Difference between revisions of "PubMan Func Spec User Management"
Line 32: | Line 32: | ||
== UC_PM_UM_02 log on to the system == | == UC_PM_UM_02 log on to the system == | ||
A user needs to log on to the system to act according to his privileges as “Account User”. | A user needs to log on to the system to act according to his privileges as “Account User”. | ||
===Status/Schedule=== | |||
*Status: '''implemented''' | |||
*Schedule:'''R1''' | |||
=== Triggers === | === Triggers === | ||
• The user wants to log on to the system. | • The user wants to log on to the system. |
Revision as of 15:12, 28 November 2007
|
UC_PM_UM_01 create account user[edit]
A new user should be given an account in the system, i.e. the user gets registered by a user ID.
Status/Schedule[edit]
- Status: not implemented
- Schedule:R3
Triggers[edit]
• The user wants to create a new account user.
Actors[edit]
• Local Administrator
Pre-Conditions[edit]
• None
Flow of Events[edit]
- 1. The user chooses to create an account user.
- 2. The system displays a list of all open organizational units and subunits for which the user has the privileges as “Local Administrator”.
- 3. (Optionally) The user chooses to view the organizational unit description.
- 3.1. The system displays the organizational unit description.
- 4. The user selects one organizational unit and confirms the choice.
- 5. The system assigns the account user as a member of the selected organizational unit and displays the account user edit view.
- 6. The user specifies an user-id, the e-mail and optionally a name of the account user and confirms the choice.
- 7. The system checks if an account user with the given user-id already exists.
- a. An account user with the given user-id does not exist in the system.
- b. Otherwise the system displays an error message (MSG_PM_UM_01), continue with 6.
- 5. The system creates and stores a new account user in the state inactive and sets the timestamp of creation. The user preferences are populated with the system defaults. The system creates an e-mail to the new account user with a predefined subject, text and link for the confirmation request. The e-mail of the user who has created the new account user is used as reply-to. The system displays a success message (MSG_PM_UM_02). The use case ends successfully.
Post-Conditions / Results[edit]
• A new account user in the state inactive is created and a confirmation request via e-mail is sent.
UC_PM_UM_02 log on to the system[edit]
A user needs to log on to the system to act according to his privileges as “Account User”.
Status/Schedule[edit]
- Status: implemented
- Schedule:R1
Triggers[edit]
• The user wants to log on to the system.
Actors[edit]
• User
Pre-Conditions[edit]
• None
Flow of Events[edit]
- 1. The user chooses to log on to the system.
- 2. The system prompts for the user-id and a password.
- 3. The user enters his user-id, the password and confirms the input.
- 4. The system checks whether the combination of user-id and password is valid and the account user is active.
- a. The combination is valid and the account user is active.
- b. Otherwise the system displays an error message (MSG_PM_UM_03), continue with 3.
- 5. The system logs the user on. The use case ends successfully.
Post-Conditions / Results[edit]
• The account user is logged-in.
UC_PM_UM_03 log off from the system[edit]
An account user wants to log off from the system.
Triggers[edit]
• The user wants to log off from the system.
Actors[edit]
• Account User
Pre-Conditions[edit]
• The user is logged in as an account user.
Flow of Events[edit]
- 1. The user chooses to log off from the system.
- 2. The system logs the user off. The use case ends successfully.
Post-Conditions / Results[edit]
• The account user is logged off from the system.
UC_PM_UM_05 edit account user[edit]
The user changes data of an account user.
Triggers[edit]
• The wants to change the data of an account user.
• This use case is included by the use case UC_PM_UM_09 confirm account user.
Actors[edit]
• Local Administrator
• Account User
Pre-Conditions[edit]
• An account user is selected.
• If the user has the role “Local Administrator”, the selected account user has to be member of any organizational unit or subunit for which the user has the privileges as “Local Administrator”.
• If the user has the role “Account User”, the selected account user is identical to the user (actor).
Flow of Events[edit]
- 1. The user chooses to edit the selected account user.
- 2. The system displays the account user edit view.
- 3. (Optionally) The user edits the name and the e-mail of the account user and confirms the choice.
- 3.1. The system saves the data and displays a success message (MSG_PM_UM_04).
- 4. (Optionally) The user chooses to change the password.
- 4.1. The system prompts for a new password and the repetition of the password.
- 4.2. The user enters a new password twice and confirms the input.
- 4.3. The system checks, if both password strings are equal.
- a. The strings are equal. The system stores the new password and displays a success message (MSG_PM_UM_05)
- b. The strings are not equal. The system displays an error message (MSG_PM_UM_06), continue with 4.1.
- 5. (Optionally) If the user has the role “Local Administrator” he can also choose to change the organizational unit assigned to the selected user.
- 5.1. The system displays a list of all open organizational units and subunits for which the user has the privileges as “Local Administrator”.
- 5.2. (Optionally) The user chooses to view the organizational unit description.
- 5.2.1. The system displays the organizational unit description.
- 5.3. The user selects one organizational unit and confirms the change..
- 5.4. The system assigns the account user as a member of the selected organizational unit and displays a success message (MSG_PM_UM_07).
- 6. Extension point: change user preferences
- 6.1. If the user is identical to the account user and wants to change the preferences, include use case UC_PM_UM_06 change user preferences.
- 7. The use case ends successfully.
Post-Conditions / Results[edit]
• The data for the account user is stored.
UC_PM_UM_06 change user preferences[edit]
The user changes his preferences.
Triggers[edit]
• The user wants to change his preferences.
Actors[edit]
• Account User
Pre-Conditions[edit]
• An account user is selected.
• The selected account user is identical to the user (actor).
• The selected account user is in state active.
Flow of Events[edit]
- 1. The user chooses to change the preferences.
- 2. The system displays the user preferences edit view.
- 3. (Optionally) The user changes the preferences.
- 4. The user confirms the input.
- 5. The system stores the preferences and displays a success message (MSG_PM_UM_08). The use case ends successfully.
Post-Conditions / Results[edit]
• The preferences of the account user are stored.
UC_PM_UM_07 assign privileges to account user[edit]
The user assigns new or additional privileges to an account user or removes privileges from an account user. Privileges can be assigned to any user without regard to their individual organizational unit.
Triggers[edit]
• The user wants to change the privilege assignment of an account user.
Actors[edit]
• Local Administrator
Pre-Conditions[edit]
• An account user is selected.
Flow of Events[edit]
- 1. The user chooses to edit the assignment of privileges to the selected account user.
- 2. The system displays the privileges edit view.
- 3. (Optionally) The user adds one or more new privileges to the selected account user.
- 3.1. The system displays a list of existing system roles.
- 3.2. The user selects one system role.
- 3.3. The system displays a list of objects according to the class definition of the selected role for which the user has the privileges as “Local Administrator”.
- 3.4. The user selects one or more objects and confirms the input.
- 3.5. The system creates a privilege for each selected object with the account user and the selected role. The system updates the privileges edit view.
- 4. (Optionally) The user edits a privilege for the selected account user.
- 4.1. The system displays a list of objects according to the class definition of the role for which the user has the privileges as “Local Administrator”.
- 4.2. The user selects an object and confirms the choice.
- 4.3. The system updates the object in the selected privilege and the privileges edit view.
- 5. (Optionally) The user removes one privilege.
- 5.1. The.system deletes the selected privilege and updates the privileges edit view.
- 6. The user chooses to finalize the data.
- 7. The system stores the privileges and displays a success message (MSG_PM_UM_09). The use case ends successfully.
Post-Conditions / Results[edit]
• The privileges are stored.
UC_PM_UM_08 delete account user[edit]
The user deletes an account user. By deleting an account user, all items owned by the account user in state “pending” will be deleted as well. An account user can not be deleted if he is owner of items in any other state than “pending”.
Triggers[edit]
• The user wants to delete an account user.
Actors[edit]
• Local Administrator
Pre-Conditions[edit]
• An account user is selected.
• The selected account user is assigned to any organizational unit or subunit for which the user has the privileges as “Local Administrator”.
Flow of Events[edit]
- 1. The user chooses to delete the selected user.
- 2. The system checks if the selected user owns items in any other state than “pending”.
- a. No item in any other state than “pending” exists.
- b. One or more items in any other state than “pending” exist. The system displays an error message (MSG_PM_UM_10). The use case ends without success.
- 3. The system displays a list of all “pending” items and prompts the user to confirm the deleting of the account user and the items.
- 4. The user confirms to delete the account user and the “pending” items.
- 5. The system deletes the items as well as the account user, the preferences and the privileges and displays a success message (MSG_PM_UM_11). The use case ends successfully.
Alternatives[edit]
- 4a. The user does not confirm to delete the account user and the items.
- 1. The selected account user and the “pending” items are unaffected. The use case ends without success.
Post-Conditions / Results[edit]
• The account user, the preferences, the privileges and all items in state “pending” are deleted.
UC_PM_UM_09 confirm account user[edit]
The user received a confirmation request for an account user and follows the given link to confirm the account user.
Triggers[edit]
• The user wants to confirm the account user.
Actors[edit]
• User
Pre-Conditions[edit]
• The account user has been created and is in state inactive.
Flow of Events[edit]
- 1. The user chooses to confirm the account user by following the link from the confirmation request.
- 2. The system prompts for a password, a repetition of the password and for a confirmation of terms and conditions.
- 3. (Optionally) The user chooses to view the terms and conditions.
- 3.1. The system displays the terms and conditions.
- 4. The user enters a password twice, accepts the terms and conditions and confirms the input.
- 5. The system checks, if both password strings are equal.
- a. The strings are equal. The system stores the password and changes the state of the account user to active, logs the user on and displays a welcome page including a success message (MSG_PM_UM_12).
- b. The strings are not equal. The system displays an error message (MSG_PM_UM_06), continue with 2.
- 6. Extension point: edit account user
- 6.1. If the user wants to edit his account details include use case UC_PM_UM_05 edit account user.
- 7. The use case ends successfully.
Alternatives[edit]
- 4a. The user does not confirm to accept the terms and conditions.
- 1. The system displays a message (MSG_PM_UM_13), continue with 2.
Post-Conditions / Results[edit]
• The account user has a password and is in state active. • The account user is logged on.