Func Spec Admin

From MPDLMediaWiki
(Redirected from Func Spec Local Admin)
Jump to navigation Jump to search

User Management[edit]

UC_LA_UM_01 Create account user[edit]

A new user should be given an account in the system.

Status/Schedule

  • Status: in specification
  • Schedule:tbd

Triggers

  • The user wants to create a new account user.

Actors

  • System Administrator (current state of implementation)
  • User Administrator (future scenario)

Pre-Conditions

  • The user management is local (no LDAP etc. involved)

Flow of Events

  1. The user chooses to create an account user.
  2. The system displays an alphabetical orders list of all open organizational units and subunits for which the user has administrative rights for.
  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 displays the account user edit view.
  6. The user specifies: NAME, LOGIN_NAME, EMAIL
  7. The system checks if an account user with the given login_name already exists.
    7.1. An account user with the given login_name does not exist in the system.
    7.2. Otherwise the system displays an error message, continue with 6.
  8. Extension Point: edit user preferences
    8.1. If the user wants to edit the default user preferences, include UC_LA_PM_03 Edit user preferences.
  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 (if not set via UC_LA_PM_03).
    • The system sets a password for this user.
    • The system creates an e-mail to the new account user with a predefined subject, text (with generated pwd) and link for the confirmation request. The e-mail of the administrative user who has created the new account user is used as reply-to.
    • The system displays a success message. 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.

Remarks FACES

  • To provide all available functionalities of Faces, for a Faces user following information has to be provided
    1. Name: family name, given name (will automatically be used as author of an own album)
    2. Valid E-Mail address (to receive system notifications during the scenario "Sharing of an album")

UC_LA_UM_02 Edit account user[edit]

The user changes data of an account user.

Status/Schedule

  • Status: in specification
  • Schedule:tbd

Triggers

  • The user wants to change the data of an account user.
  • Integrated in: UC_LA_UM_05 Activate user
  • Integrated in: UC_LA_AS_01 View account users list

Actors

  • System Administrator (current state of implementation)
  • User - own profile (future scenario)
  • User Administrator (future scenario)

Pre-Conditions

  • The user management is local (no LDAP etc. involved)
  • An account user is selected.
  • The selected account user has to be member of any organizational unit or subunit for which the user has administrative rights for or the selected account user is the user itself.

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: NAME, LOGIN_NAME, EMAIL.
  4. (Optionally) The user chooses to change the password (Only if the account user is the user itself).
    4.1. The system prompts for a new password and the repetition of the password.
    4.2. 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
    b. The strings are not equal. The system displays an error message, continue with 4.1.
  5. The user chooses to change the organizational unit assigned to the selected user.
    5.1. The system displays an alphabetically orders list of all open organizational units and subunits for which the user has administrative rights for.
    5.2. (Optionally) The user chooses to view 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.
  6. (Optionally) Extension Point: UC_LA_UM_03 Assign privileges to account user
  7. (Optionally) Extension Point: UC_LA_PM_03 Edit user preferences
  8. (Optionally) Extension Point: UC_LA_UM_04 Deactivate account user
  9. Optionally) Extension Point: UC_LA_AS_05 View user groups list for user
  10. The user confirms the changes. The use case ends successfully.

Post-Conditions / Results

  • The data for the account user is stored.

Additional Information

  • A matrix of User Management actions can be found here


Open Questions

  • Who is allowed to edit what?
    • For start, the user itself is only allowed to change his password and not other data (NAME, EMAIL etc.)
    • An administrative user is only allowed to change the data of the user (NAME, EMAIL etc.), not the password
  • There must be a possibility for the local admin (or the user himself) to reset the password just for the case that the user has forgotten his password. --Kristina 15:33, 15 February 2010 (UTC)
    • I think only the user himself should be able to reset his pwd. Therefore I am not sure if this is part of the Local Admin spec. We will have to clarify in discussion.--Friederike 15:43, 17 February 2010 (UTC)

UC_LA_UM_03 Assign privileges to account user[edit]

The user assigns new or additional privileges to an account user or removes privileges from an account user.

Status/Schedule

  • Status: in specification
  • Schedule:tbd

Triggers

  • The user wants to change the privilege assignment of an account user.
  • Integrated in: UC_LA_UM_02 Edit account user

Actors

  • System Administrator (current state of implementation)
  • User Administrator (future scenario)

Pre-Conditions

  • An account user is selected.
  • The selected account user has to be member of any organizational unit or subunit for which the user has administrative rights for.

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 new privileges to the selected account user.
    3.1. The system displays an alphabetically ordered list of existing system roles and an alphabetically ordered list of all contexts (only state 'open') the user has administrative rights for.
    3.2. The user selects one system role. The user selects a context the system role should be applied to.
  4. (Optionally) The user edits a privilege for the selected account user.
    4.1. The system displays an alphabetically ordered list of all system roles and the related contexts the account user has.
    4.2. The user can change the role and/ or the context of already existing privileges
  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. The use case ends successfully.

