Skip to content

BRD

Feature BRD: Admin: User Editing & Status Management
Document Version: 1.0
Author: Senior Business Analyst
Date: 2025-09-10
Status: Draft for Review

1. Introduction

1.1. Feature Overview

This document specifies the business requirements for the User Editing and Status Management feature. This functionality allows authorized administrators to modify an existing user's profile information, manage their group memberships, and control their account status (e.g., "Active," "Inactive"). This is a core administrative function necessary for maintaining an accurate and secure user base throughout the user lifecycle.

1.2. Business Objectives

  • Maintain Data Accuracy: To provide a mechanism for correcting and updating user information as roles and personal details change over time.
  • Manage User Lifecycle: To enable administrators to control a user's access by deactivating accounts for departing employees or reactivating accounts for returning ones, directly impacting system security.
  • Ensure Correct Access Levels: To allow for the flexible management of a user's group assignments, ensuring their permissions evolve in lockstep with their job responsibilities.

1.3. Scope

In Scope Out of Scope
A dedicated "Edit User" page, pre-populated with the selected user's data. The ability for a user to edit their own profile. (This is a separate self-service feature).
The ability to modify a user's First Name and Last Name. The ability to change a user's Email Address, which serves as a unique, permanent identifier.
The ability to manage a user's group memberships (adding or removing them from groups). The ability to permanently delete a user record. (This is a distinct, destructive action).
The ability to change a user's account status between "Active" and "Inactive." Bulk-editing capabilities for multiple users at once.
All data validation rules for the editing form. Password reset functionality, which is handled by the identity provider.

2. Business Requirements & Rules

2.1. Access Control

  • Rule 2.1.1: The ability to access and use the "Edit User" page MUST be strictly controlled. A user MUST have the user:edit permission in their effective permission set.
  • Rule 2.1.2: An "Edit" button or link MUST be visible on each row of the User Listing page, but only to administrators who possess the user:edit permission.
  • Rule 2.1.3: Users without the user:edit permission who attempt to access the Edit User page URL directly MUST be redirected to an "Access Denied" page.

2.2. User Interface and Components

  • Rule 2.2.1 (Data Pre-population): When navigating to the "Edit User" page for a specific user, all form fields MUST be pre-populated with that user's current data.
  • Rule 2.2.2 (Form Fields): The "Edit User" interface MUST contain the following fields:
    • First Name: A required text input field.
    • Last Name: A required text input field.
    • Email Address: A read-only, non-editable display of the user's email.
    • Status: A dropdown or radio button group allowing selection between "Active" and "Inactive."
    • Group Assignment: A required multi-select dropdown or checkbox list, populated with all available group names and with the user's current groups pre-selected.
  • Rule 2.2.3 (Actions): The form MUST provide two primary actions:
    • "Save Changes" Button: Submits the form. This button should be disabled by default and only become enabled when a change has been made to the form data.
    • "Cancel" Button/Link: Discards all changes and returns the administrator to the User Listing page.

2.3. Data Validation and System Logic

  • Rule 2.3.1 (Field Validation): The same validation rules from user creation MUST be enforced:
    • First Name & Last Name: Cannot be empty; must be between 2 and 50 characters.
    • Group Assignment: At least one group MUST remain selected. The system must prevent a user from being unassigned from all groups.
  • Rule 2.3.2 (Status Change Impact): Changing a user's status to "Inactive" MUST prevent that user from being able to log in to the system. Existing active sessions should be terminated if technically feasible.
  • Rule 2.3.3 (Successful Submission): Upon successful validation and submission, the system MUST:
    1. Update the user record and its group associations in the database.
    2. Redirect the administrator back to the User Listing page.
    3. Display a persistent success notification message (e.g., "User 'Jane Doe' has been updated successfully.").

3. User Scenarios

3.1. Scenario 1: Successful Profile and Group Update

  • Persona: David, a System Administrator.
  • Action: A user, John Smith, has recently married and changed his last name to Jones. He has also moved from the "Sales" team to the "Marketing" team. David navigates to the User Listing, finds John, and clicks "Edit." He changes the Last Name to "Jones," un-selects the "Sales Team" group, and selects the "Marketing Department" group. He then clicks "Save Changes."
  • Expected System Behavior:
    1. The system validates the new last name and confirms at least one group is still selected.
    2. The user's record is updated in the database.
    3. David is returned to the User Listing page, where the user now appears as "John Jones" and is associated with the "Marketing Department." A success message is displayed.

3.2. Scenario 2: Deactivating a User Account

  • Persona: David, a System Administrator.
  • Action: An employee, Carol, has left the company. David finds Carol's account on the User Listing page and clicks "Edit." He changes her "Status" from "Active" to "Inactive" and clicks "Save Changes."
  • Expected System Behavior:
    1. Carol's user status is updated to "Inactive." David is redirected to the User Listing page with a success message.
    2. The next time Carol attempts to log in with her credentials, the system will deny her access.

3.3. Scenario 3: Edit Failure (Invalid Data)

  • Persona: David, a System Administrator.
  • Action: While editing a user, David accidentally deletes the user's First Name, leaving the field blank. He also tries to un-assign the user from all groups. He clicks "Save Changes."
  • Expected System Behavior:
    1. The system's validation fails on two counts.
    2. The form is not submitted.
    3. Clear, inline error messages appear next to the invalid fields: "First Name is required" and "User must belong to at least one group."

3.4. Scenario 4: Unauthorized Attempt to Edit

  • Persona: A manager with user:view:list permissions but not user:edit.
  • Action: The manager is viewing the list of users on their team.
  • Expected System Behavior:
    1. The "Edit" button/link is not visible on any user row.
    2. If the manager tries to guess the URL to an edit page, the system checks their permissions, finds user:edit is missing, and redirects them to the "Access Denied" page.