PubMan Func Spec User Management

PubMan Functional Specification View · Browse Full Submission · Easy Submission Import · Export Quality Assurance · Search Collaboration · Copyright Collection Administration Organizational Unit Management User Management Feeding local webpages History of affiliations edit

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

• Local Administrator

Pre-Conditions

• None

Flow of Events

• 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

• A new account user in the state inactive is created and a confirmation request via e-mail is sent.

Discussion

Talk:PubMan_Func_Spec_User_Management#UC_PM_UM_01 create account user

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.

Discussion

Talk:PubMan_Func_Spec_User_Management#UC_PM_UM_02 log on to the system

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.

Discussion

Talk:PubMan_Func_Spec_User_Management#UC_PM_UM_03 log 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.

• This use case is included by the use case UC_PM_UM_09 confirm account user.

Actors

• Local Administrator

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.
• 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).
• 7. The use case ends successfully.

Post-Conditions / Results

• The data for the account user is stored.

Future Development

Actors:

• Account User

Flow of events

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

Discussion

Talk:PubMan_Func_Spec_User_Management#UC_PM_UM_05 edit account user

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.

Discussion

Talk:PubMan_Func_Spec_User_Management#UC_PM_UM_06 change user preferences

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

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

Discussion

Talk:PubMan_Func_Spec_User_Management#UC_PM_UM_07 assign privileges to account user

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

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.

Discussion

Talk:PubMan_Func_Spec_User_Management#UC_PM_UM_08 delete account user

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.

Discussion

Talk:PubMan_Func_Spec_User_Management#UC_PM_UM_09 confirm account user

UC_PM_UM_10 create user group

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

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 in status "opened" or "closed", one or more users by entering their user name, one or more user groups or, one or more user attributes (provided via Shibboleth)
• 6. The system saves the selectors for the user group and sends every member of the user group a notification (details have to be specified. This e-Mail shall contain the information, that the user hast to contact the user group creator if he wants to leave the user group). The system displays a success message (MSG_PM_UM_14). 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.
• R5 Scope:
  • For the OUs in status "opened" or "closed" additional action link next to OU in the browse tree (available only if user is logged in with Administrative privileges) should be displayed.
  • When administrator activates this link, the system creates a user group in following manner:
    • name: User group ||'-' ||<OU-Name>
    • label: UG||'-'||<OU-ID>
    • description: A user group for users affiliated to <OU-Name>
    • type: OU
    • selectors:
      • add selector with following attributes:
        • name="organizational-unit"
        • type="internal"
        • value of selector should be <OU-ID>

• User group administrator does not exist yet as a role
• see also JIRA issue

Discussion

Talk:PubMan_Func_Spec_User_Management#UC_PM_UM_10 create user group

UC_PM_UM_11 Grant or revoke audience privileges for files

The user grants or revokes audience privileges to one or more user groups for the content of selected files that have visibility level set to "audience".

Status/Schedule

• Status: design
• Schedule:R5

Triggers

• The user wants to grant or revoke audience privileges for files of an item to one or more user groups.

Actors

• Moderator

Pre-Conditions

• One publication item is selected (full item view).
• Publication item has one or more files with visibility level set to "audience".
• The user chooses the "audience" tab, which serves as workspace to define the audience group(s).

Flow of Events

• 1. The user chooses to define who can access the content of the files of the item with visibility set to "audience".
• 2. The system displays the "Audience" view of an item containing a list of all files with visibility set to "audience" and evetl. the groups for which the audience privilege has been granted.
• 3. For each file:
  • 3.1. (Optionally) If there are no granted privileges to user groups for the file
    • 3.1.1 The system displays a list of existing user groups the user is allowed to see
    • 3.1.2 The user selects one or more user groups that need to be granted with audience privilege on the file content
  • 3.2. (Optionally) If there are already granted privileges to user groups for the file
    • 3.2.1 The system displays a list of granted user groups with audience privilege for the file
    • 3.2.2 The user selects one or more user groups for which the audience privilege needs to be revoked on the file content
  • 3.3 The user confirms the input
    • 3.1.3 The system creates or revokes an audience role grant for each specified file and user group. The system displays a confirmation message. The use case ends successfully.

Post-Conditions / Results

• The privileges for files and user groups are stored and are taking effect for all users who are members of the user group after the release of an item (or immediately, if the item was already released).

Discussion

Talk:PubMan_Func_Spec_User_Management#UC_PM_UM_11 Grant audience privileges for files

UC_PM_UM_12 Revoke audience privileges for files

The system revokes all audience privileges from one or more user groups for the content of selected files that have visibility level set to "audience". This operation is triggered during the item release, see UC_PM_QA_08 Release Item.

Status/Schedule

• Status: design
• Schedule:R5

Triggers

• The system revokes audience privileges for files of an item to one or more user groups.

Actors

• System

Pre-Conditions

• One publication item is selected.
• Publication item has no files with visibility level set to "audience".
• There are files on the item for which audience grants exist

Flow of Events

• 1. For each file that satisfies the preconditions:
• 1.1. The system revokes the audience privileges that exist for files with visibility level other than "audience".
• 2. The use case ends successfully.

Post-Conditions / Results

• The privileges for files and user groups are revoked and are taking effect for all users who are members of the user group after the release of an item.

Discussion

• use UserAccount.retrieveGrants method, UserGroup.revokeGrants method or UserAccount.revokeGrants method (depending on the type of the grantee)
  • for R5 only groups can be granted with audience privilege

Talk:PubMan_Func_Spec_User_Management#UC_PM_UM_12 Revoke audience privileges for files

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

Discussion

Talk:PubMan_Func_Spec_User_Management#Additional information - system roles

Publication Management

Use Case

Identifier

Logging-in system for computer networks

Organizational Unit