Post-Conditions / Results

  • The privileges are stored.

Additional Information

  • What privileges a administrative user may assign are described in the action matrix

UC_LA_UM_04 Deactivate account user[edit]

The user deactivates an account user (the account users state is set to 'inactive').

Status/Schedule

  • Status: in specification
  • Schedule:tbd

Triggers

  • The user wants to deactivate an account user.
  • Integrated in: UC_LA_UM_02 Edit account user

Actors

  • System Administrator (current state of implementation)
  • User Administrator (future scenario)

Pre-Conditions

  • An account user is selected.
  • The selected account user has to be member of any organizational unit or subunit for which the user has administrative rights for.
  • The selected account user is in state 'active'

Flow of Events

  1. The user chooses to deactivate the selected user.
  2. The system asks for a confirmation to delete the selected account user.
    2.1. The user confirms this. The account user state is set to 'inactive'. The user can not log in any more and he can not perform any actions any more. The use case ends successfully.
    3.2. The user does not confirm this. The user is redirected to the selected user edit page. The use case ends without success.

Post-Conditions / Results

  • The account user state is set to 'inactive'.

Further informations

  • A deactivated user can be activated once again by an administrator with the corresponding priviledges.

Open Questions

  • Should the account user get an email that his account was set 'inactive', and he can not log in anymore?
    • I think yes, because otherwise the user does not have any information why his account doesn't work any more. --Kristina 15:38, 15 February 2010 (UTC)
  • What happens with pending items of the account user? When the account user is inactive, no one has access to this items, they are lost within the system.
    1. All pending items will be deleted when deactivating an account user (to prevent any mistakes, a list of all pending items should be displayed during the process of deactivating an user)
    2. A user can only be deactivated, when he does not have any pending items (BUT then it could happen that some users can never be deactivated)
  • What happens with the released items of the user? He now has no more change to edit/withdraw them (especially in Faces, where an album can only be edited by its creator)? Somehow there needs to be a general administrator who in such a case can edit all items.

UC_LA_UM_05 Activate user[edit]

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

Status/Schedule

  • Status: in specification
  • Schedule:tbd

Triggers

  • The user wants to activate the account.

Actors

  • System Administrator (current state of implementation)
  • User (next step of implementation)

Pre-Conditions

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

Flow of Events

  1. The user chooses to activate the account 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. - The system displays the terms and conditions.
  4. The user enters a password twice, accepts the terms and conditions and confirms the input.
    4.1. The user confirms the terms of condition
    4.2. The user does not confirm to accept the terms and conditions. - The system displays an error message, continue with 2.
  5. The system checks, if both password strings are equal.
    5.1. 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.
    5.2. The strings are not equal. The system displays an error message, continue with 2.
  6. (Optionally) Extension point: UC_LA_UM_02 Edit account user
  7. The use case ends successfully.

Post-Conditions / Results

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

Open Question

  • Is only the user allowed to activate his account? (Guess this has smth. to do with the acceptance of the terms of condition?)

UC_LA_UM_06 Create user group[edit]

A new user group should be created in the system.

Status/Schedule

  • Status: in specification
  • Schedule:tbd

Triggers

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

Actors

  • System Administrator (current state of implementation)
  • UserGroup Administrator (next step of implementation FW 1.2)

Pre-Conditions

  • None

Flow of Events

  1. The user chooses to create a new user group
  2. The user specifies a NAME, LABEL (short name), TYPE, DESCRIPTION for 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" (only OUs where he has administrative rights for)
    • one or more users by entering their user name (only users where he has administrative rights for)
    • one or more user groups (only user groups where he has administrative rights for)
    • one or more user attributes (provided via Shibboleth)
    Does that mean that for each of this bullet points a list will be displayed or does the user have to know the user name of his colleagues? --Kristina 15:48, 15 February 2010 (UTC)
  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. 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.

Open Question

  • Is a user group affiliated to an OU? (like user)
  • What about asking (via e-mail confirmation) the user first if he wants to be part of a user group? For Faces (sharing of an album) a confirmation is required by the institute. --Kristina 15:48, 15 February 2010 (UTC)

UC_LA_UM_07 Edit user group[edit]

An already created user group is edited

Status/Schedule

  • Status: in specification
  • Schedule:tbd

Triggers

  • The user wants to edit a user group
  • Integrated in: UC_LA_AS_02 View account user groups list

Actors

  • System Administrator (current state of implementation)
  • UserGroup Administrator (next step of implementation FW 1.2)

Pre-Conditions

  • The user has administrative rights for the selected user group

