Skip to content

Use Case & User Stories: Admin: User Editing & Status Management
Use Case ID: UC-07
Use Case Name: Modify an Existing User Account
Feature: Admin: User Editing & Status Management
Actors: System Administrator (Primary)

1. Use Case Description

This use case outlines the process for an authorized System Administrator to modify the details of an existing user account. This includes updating a user's name, managing their group memberships to adjust their permissions, and changing their account status between "Active" and "Inactive" to control their access to the system. This is a critical function for maintaining data accuracy and managing the user lifecycle. The user's email address is treated as a permanent, non-editable identifier.

2. User Stories

  • US-26: Update User's Personal and Group Information > As a System Administrator, > I want to be able to edit a user's First Name, Last Name, and change their group memberships, > so that I can keep user records accurate as they change roles or names (e.g., moving from "Sales" to "Marketing").

  • US-27: Manage User Lifecycle via Status Change > As a System Administrator, > I want to change a user's status from "Active" to "Inactive", > so that I can immediately revoke the login access for an employee who has left the company, ensuring system security.

  • US-28: Prevent Accidental Removal of All Permissions > As a System Administrator, > I want the system to prevent me from saving changes if I try to remove a user from all of their assigned groups, > so that I don't accidentally leave a user in a state with no permissions.

  • US-29: Enforce Access Control for User Editing > As an IT Security Officer, > I want the ability to edit user profiles to be strictly limited to administrators with the user:edit permission, > so that only authorized personnel can modify user data, group assignments, and account status.

  • US-30: Intuitive Editing Workflow > As a System Administrator, > I want the "Save Changes" button to be disabled until I've actually made a change to the form, > so that it's clear when I have unsaved changes and I'm prevented from making empty submissions.

3. Preconditions

  • The user is a System Administrator with an active session (UC-01).
  • The administrator's effective permissions include user:edit (UC-04).
  • The administrator is on the "User Management" listing page (UC-05) and has identified the user they wish to edit.

4. Postconditions

  • On Success:
    • The user's record and/or group associations are updated in the database.
    • The administrator is returned to the User Listing page, where the updated information is now visible.
    • A success notification is displayed.
  • On Failure:
    • No changes are saved to the database.
    • The administrator remains on the "Edit User" form with their entered data preserved.
    • Clear error messages are displayed for the invalid fields.

5. Main Success Scenario (Happy Path - Name and Group Change)

Step User Action System Response
1 On the User Listing page, finds the user "John Smith" and clicks the "Edit" button on his row. The system verifies the admin has user:edit permission and navigates them to the "Edit User" page for John Smith.
2 The form is displayed and pre-populated with John's current data: First Name ("John"), Last Name ("Smith"), a read-only Email, his Status ("Active"), and his currently selected group ("Sales Team"). The "Save Changes" button is disabled.
3 Changes the Last Name field to "Jones". The system detects a change, and the "Save Changes" button becomes enabled.
4 In the "Group Assignment" list, un-selects "Sales Team" and selects "Marketing Department".
5 Clicks the "Save Changes" button. The system validates that all required fields are still valid (name is not empty, at least one group is selected).
6 The system updates the user record and its group associations in the database.
7 The system redirects the administrator back to the User Listing page.
8 The list now shows the user as "John Jones" with the "Marketing Department" group. A success message is displayed: "User 'John Jones' has been updated successfully."

6. Alternative & Exception Flows

  • Flow A: Deactivating a User Account

    • 3a. Admin selects the user "Carol" and navigates to her edit page.
    • 3b. Admin changes the "Status" dropdown from "Active" to "Inactive". The "Save Changes" button becomes enabled.
    • 3c. Admin clicks "Save Changes".
    • System Response: The user record is updated. The administrator is returned to the User Listing with a success message. The next time Carol attempts to log in, her session will be denied.

  • Flow B: Edit Failure - Validation

    • 5a. Empty Required Field: Admin accidentally deletes the user's First Name, leaving the field blank, and clicks "Save Changes".
      • System Response: The form is not submitted. An inline error appears: "First Name is required."
    • 5b. No Groups Selected: Admin de-selects all groups from the user and clicks "Save Changes".
      • System Response: The form is not submitted. An error message appears: "User must belong to at least one group."

  • Flow C: User Cancels Edit

    • 3a. Admin makes several changes to a user's profile and then clicks the "Cancel" button.
      • System Response: The system discards all changes and returns the admin to the User Listing page. No data is saved.

  • Exception Flow D: Unauthorized Access Attempt

    • 1a. A manager with user:view:list permission but not user:edit views the user list.
      • System Response: The "Edit" button is not visible on any user row.
    • 1b. If the manager obtains and tries to access the direct URL for an edit page.
      • System Response: The system checks permissions, finds user:edit is missing, and redirects them to the "Access Denied" page.