Talk:PubMan Func Spec User Management

UC_PM_UM_01 create account user

A new user should be given an account in the system, i.e. the user gets registered by a user ID.

Status/Schedule

• Status: implemented
• Schedule:R3

Triggers

• The user wants to create a new account user.

Actors

• Service Administrator

Pre-Conditions

• None

Flow of Events

• 1. The user chooses to create an account user.
• 2. The user defines the organisational unit, the name , the user ID and the e-mail (optional) and confirms.
• 3 The system assigns a default password.
• 4. 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 active.

Post-Conditions / Results

• A new account user in the state active is created.

Future development

• Revise use case according to:

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 and confirms the choice. 7. The system assigns a default password. 8. 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. 9. 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: A new account user in the state inactive is created and a confirmation request via e-mail is sent.

• Add specification for creation of registered users (i.e. users are not assigned to any organisational unit, but do have some basic privileges, such as save a search, basket, run an export). self-registration has to be considered.

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”.

Status/Schedule

• Status: implemented
• Schedule:R1

Triggers

• The user wants to log on to the system.

Actors

• User

Pre-Conditions

• None

Flow of Events

• 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

• The account user is logged-in.

UC_PM_UM_03 log off from the system

An account user wants to log off from the system.

Status/Schedule

• Status: implemented
• Schedule:R1

Triggers

• The user wants to log off from the system.

Actors

• Account User

Pre-Conditions

• The user is logged in as an account user.

Flow of Events

• 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

• The account user is logged off from the system.

UC_PM_UM_05 edit account user

The user changes data of an account user.

Status/Schedule

• Status: implemented
• Schedule:R3

Triggers

• The wants to change the data of an account user.

Actors

• Service Administrator

Pre-Conditions

• An account user is selected.

Flow of Events

• 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, the login-name, the e-mail, the Organisational unit and the grants for the user in a specific context.
• 4. The system saves the data and displays a success message (MSG_PM_UM_04).

Post-Conditions / Results

• The data for the account user is stored.

Future development

Revise use case according to:

Triggers:

• The user 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:

• Local Administrator

• Account User

Pre-Conditions:

• 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:

• 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.

Comment Robert: Currently, editing the password is not possible and in principle this shouldn't be necessary, when the system is used - as planned - with authentication via shibboleth. so the question is how much effort we want to spend on this interim solution.

Agree, we need to see what happens with the identity provider or shibboleth authentication. This use case can be considered partly as "external" . The non-external parts are: user preferences and I am not certain on organizational units at present and how they will relate to an external identity provider and will be mapped to escidoc org units--Natasa 12:00, 30 January 2008 (CET)

• 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: The data for the account user is stored.

UC_PM_UM_06 change user preferences

The user changes his preferences.

Status/Schedule

• Status: not implemented
• Schedule:to be defined

Triggers

• The user wants to change his preferences.

Actors

• Account User

Pre-Conditions

• 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

• 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

• The preferences of the account user are stored.

Candidates for user preferences

• Saved baskets
• saved search, incl. Descriptions
• default view (tabular, bibliographic)
• Default citation style
• User is always first author, prefill personal data from Cone
• User gets his default co-authors (stored in user preferneces)
• Personal template item (is a template PubItem, own ID)
• check for duplicates during entry (depends on duplicate check scenarios)
• Set default index for quick search (e.g. restrict to certain context)

UC_PM_UM_07 assign privileges to account user

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.

Status/Schedule

• Status: implemented
• Schedule:R3

Triggers

• The user wants to change the privilege assignment of an account user.

Actors

• Service Administrator

Pre-Conditions

• An account user is selected.

Flow of Events

• 1. The user chooses to edit the assignment of privileges to the selected account user.
• 2. The system displays the privileges edit view.
• 3. The user edits the grants to the selected user for a specific context.
• 4. The user chooses to finalize the data.
• 5. The system stores the privileges and displays a success message (MSG_PM_UM_09). The use case ends successfully.

Post-Conditions / Results

• The privileges are stored.

Future development

Revise use case according to:

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: The user wants to change the privilege assignment of an account user.

Actors: Local Administrator

Pre-Conditions: An account user is selected.

Flow of Events:

• 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: The privileges are stored.

UC_PM_UM_08 delete account user

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”. What is the purpose of "deleting" account user once he was active in the system? Should not the "de-activation" be sufficient?--Natasa 12:03, 30 January 2008 (CET)

Status/Schedule

• Status: not implemented
• Schedule:to be defined

Triggers

• The user wants to delete an account user.

Actors

• Local Administrator

Pre-Conditions

• 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

• 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

• 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

• The account user, the preferences, the privileges and all items in state “pending” are deleted.

UC_PM_UM_09 confirm account user

The user received a confirmation request for an account user and follows the given link to confirm the account user.

Status/Schedule

• Status: not implemented
• Schedule:to be defined

Triggers

• The user wants to confirm the account user.

Actors

• User

Pre-Conditions

• The account user has been created and is in state inactive.

Flow of Events

• 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

• 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

• The account user has a password and is in state active.

• The account user is logged on.

UC_PM_UM_10 create user group

A new user group should be created in the system. See R5 limitation.

Based on this use case, further use cases needs to be specified (--Kristina 09:16, 31 July 2009 (UTC)):

• Add members to a user group
• Remove members from a user group
• Delete user group

Status/Schedule

• Status: design
• Schedule:R5

Triggers

• The user wants to create a new user group in the system.

Actors

• Local Administrator
• User Group Administrator

Pre-Conditions

• None

Flow of Events

• 1. The user chooses to create a new user group
• 2. The user specifies a user group name, label (short name), type of the user group and optionally, description of the purpose of the user group.
• 3. The user saves the newly created user group.
• 4. The system prompts for definition of the group selectors
• 5. The user defines the group selectors by choosing: one or more organizational units, one or more users, one or more user groups or, one or more user attributes (provided via Shibboleth)

TODO: specify this part better --Natasa 08:34, 14 May 2009 (UTC)

• 6. The system saves the selectors for the user group. The system displays a success message (MSG_PM_UM_02). The use case ends successfully.

Post-Conditions / Results

• A new user group in the state active is created. The user group can be further granted with rights and privileges for system objects.

R5 Limitation

• In release R5 a user group will be created for a single selector of type organizational unit. This would imply that all user accounts that are affiliated to this organizational unit are automatically members of the newly created user group.
• User group administrator does not exist yet as a role
• see also link JIRA issue

• Back to PubMan_Func_Spec_User_Management#UC_PM_UM_10_create_user_group

Additional information - system roles

The “Service Administrator” acts as a superuser in the system. Only one user with the userid “service_admin” will exist in the system. This user has all privileges and can not be deleted. No other user can act as a “Service Administrator” because “Service Administrator” is not a role. The role “Local Administrator” is assigned to account users in the context of an organizational unit and the respective child organizational units. The user is responsible for the execution of administrative use cases for these organizational units. A user who is not logged on to the system is called “anonymous user” and the corresponding role is “User”.

Use Case

Identifier

Central European Time

Coordinated Universal Time

Logging-in system for computer networks