Flow of Events

  1. The user chooses to edit a user group
  2. (Optionally) The user can edit the following parameter : NAME, LABEL (short name), TYPE, DESCRIPTION
  3. (Optionally) The user wants to modify the selectors of the user group
    3.1. The system displays all selectors of the user group
    3.2. The user can change the selectors of the user group by defining new ones:
    • one or more organizational units in status "opened" or "closed" (only OUs where he has administrative rights for)
    • one or more users by entering their user name (only users where he has administrative rights for)
    • one or more user groups (only user groups where he has administrative rights for)
    • one or more user attributes (provided via Shibboleth)
  4. The user wants to view all members of this user group. The system displays all members of this user group.
  5. The user saves the changes of the user group.

UC_LA_UM_08 Confirm account user[edit]

Status/Schedule

  • Status: in specification
  • Schedule: tbd

Motivation

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

Pre-Condition

  • An account user has been created and is in state deactivated.
  • An confirmation mail has been send to the selected account user.

Steps

  1. The user chooses to confirm the account user by following the link to the confirmation request.
  2. The system prompts for a password and a repetition of the password.
  3. The user enters a password twice and confirms the input.
  4. The system checks, if both password strings are equal.
  5. 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 success message. The use case ends successfully.

Alternatives

5.a The strings are not equal. The system displays an error message, continue with Step 2.

Actors Involved

  • User

Additional information[edit]

User States
An account user can have two different states:

  1. active:
    1. The account has been activated by the user and can be used.
  2. deactivated/inactive:
    1. The account has been created by the administrator but has not been activated yet by the user.
    2. An active account has been deactivated by the administrator so it can not be used any more. Deactivated accounts can be activated again by the administrator.

Context Management[edit]

UC_LA_CM_01 Create a context[edit]

Create a new context as an administrative unit.

Status/Schedule

  • Status: in specification
  • Schedule:tbd

Triggers

  • The user wants to create a new context.

Actors

  • System Administrator (current state of implementation)
  • Context Administrator (next step of implementation with FW 1.2)

Pre-Conditions

  • None

Flow of Events

  1. The user chooses to create a new context.
  2. The system displays an alphabetically sorted list of all open organizational units and subunits for which the user has the privileges as 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 or more organizational units and confirms the choice.
  5. The system creates a context in the state “created” with the selected organizational unit(s) and the standard workflows predefined. By default all available genres are selected as “allowed genres”, all available submission methods are selected as “allowed submission methods”.
  6. Continue with: UC_LA_CM_02 Edit context. The use case ends successfully.

Post-Conditions / Results

  • A new context in the state “created” has been created.

UC_LA_CM_02 Edit context[edit]

The user edits a context attributes or metadata values.

Status/Schedule

  • Status: in specification
  • Schedule:tbd

Triggers

  • The user wants to edit the context attributes or the default metadata values.
  • Included in: UC_LA_CM_01 Create a context.
  • Included in: UC_LA_AS_03 View contexts list

Actors

  • System Administrator (current state of implementation)
  • Context Administrator (next step of implementation with FW 1.2)
  • Context Modifier (next step of implementation with FW 1.2)

Pre-Conditions

  • One context is selected.
  • The context is in the state “created” or “opened”.
  • The context belongs to an OU where the user has administrative rights for.

Flow of Events

  1. The user chooses to edit the selected context or the context was selected by a previous use case.
  2. The system displays the context edit view.
  3. (Optionally) The user adds other open organizational units for which the user has administrative rights for.
  4. (Optionally) The user edits the context attributes (NAME, TYPE, DESCRIPTION, VALIDATION SCHEMA, WORKFLOW, CONTACT EMAIL, GENRES).
    4.1. The system checks if items in the selected context exist with a genre not listed as an allowed genre. (This should prevent that a genre type is deselected, but items with this genre type already exist in this context)
    • a. No items exist.
    • b. At least one item exists. The system displays an error message. Continue with 4.
  5. (Optionally) Extension point: UC_LA_CM_06 Configure workflows for context
  6. (Optionally) Extension point: UC_LA_CM_07 Configure validation schema for a context
  7. (Optionally) Extension point: UC_LA_PM_01 Edit context preferences
  8. (Optionally) Extension point: UC_LA_CM_08 Grant rights to a context
  9. The user chooses to confirm the input. - The system stores the data and displays a success message. The use case ends successfully.

Post-Conditions / Results

  • The context data is saved.

Additional Information

  • A matrix of Context Management actions can be found here

Open Questions

  • Defining the Genres is very pubman specific. perhaps this choice is only given when TYPE= PubMan?.

UC_LA_CM_03 Open context[edit]

Change the status of a context to "open".

Status/Schedule

  • Status: in specification
  • Schedule:tbd

Triggers

  • The user wants to open a context for submission.

Actors

  • System Administrator (current state of implementation)
  • Context Administrator (next step of implementation with FW 1.2)
  • Context Modifier (next step of implementation with FW 1.2)

Pre-Conditions

  • One context is selected where the user has administrative rights for.
  • The context is in the state “created” or “closed”.

