Func Spec Admin

This page will contain the specification of local administration for eSciDoc solutions.

User Management

UC_LA_UM_01 Create account user

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

• Local Administrator

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 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 user specifies: NAME, LOGIN_NAME, EMAIL
• 6. The system checks if an account user with the given login_name already exists.
  • 6.1. An account user with the given user-id does not exist in the system.
  • 6.2. Otherwise the system displays an error message, continue with 5.
• 7. (Optionally) Extension Point: UC_LA_PM_03 Edit user preferences
• 8. 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 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 local administrator 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.

UC_LA_UM_02 Edit account user

The user changes data of an account user.

Status/Schedule

• Status: in specification
• Schedule:tbd

Triggers

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

• Local Administrator

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 the privileges as “Local Administrator”.

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.
• 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 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 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.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_PM_03 Edit user preferences
• 7. The use case ends successfully.

Post-Conditions / Results

• The data for the account user is stored.

UC_LA_UM_03 Assign privileges to account user

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.

Actors

• Local Administrator

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 the privileges as “Local Administrator”.

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

Post-Conditions / Results

• The privileges are stored.

Additional Information

• What privileges a local administrator may assign are described in the action matrix

UC_LA_UM_04 Delete/inactivate 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”, in this case a user can only be set inactive.

Status/Schedule

• Status: in specification
• Schedule:tbd

Triggers

• The user wants to delete/deactivate an account user.

Actors

• Local Administrator

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 the privileges as “Local Administrator”.

Flow of Events

• 1. The system asks the user if the selected account user should be deleted.
• 2. The system checks if the selected user owns items in any other state than “pending”.
  • 2.1. No item in state “pending” exists. Continue with 5.
  • 2.2. One or more items in state “pending” exist. Continue with 3.
• 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.
  • 3.1. The user confirms to delete the account user and the “pending” items. All pending items are deleted. Continue with 4.
  • 3.2. The user does not confirm to delete the account user and the items. The selected account user and the “pending” items are unaffected. The use case ends without success.
• 4. The account user, the preferences and the privileges are deleted, a success message is displayed. The use case ends successfully.
• 5. Alternative: The system asks the user if the selected account user should be set "inactive".
  • 5.1. The user confirms this. All privileges are revoked from the user. If the user has items in state "pending" continue with 3.
  • 5.2. The user does not confirm this. The user is redirected to the selected user edit page.

Post-Conditions / Results

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

UC_LA_UM_05 Activate user

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

• User

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?)
• Is the user allowed to edit his data, or only the local administrator? If the user is allowed to edit his data, which kind of data?

UC_LA_UM_06 Create user group

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

• Local Administrator

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 is 'local administrator' for)
• one or more users by entering their user name (only users where he is 'local administrator' for)
• one or more user groups (only user groups where he is 'local administrator' for)
• 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. 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)

UC_LA_UM_07 Edit user group

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

• Local Administrator

Pre-Conditions

• The user has the privilege 'local administrator' 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 is 'local administrator' for)
• one or more users by entering their user name (only users where he is 'local administrator' for)
• one or more user groups (only user groups where he is 'local administrator' for)
• one or more user attributes (provided via Shibboleth)

• 4. The user saves the changes of the user group.

Context Management

UC_LA_CM_01 Create a context

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

• Local Administrator

Pre-Conditions

• None

Flow of Events

• 1. The user chooses to create a new context.
• 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 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

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

• Local Administrator

Pre-Conditions

• One context is selected (*).
• The context is in the state “created” or “opened”.

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 the privileges as local administrator.
• 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 Assign validation rules to a context
• 7. (Optionally) Extension point: UC_LA_PM_01 Edit context preferences
• 8. 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.

Open Questions

• (*) Can a user only change a context where he is 'local administrator' for, or only contexts he created?
• Defining the Genres is very pubman specific. perhaps this choice is only given when TYPE= PubMan?.

UC_LA_CM_03 Open context

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

• Local Administrator

Pre-Conditions

• One context is selected where the user is 'local administrator' 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

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

• Local Administrator

Pre-Conditions

• One context is selected where the user is 'local administrator' 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

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

• Local Administrator

Pre-Conditions

• One context is selected where the user has privileges as "Local Administrator".
• The context contains only items in state “pending”.

Flow of Events

• 1. The user chooses to delete a context.
• 2. The system displays a list of all “pending” items and prompts the user to confirm the deleting of the context and the items.
  • 2.1. The user confirms to delete the context and the “pending” items.
  • 2.2. The user does not confirm to delete the context and the items. - The selected context and the “pending” items are unaffected. The use case ends without success.
• 3. The system deletes the items as well as the context and displays a success message. The use case ends successfully.

Post-Conditions / Results

• The context and all items in state “pending” are deleted and no longer available for any system action.

UC_LA_CM_06 Configure workflows for context

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

• Local Administrator

Pre-Conditions

• One context is selected where is user is 'local administrator' for.
• The context is in state “created”

Flow of Events

• 1. The system displays the lists of available publication and modification workflows.
• 2. (Optionally) The user changes the desired publication workflow.
• 3. (Optionally) The user changes the desired modification workflow.
• 4. The system prompts for the confirmation of the workflow changes.
  • 4.1. The user chooses to confirm the selection.
  • 4.2. The user does not confirm the workflow selection for the context. - The selected context is unaffected. The use case ends without success.