Flow of Events

  1. The user chooses to open a context.
  2. The system prompts the user to confirm the opening of the context.
    2.1. The user confirms to open the context.
    2.2. The user does not confirm to open the context. - The selected context is unaffected. The use case ends without success.
  3. The system changes the state of the context to “opened” and displays a success message. The use case ends successfully.

Post-Conditions / Results

  • The context is in the state “opened”.

Open Questions

  • What other preconditions? That validation rules are assigned? That a workflow is assigned?

UC_LA_CM_04 Close a context[edit]

Change the status of a context to "closed".

Status/Schedule

  • Status: in specification
  • Schedule:tbd

Triggers

  • The user wants to close a context, because it should no longer be available for new submissions.

Actors

  • System Administrator (current state of implementation)
  • Context Administrator (next step of implementation with FW 1.2)
  • Context Modifier (next step of implementation with FW 1.2)

Pre-Conditions

  • One context is selected where the user has administrative rights for.
  • The context is in the state “opened”.

Flow of Events

  1. The user chooses to close a context.
  2. The system prompts the user to confirm the closing of the context.
    2.1. The user confirms to close the context.
    2.2. The user does not confirm to close the context. - The selected context is unaffected. The use case ends without success.
  3. The systems changes the state of the context to “closed” and displays a success message. The use case ends successfully.

Post-Conditions / Results

  • The context is in the state “closed”.

UC_LA_CM_05 Delete a context[edit]

The user wants to delete a context.

Status/Schedule

  • Status: in specification
  • Schedule:tbd

Triggers

  • The user wants to delete a context, because it is no longer used.

Actors

  • System Administrator (current state of implementation)
  • Context Administrator (next step of implementation with FW 1.2)
  • Context Modifier (next step of implementation with FW 1.2)

Pre-Conditions

  • One context is selected where the user has administrative rights for.
  • The context is in state 'created'

Flow of Events

  1. The user chooses to delete a context.
  2. The user confirms to delete the context.
    2.1. The user does not confirm to delete the context. - The selected context is unaffected. The use case ends without success.
  3. The system deletes the context and displays a success message. The use case ends successfully.

Post-Conditions / Results

  • The context is deleted and no longer available for any system action.

UC_LA_CM_06 Configure workflows for context[edit]

The user configures the publication and modification workflows for a context.

Status/Schedule

  • Status: in specification
  • Schedule:tbd

Triggers

  • The user wants to configure the workflows for a context.
  • Integrated in: UC_LA_CM_02 Edit context.

Actors

  • System Administrator (current state of implementation)
  • Context Administrator (next step of implementation with FW 1.2)
  • Context Modifier (next step of implementation with FW 1.2)

Pre-Conditions

  • One context is selected where the user has administrative rights for.
  • The context is in state “created”

Flow of Events

  1. The system displays the lists of available workflows.
  2. (Optionally) The user changes the desired workflow.
  3. The system prompts for the confirmation of the workflow changes.
    3.1. The user chooses to confirm the selection.
    3.2. The user does not confirm the workflow selection for the context. - The selected context is unaffected. The use case ends without success.
  4. The system stores the selected workflows as defined for the context and displays a success message. The use case ends successfully.

Post-Conditions / Results

  • A workflow for the context is saved.

UC_LA_CM_07 Configure validation schema for a context[edit]

The user assigns a validation schema to a context.

Status/Schedule

  • Status: in specification
  • Schedule:tbd

Triggers

  • The user wants to assigns a validation schema to a context.
  • Integrated in: UC_LA_CM_02 Edit context.

Actors

  • System Administrator (current state of implementation)
  • Context Administrator (next step of implementation with FW 1.2)
  • Context Modifier (next step of implementation with FW 1.2)

Pre-Conditions

  • One context is selected where the user has administrative rights for.
  • The context is in state "created".

Flow of Events

  1. The system displays the lists of available, predefined validation schemas, the user can select one validation schema.
  2. The system prompts to confirm the change of the validation schema.
    2.1. The user chooses to confirm the selection.
    2.2. The user does not confirm the validation schema selection for the context. - The selected context is unaffected. The use case ends without success.
  3. The system assigns the validation schema to the selected context and displays a success message. The use case ends successfully.

Post-Conditions / Results

  • The validation schema is assigned to the context.

UC_LA_CM_08 Grant rights to a context[edit]

The user assigns different rights to a context.

Status/Schedule

  • Status: in specification
  • Schedule:tbd

Triggers

  • The user wants to assign rights to a context.
  • Integrated in: UC_LA_CM_02 Edit context.

Actors

  • System Administrator (current state of implementation)
  • Context Administrator (next step of implementation with FW 1.2)

Pre-Conditions

  • One context is selected where the user has administrative rights for.
  • The context is in state "created".

Flow of Events

  1. The system displays the lists of all possible roles on context level (currently only Context Administrator for System Administrators or Context Modifier for Context Administrators).
  2. The user chooses to add this role.
  3. The user chooses one or more users he wants to grant the role.
  4. The systems prompts for conformation of the data.
  5. The system assigns selected role to the selected users and displays a success message. The use case ends successfully.

Post-Conditions / Results

  • New grants are added to the context

Organization Management[edit]

For cross-checking, please see also: PubMan_Func_Spec_Organizational_Unit_Management#General_rules

UC_LA_OUM_01 Create organizational unit[edit]

The user creates a new organizational unit and specifies the position in the organizational unit structure.

Status/Schedule

  • Status: in specification
  • Schedule:tbd

Triggers

  • The user wants to create a new organizational unit.

Actors

  • System Administrator (current state of implementation)
  • Organizational Unit Administrator (next step of implementation with FW 1.3)

Pre-Conditions

  • The user can only create an organizational unit as children of the organizational unit he has administrative rights for.

Flow of Events

  1. The user chooses to create an organizational unit.
  2. The system displays an organizational unit details view.
  3. The user enters the data for the new organizational unit. The following data can be entered: TITLE, ALTERNATIVE TITLE, DESCRIPTION, ORGANIZATION TYPE, CITY, COUNTRY, COORDINATES, START_DATE, END_DATE.
  4. The user selects one parent organizational units in the organizational unit structure (he can only choose OUs where he has administrative rights for).
  5. (Optionally) Extension Point: UC_PM_OUM_06 Add predecessor to organizational unit
  6. (Optionally) Extension Point: UC_LA_OUM_07 Add successor of an organizational unit
  7. (Optionally) Extension Point: UC_LA_PM_02 Edit organizational unit preferences
  8. The user confirms the creation.
  9. The system checks if an organizational unit with the given name already exists under the same parent.
    9.1. An organizational unit with the given name does not exist under the same parent.
    9.2. Otherwise the system displays an error message, continue with 3.
  10. The system creates and stores a new organizational unit in state “created” and the relations to the parent organizational units. The system displays a success message. The use case ends successfully.

Post-Conditions / Results

  • The new organizational unit in the state “created” is created.

UC_LA_OUM_02 Open organizational unit[edit]

The user opens an organizational unit with state "created".

Status/Schedule

  • Status: in specification
  • Schedule:tbd

Triggers

  • The user wants to set an organizational unit to state "opened".

Actors

  • System Administrator (current state of implementation)
  • Organizational Unit Administrator (next step of implementation with FW 1.3)

Pre-Conditions

  • One organizational unit is selected where the user has administrative rights for
  • The selected organizational unit is in status "created"
  • If there is a parent organizational unit, the parent organizational unit is in status "opened"

Flow of Events

  1. The user chooses an organizational unit to change its state to "opened".
  2. The system displays an organizational unit details view.
  3. (Optionally) Extension point: UC_LA_OUM_03 Edit organizational unit
  4. The user confirms the opening.
  5. The system stores the changes and set the organizational unit to state “open”. The system displays a success message. The use case ends successfully.

Post-Conditions / Results

  • The state of the organizational unit is set to “opened”.

UC_LA_OUM_03 Edit organizational unit[edit]

The user changes data of an organizational unit.

Status/Schedule

  • Status: in specification
  • Schedule:tbd

Triggers

  • The user wants to edit the data of an organizational unit.
  • Integrated in: UC_LA_OUM_01 Create organizational unit
  • Integrated in: UC_LA_AS_04 View organizational unit list

Actors

  • System Administrator (current state of implementation)
  • Organizational Unit Administrator (next step of implementation with FW 1.3)

Pre-Conditions

  • An organizational unit is selected where the user has administrative rights for.

Flow of Events

  1. The user chooses to edit the selected organizational unit.
  2. The system displays the details of the selected organizational unit in an edit view.
  3. (Optionally) The user changes the data for the organizational unit.
  4. Optionally) If organizational unit is in status "created" the user changes the parent organizational unit.
    4.1. The system displays a list of organizational units, the user has administrative rights for
  5. (Optionally) Extension Point: UC_PM_OUM_06 Add predecessor to organizational unit
  6. (Optionally) Extension Point: UC_LA_OUM_07 Add successor of an organizational unit
  7. (Optionally) Extension Point: UC_LA_PM_02 Edit organizational unit preferences
  8. The user confirms the changes.
  9. The system stores the changes and displays a success message. The use case ends successfully.

Post-Conditions / Results

  • Modifications of the selected organizational unit are saved.

Additional Information

  • A matrix of Organizational Unit Management actions can be found here

UC_LA_OUM_04 Close organizational unit[edit]

The user closes an organizational unit.

Status/Schedule

  • Status: in specification
  • Schedule:tbd

Triggers

  • The user wants to close an organizational unit.

Actors

  • System Administrator (current state of implementation)
  • Organizational Unit Administrator (next step of implementation with FW 1.3)

Pre-Conditions

  • An organizational unit is selected where the user has administrative rights for.
  • Selected organizational unit is in status "opened"