• 5. 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 publication and a modification workflow for the context is saved.

UC_LA_CM_07 Assign validation rules to a context

The user assigns pre-defined validation rules to a context.

Status/Schedule

• Status: in specification
• Schedule:tbd

Triggers

• The user wants to assigns pre-defined validation rules to a context.
• Integrated in: UC_LA_CM_02 Edit context.

Actors

• Local Administrator

Pre-Conditions

• One context is selected where the user is 'local administrator' for.
• The context is in state "created".

Flow of Events

• 1. The system displays the lists of available, predefined validation rules.
• 2. The system prompts to confirm the changes in the validation rules.
  • 2.1. The user chooses to confirm the selection.
  • 2.2. The user does not confirm the validation rule selection for the context. - The selected context is unaffected. The use case ends without success.
• 3. The system assigns the validation rules to the selected context and displays a success message. The use case ends successfully.

Post-Conditions / Results

• The validation rules are assigned to the context.

Organization Management

UC_LA_OUM_01 Create organizational unit

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

• Local Administrator

Pre-Conditions

• The user can only create an organizational unit as children of the organizational unit he is local administrator 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 or more parent organizational units in the organizational unit structure.
• 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.

Open Questions

• What happens if a user selects more parent organizational units... for a OU?

UC_LA_OUM_02 Open organizational unit

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

• Local Administrator

Pre-Conditions

• One organizational unit is selected where the user is local administrator 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

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

• Local Administrator

Pre-Conditions

• An organizational unit is selected where the user is 'local administrator' 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 is 'local administrator' to
• 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 to the selected organizational unit are saved.

UC_LA_OUM_04 Close organizational unit

The user closes an organizational unit.

Status/Schedule

• Status: in specification
• Schedule:tbd

Triggers

• The user wants to close an organizational unit.

Actors

• Local Administrator

Pre-Conditions

• An organizational unit is selected where the user has 'local administrator' privileges 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

The user deletes an organizational unit.

Status/Schedule

• Status: in specification
• Schedule:tbd

Triggers

• The user wants to delete an organizational unit.

Actors

• Local Administrator

Pre-Conditions

• One organizational unit is selected where the user is 'local administrator' 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

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

• Local Administrator

Pre-Conditions

• An organizational unit to which predecessor should be added is selected

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

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

• Local Administrator

Pre-Conditions

Flow of Events

Post-Conditions / Results

Preferences Management

This section is a loose idea collection for start.

UC_LA_PM_01 Edit context preferences

The user wants to edit system preferences for a context

Status/Schedule

• Status: idea
• Schedule: tbd

Actors Involved

• Local Administrator

Prerequisites

• The user chooses a context where he has local administrator 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

The user wants to edit system preferences for an organizational unit

Status/Schedule

• Status: idea
• Schedule: tbd

Actors Involved

• Local Administrator

Prerequisites

• The user chooses a context where he has local administrator 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

The user wants to edit system preferences for a specific user

Status/Schedule

• Status: idea
• Schedule: tbd

Actors Involved

• Local Administrator

Prerequisites

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

Ideas

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

Administrative Search

UC_LA_AS_01 View account users list

The user wants to overview all account users he can manage.

Status/Schedule

• Status: in specification
• Schedule: tbd

Actors Involved

• Local Administrator

Flow of Events

1. The user chooses to overview all account users.
2. The system displays the list of all account users (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: LOGIN NAME, NAME (family name, given name), ORGANIZATIONAL UNIT, 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_02 Edit account user

UC_LA_AS_02 View account user groups list

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

Status/Schedule

• Status: in specification
• Schedule: tbd

Actors Involved

• Local Administrator

Flow of Events

1. The user chooses to overview all account 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

The user wants to overview all contexts he can manage.

Status/Schedule

• Status: in specification
• Schedule: tbd

Actors Involved

• 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

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

Status/Schedule

• Status: in specification
• Schedule: tbd

Actors Involved

• 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

States

User

1. Active - The user is allowed to perform any actions his assigned privileges allow him to.
2. Inactive - A user account has been set to inactive. The user is not allowed to perform any actions.
3. 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

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

Organizational Unit

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

Additional Information

• The privileges of a local administrator are related to an organizational unit.
• There is a more detailed matrix of allowed actions, comparing administrators and local administrators (--work in progress--)

Solution Specific Specifications

• PubMan
  • http://colab.mpdl.mpg.de/mediawiki/PubMan_Func_Spec_Collection_Administration
  • http://colab.mpdl.mpg.de/mediawiki/PubMan_History_of_affiliations#History_of_affiliation_in_organizational_unit_management
  • http://colab.mpdl.mpg.de/mediawiki/PubMan_Func_Spec_Organizational_Unit_Management
  • http://colab.mpdl.mpg.de/mediawiki/PubMan_Func_Spec_User_Management
• FACES
  • http://colab.mpdl.mpg.de/mediawiki/Faces_User_Management
• ViRR
  • http://colab.mpdl.mpg.de/mediawiki/ViRR_User_Management

Enhanced Scientific Documentation

Use Case

Lightweight Directory Access Protocol

Logging-in system for computer networks

Organizational Unit

Publication Management

Global Positioning System

Virtueller Raum Reichsrecht