Flow of Events

  1. The user chooses to close the selected organizational unit.
  2. The system displays the details of the selected organizational unit in an edit view.
  3. The system checks if there are children of this OU in state "open"
    3.1. If there are children of the OU in state "open", the system prompts a message that all children will be closed as well
    • a The user confirms the closure of all child OUs. Continue with 6.
    • b The user does not confirm the closure of all child OUs. Continue with 2. and display error message.
  4. The user confirms the operation of closure of organizational unit.
  5. The system changes the state of the organizational unit to "closed" and displays a success message. The use case ends successfully.

Post-Conditions / Results

  • The organizational unit with all children are closed.

UC_LA_OUM_05 Delete organizational unit[edit]

The user deletes an organizational unit.

Status/Schedule

  • Status: in specification
  • Schedule:tbd

Triggers

  • The user wants to delete an organizational unit.

Actors

  • System Administrator
  • Organizational Unit Administrator (next step of implementation with FW 1.3)

Pre-Conditions

  • One organizational unit is selected where the user has administrative rights for.
  • The selected organizational unit is in status "created"

Flow of Events

  1. The user chooses to delete the selected organizational unit.
  2. The system displays the details of the selected organizational unit in an edit view.
  3. The system checks if the selected OU has child OUs
    3.1. The selected OU has only child OUs in state "created" or no child OUs. The system prompts a message that all child OUs will be deleted as well.
    3.2. The selected OU has child OUs in other states than "created". The system prompts an error message, continue with 2.
  4. The user confirms the deletion.
  5. The system stores the changes and displays a success message. The use case ends successfully.

Post-Conditions / Results

  • The organizational unit with children is deleted.

UC_LA_OUM_06 Add predecessor to an organizational unit[edit]

The user adds a predecessor to an organizational unit.

Status/Schedule

  • Status: in specification
  • Schedule:tbd

Triggers

  • The user wants to add a predecessor to an organizational unit.
  • Integrated in: UC_LA_OUM_01 Create organizational unit
  • Integrated in: UC_LA_OUM_02 Edit organizational unit

Actors

  • System Administrator (current state of implementation)
  • Organizational Unit Administrator (next step of implementation with FW 1.3)

Pre-Conditions

  • An organizational unit to which predecessor should be added is selected
  • The user administrative rights for the selected OU.

Flow of Events

  1. The user chooses to add a predecessor to the selected organizational unit.
  2. The system displays the details of the selected organizational unit in an edit view.
  3. The system displays a list with all organizational units. The user selects one or more organizational units in status "opened" or "closed" to specify them as predecessors for the selected organizational unit.
  4. The user specifies the type of relation (FUSION, REPLACEMENT, SPLITTING, SPIN-OFF, AFFILIATION) of the predecessor organizational unit to the organizational unit she is editing.
  5. The user confirms the change. The system saves the change and displays a success message. The use case ends successfully.

Post-Conditions / Results

  • A predecessor is added to the organizational unit. All predecessors and successors (derived from other predecessor relations) of the organizational unit are shown in the organizational unit edit view and organizational unit detail view.

UC_LA_OUM_07 Add successor of an organizational unit[edit]

The user adds a successor of an organizational unit.

Status/Schedule

  • Status: in specification
  • Schedule:tbd

Triggers

  • The user wants to add a successor to an organizational unit.
  • Integrated in: UC_LA_OUM_01 Create organizational unit
  • Integrated in: UC_LA_OUM_02 Edit organizational unit

Actors

  • System Administrator (current state of implementation)
  • Organizational Unit Administrator (next step of implementation with FW 1.3)

Pre-Conditions

Flow of Events


Post-Conditions / Results

Preferences Management[edit]

This section is a loose idea collection for start.

UC_LA_PM_01 Edit context preferences[edit]

The user wants to edit system preferences for a context

Status/Schedule

  • Status: idea
  • Schedule: tbd

Actors Involved

  • System Administrator
  • Context Administrator
  • Context Modifier

Prerequisites

  • The user chooses a context where he has administrative rights for.

Ideas

  • Customization of submission mask (very PubMan specific)
  • Integration of Cone (yes/no)
  • Display of special metadata (e.g. GPS Coordinates) (yes/no)
  • Set allowed submission methods (easy, full, import, batch import)
  • Set allowed import sources (e.g. arxiv, biomed, all)

UC_LA_PM_02 Edit organizational unit preferences[edit]

The user wants to edit system preferences for an organizational unit

Status/Schedule

  • Status: idea
  • Schedule: tbd

Actors Involved

  • System Administrator
  • Organizational Unit Administrator

Prerequisites

  • The user chooses a context where he has administrative rights for.

Ideas

  • Customization of skin (what to do if user has more org units?)
  • Customization of the text of emails, send to account users (welcome email, pwd change email)

UC_LA_PM_03 Edit user preferences[edit]

The user wants to edit system preferences for a specific user.

See also User Management

Status/Schedule

  • Status: idea
  • Schedule: tbd

Actors Involved

  • System Administrator
  • User Administrator

Prerequisites

  • The user chooses a context where he has administrative rights for.

Ideas

  • Pre filled entry masks (yes/no) with the user as author
  • Pre filled entry mask of favourite co authors

Administrative Search[edit]

UC_LA_AS_01 View account users list[edit]

The user wants to overview all account users he is allowed to manage.

Status/Schedule

  • Status: in specification
  • Schedule: tbd

Actors Involved

  • System Administrator
  • Local Administrator

Flow of Events

  1. The user chooses to overview all account users.
  2. The system displays the list of all account users, the user has local administrator privileges for, and the number of list entries. In this list is following information displayed about each account user: LOGIN NAME, NAME (family name, given name), ORGANIZATIONAL UNIT, STATE, ROLE with CONTEXT, DATE LAST MODIFIED. The defaults for the sorting order and the number of hits per page are given by the system (by default: sorted by name (alphabetically), number of hits per page: 10).
  3. (Optionally) The user changes the sorting order (it should be possible to sort the list by all columns available in the list).
    3.1 The system displays the account user list in the selected sorting order.
  4. (Optionally) The user chooses another number of hits per page.
    4.1 The system displays the account user list containing the selected number of hits per page.
  5. (Optionally) The user goes to a special page, to the last page or to the first page.
    5.1 The system displays the selected page.
  6. Extension point: edit account user
    6.1 If the user wants to edit a selected account user, include UC_LA_UM_02 Edit account user.
  7. Extension point: deactivate account user
    7.1 If the user wants to deactivate a selected account user, include UC_LA_UM_04 Deactivate account user.
  8. The use case ends successfully.

UC_LA_AS_02 View user groups list[edit]

The user wants to overview all user groups he can manage.

Status/Schedule

  • Status: in specification
  • Schedule: tbd

Actors Involved

  • System Administrator
  • Local Administrator

Flow of Events

  1. The user chooses to overview all user groups.
  2. The system displays the list of all account user groups (sorted per default alphabetically), the user has local administrator privileges for, and the number of list entries. In this list is following information displayed about each account user group: NAME, TYPE, DESCRIPTION, STATE, ROLE with CONTEXT, DATE LAST MODIFIED
  3. (Optionally) The user changes the sorting order (it should be possible to sort the list by all columns available in the list).
  4. (Optionally) The user chooses another number of hits per page.
  5. (Optionally) The user goes to a special page, to the last page or to the first page.
  6. (Optionally) Extension point: UC_LA_UM_07 Edit user group


UC_LA_AS_03 View contexts list[edit]

The user wants to overview all contexts he can manage.

Status/Schedule

  • Status: in specification
  • Schedule: tbd

Actors Involved

  • System Administrator
  • Local Administrator

Flow of Events

  1. The user chooses to overview all contexts he is a local administrator for.
  2. The system displays the list of all contexts, the user has local administrator privileges for, and the number of list entries. In this list is following information displayed about each context: NAME, DESCRIPTION, ORGANIZATIONAL UNIT, STATUS, DATE LAST MODIFIED
  3. (Optionally) The user changes the sorting order (it should be possible to sort the list by all columns available in the list).
  4. (Optionally) The user chooses another number of hits per page.
  5. (Optionally) The user goes to a special page, to the last page or to the first page.
  6. (Optionally) Extension point: UC_LA_CM_02 Edit context


UC_LA_AS_04 View organizational unit list[edit]

The user wants to overview all organizational units he can manage.

Status/Schedule

  • Status: in specification
  • Schedule: tbd

Actors Involved

  • System Administrator
  • Local Administrator

Flow of Events

  1. The user chooses to overview all organizational unit the user has local administrator privileges for.
  2. The system displays the tree of all organizational units with information on: NAME, DESCRIPTION (link), STATE, DATE LAST MODIFIED
  3. (Optionally) Extension point: UC_LA_OUM_03 Edit organizational unit
  4. (Optionally) Extension point: UC_LA_OUM_06 Add predecessor to an organizational unit
  5. (Optionally) Extension point: UC_LA_OUM_07 Add successor of an organizational unit


UC_LA_AS_05 View user groups list for account user[edit]

The user wants to overview all user groups, a user is member of.

Status/Schedule

  • Status: in specification
  • Schedule: tbd

Actors Involved

  • System Administrator
  • Local Administrator
  • User

Triggers

  • Included in: UC_LA_UM_02 Edit account user

Flow of Events

  1. The user chooses to overview all user groups of a selected account user. The user has local administrator privileges for this account user or is the account user itself.
  2. The system displays the list of all user groups (sorted per default alphabetically), where this selected account user is member of, and the number of list entries. In this list is following information displayed about each account user group: NAME, TYPE, DESCRIPTION, STATE, ROLE with CONTEXT, DATE LAST MODIFIED
  3. (Optionally) The user changes the sorting order (it should be possible to sort the list by all columns available in the list).
  4. (Optionally) The user chooses another number of hits per page.
  5. (Optionally) The user goes to a special page, to the last page or to the first page.

UC_LA_AS_06 Simple Search[edit]

The user wants to perform a simple search for objects within the administrative solution.

Status/Schedule

  • Status: in specification
  • Schedule: tbd

Actors Involved

  • System Administrator
  • Local Administrator

Triggers

  • The user chooses to perform a search.

Flow of Events

  1. The user enters an arbitrary search term in the simple search text field and submits.
  2. The system performs a search of all objects the user has 'local administrator' rights for, on the indexes: TBD
    2.1. One or more objects were found, continue with 3.
    2.2. No object was found, the system displays an error message.
  3. The system displays a search result list with the following information: NAME, TYPE (User, User Group, Context, OU), DATE LAST MODIFIED
  4. (Optionally) The user changes the sorting order (it should be possible to sort the list by all columns available in the list).
  5. (Optionally) The user chooses another number of hits per page.
  6. (Optionally) The user goes to a special page, to the last page or to the first page.
  7. (Optionally) The list can be filtered for object type USER, CONTEXT, ORGANIZATIONAL UNIT.
  8. (Optionally) Extension point: UC_LA_UM_02 Edit account user
  9. (Optionally) Extension point: UC_LA_UM_07 Edit user group
  10. (Optionally) Extension point: UC_LA_CM_02 Edit context
  11. (Optionally) Extension point: UC_LA_OUM_03 Edit organizational unit
  12. The use case ends successfully.

Open Question

  • Does it makes sense to display such a mixed list? It can happen that the user will not see in which field his search term was found (e.g. OU description).
    • Is it possible to add one field 'search term' to each row, which indicates in which field the search term was found?

UC_LA_AS_07 Advanced Search[edit]

The user wants to perform an advanced search for objects within the administrative solution.

Status/Schedule

  • Status: in specification
  • Schedule: tbd

Actors Involved

  • System Administrator
  • Local Administrator

Triggers

  • The user chooses to perform a search.

Flow of Events

  1. The user can search for:
    USER NAME, USER EMAIL, USER LOGIN_NAME, USER GROUP NAME
    OU TITLE, OU DESCRIPTION, OU STATE
    CONTEXT NAME, CONTEXT DESCRIPTION
  2. The system performs a search of all objects the user has 'local administrator' rights for, on the corresponding indexes.
    2.1. One or more objects were found, continue with 3.
    2.2. No object was found, the system displays an error message.
  3. The system displays a search result list with the following information: NAME, TYPE (User, User Group, Context, OU), DATE LAST MODIFIED
  4. (Optionally) The user changes the sorting order (it should be possible to sort the list by all columns available in the list).
  5. (Optionally) The user chooses another number of hits per page.
  6. (Optionally) The user goes to a special page, to the last page or to the first page.
  7. (Optionally) The list can be filtered for object type USER, CONTEXT, ORGANIZATIONAL UNIT.
  8. (Optionally) Extension point: UC_LA_UM_02 Edit account user
  9. (Optionally) Extension point: UC_LA_UM_07 Edit user group
  10. (Optionally) Extension point: UC_LA_CM_02 Edit context
  11. (Optionally) Extension point: UC_LA_OUM_03 Edit organizational unit
  12. The use case ends successfully.

Open Question

  • Same as simple search, mixed list problematic?

States[edit]

User[edit]

  • Active - The user is allowed to perform any actions his assigned privileges allow him to.
  • Inactive - A user account has been set to inactive. The user is not allowed to perform any actions.
  • Created - The initial state of a user. A user is known to the system, but he has not agreed to the terms of condition yet though he is not allowed to perform any actions.

Context[edit]

  • Open - The context is open and items can be submitted to it.
  • Closed - A context is not longer available for any actions in the solutions.
  • Created - The initial state of a context. The context was created, but not yet opened.

Organizational Unit[edit]

  • Open - The organizational unit is open persons and contexts can be assigned to it.
  • Closed - An organizational unit is not longer available for any actions.
  • Created - The initial state of an organizational unit. The organizational unit was created, but not yet opened.

Additional Information[edit]

eSciDoc Administrative Roles[edit]

A description of the eSciDoc administrative roles which are referenced in his specification can be found here.

Solution Specific Specifications[edit]

Use Case

Lightweight Directory Access Protocol

Coordinated Universal Time

Logging-in system for computer networks

Organizational Unit

Publication Management

Global Positioning System

To Be Defined

Enhanced Scientific Documentation

Virtueller Raum Reichsrecht

Retrieved from "https://colab.mpdl.mpg.de/mw010/index.php?title=Func_Spec_Admin&oldid=88416"