Difference between revisions of "Func Spec Admin"

From MPDLMediaWiki
Jump to navigation Jump to search
m (Reverted edits by Kleinfercher (talk) to last revision by Kristina)
 
(118 intermediate revisions by 3 users not shown)
Line 1: Line 1:
This page will contain the specification of local administration for eSciDoc solutions.
==User Management==
==User Management==


Line 8: Line 6:
'''Status/Schedule'''
'''Status/Schedule'''
*Status: '''in specification'''
*Status: '''in specification'''
*Schedule:'''6.1'''
*Schedule:'''tbd'''


'''Triggers'''  
'''Triggers'''  
Line 14: Line 12:


'''Actors'''  
'''Actors'''  
*Local Administrator
* System Administrator (current state of implementation)
* ''User Administrator (future scenario)''


'''Pre-Conditions'''
'''Pre-Conditions'''
Line 21: Line 20:
'''Flow of Events'''  
'''Flow of Events'''  


*1. The user chooses to create an account user.
# 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”.
# 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.
# Optionally) The user chooses to view the organizational unit description.
**3.1. The system displays the organizational unit description.
#: 3.1. The system displays the organizational unit description.
*4. The user selects one organizational unit and confirms the choice.
# The user selects one organizational unit and confirms the choice.
*5. The user specifies: NAME, LOGIN_NAME, EMAIL  
# The system displays the account user edit view.  
*6. The system checks if an account user with the given login_name already exists.
# The user specifies: NAME, LOGIN_NAME, EMAIL  
**6.1. An account user with the given user-id does not exist in the system.  
# The system checks if an account user with the given login_name already exists.
**6.2. Otherwise the system displays an error message, continue with 5.
#: 7.1. An account user with the given login_name does not exist in the system.  
*7.    (Optionally) ''Extension Point:'' '''UC_LA_PM_03 Edit user preferences'''
#: 7.2. Otherwise the system displays an error message, continue with 6.
*8. The system creates and stores a new account user in the state inactive and sets the timestamp of creation.  
# ''Extension Point:'' '''edit user preferences'''  
:      The user preferences are populated with the system defaults (if not set via UC_LA_PM_03).  
#: 8.1. If the user wants to edit the default user preferences, include [[Func_Spec_Admin#UC_LA_PM_03_Edit_user_preferences|UC_LA_PM_03 Edit user preferences]].
:      The system sets a password for this user.
# The system creates and stores a new account user in the state inactive and sets the timestamp of creation.  
:      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 local administrator who has created the new account user is used as reply-to.  
#* The user preferences are populated with the system defaults (if not set via UC_LA_PM_03).  
:      The system displays a success message. The use case ends successfully.
#* 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'''
'''Post-Conditions / Results'''
*A new account user in the state inactive is created and a confirmation request via e-mail is sent.
*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
*# '''Name:''' family name, given name (will automatically be used as author of an own album)
*# Valid '''E-Mail address''' (to receive system notifications during the scenario [[Faces_Album_Management#Sharing_of_an_album|"Sharing of an album"]])


===UC_LA_UM_02 Edit account user===
===UC_LA_UM_02 Edit account user===
Line 45: Line 52:
'''Status/Schedule'''
'''Status/Schedule'''
*Status: '''in specification'''
*Status: '''in specification'''
*Schedule:'''6.1'''
*Schedule:'''tbd'''


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


'''Actors'''
'''Actors'''
* Local Administrator
* System Administrator (current state of implementation)
* User
* ''User - own profile (future scenario)''
* ''User Administrator (future scenario)''


'''Pre-Conditions'''
'''Pre-Conditions'''
* The user management is local (no LDAP etc. involved)
* The user management is local (no LDAP etc. involved)
* An account user is selected.
* 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” or
* 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.  
* The selected account user is the user itself.


'''Flow of Events'''
'''Flow of Events'''
*1. The user chooses to edit the selected account user.
# The user chooses to edit the selected account user.
*2. The system displays the account user edit view.
# The system displays the account user edit view.
*3. (Optionally) The user edits: NAME, LOGIN_NAME, EMAIL.
# (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).
# (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.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.
#: 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  
#:: 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.
#:: 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.
# The user chooses 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.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.2. (Optionally) The user chooses to view the organizational unit description.
**5.3. The user selects one organizational unit and confirms the change..
#: 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.
#: 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'''
# (Optionally) ''Extension Point:'' '''UC_LA_UM_03 Assign privileges to account user'''  
*7.    (Optionally) ''Extension Point:'' '''UC_LA_PM_03 Edit user preferences'''
# (Optionally) ''Extension Point:'' '''UC_LA_PM_03 Edit user preferences'''  
*8.    (Optionally) ''Extension Point:'' '''UC_LA_UM_04 Deactivate account user'''
# (Optionally) ''Extension Point:'' '''UC_LA_UM_04 Deactivate account user'''
*9.    (Optionally) ''Extension Point:'' '''UC_LA_AS_05 View user groups list for user'''
# Optionally) ''Extension Point:'' '''UC_LA_AS_05 View user groups list for user'''  
*10. The use case ends successfully.
# The user confirms the changes. The use case ends successfully.


'''Post-Conditions / Results'''
'''Post-Conditions / Results'''
Line 87: Line 94:
'''Additional Information'''
'''Additional Information'''
* A matrix of User Management actions can be found [[Func_Spec_Local_Admin_Matrix#User%20Management | here]]
* A matrix of User Management actions can be found [[Func_Spec_Local_Admin_Matrix#User%20Management | here]]


'''Open Questions'''
'''Open Questions'''
* Who is allowed to edit what?
* 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. --[[User:Kristina|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.--[[User:Kleinfercher|Friederike]] 15:43, 17 February 2010 (UTC)


===UC_LA_UM_03 Assign privileges to account user===
===UC_LA_UM_03 Assign privileges to account user===
Line 96: Line 108:
'''Status/Schedule'''
'''Status/Schedule'''
*Status: '''in specification'''
*Status: '''in specification'''
*Schedule:'''6.1'''
*Schedule:'''tbd'''


'''Triggers'''
'''Triggers'''
Line 103: Line 115:


'''Actors'''
'''Actors'''
*Local Administrator
* System Administrator (current state of implementation)
* ''User Administrator (future scenario)''


'''Pre-Conditions'''
'''Pre-Conditions'''
*An account user is selected.
*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”.
*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'''
'''Flow of Events'''
*1. The user chooses to edit the assignment of privileges to the selected account user.
# The user chooses to edit the assignment of privileges to the selected account user.
*2. The system displays the privileges edit view.
# The system displays the privileges edit view.
*3. (Optionally) The user adds new privileges to the selected account user.
# Optionally) The user adds new privileges to the selected account user.
**3.1. The system displays a list of existing system roles and a list of all contexts the user is 'local administrator' for.
#: 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.
#: 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.
# (Optionally) The user edits a privilege for the selected account user.
**4.1. The system displays a list of all system roles and the related contexts the account user has.
#: 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
#: 4.2. The user can change the role and/ or the context of already existing privileges
*5. (Optionally) The user removes one privilege.
# (Optionally) The user removes one privilege.
**5.1. The system deletes the selected privilege and updates the privileges edit view.
#: 5.1. The system deletes the selected privilege and updates the privileges edit view.
*6. The user chooses to finalize the data.
# The user chooses to finalize the data.
*7. The system stores the privileges and displays a success message. The use case ends successfully.
# The system stores the privileges and displays a success message. The use case ends successfully.


'''Post-Conditions / Results'''
'''Post-Conditions / Results'''
Line 127: Line 140:


'''Additional Information'''
'''Additional Information'''
* What privileges a local administrator may assign are described in the [[Func_Spec_Local_Admin_Matrix | action matrix]]
* What privileges a administrative user may assign are described in the [[Func_Spec_Local_Admin_Matrix | action matrix]]


===UC_LA_UM_04 Deactivate account user===
===UC_LA_UM_04 Deactivate account user===
Line 134: Line 147:
'''Status/Schedule'''
'''Status/Schedule'''
*Status: '''in specification'''
*Status: '''in specification'''
*Schedule:'''6.1'''
*Schedule:'''tbd'''


'''Triggers'''
'''Triggers'''
Line 141: Line 154:


'''Actors'''
'''Actors'''
*Local Administrator
* System Administrator (current state of implementation)
* ''User Administrator (future scenario)''


'''Pre-Conditions'''
'''Pre-Conditions'''
*An account user is selected.
*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”.
*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'''
'''Flow of Events'''
*1. The system asks the user if the selected account user should be set deactivated.
# The user chooses to deactivate the selected user.  
*2.    The system asks the user if the selected account user to confirm the deactivation.  
# 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.
#: 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.
**2.2.  The user does not confirm this. The user is redirected to the selected user edit page.
#: 3.2.  The user does not confirm this. The user is redirected to the selected user edit page. The use case ends without success.  
*3.    The use case ends successfully.


'''Post-Conditions / Results'''
'''Post-Conditions / Results'''
*The account user state is set to 'inactive'.
*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. --[[User:Kristina|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.
*# 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)
*# 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===
===UC_LA_UM_05 Activate user===
Line 162: Line 187:
'''Status/Schedule'''
'''Status/Schedule'''
*Status: '''in specification'''
*Status: '''in specification'''
*Schedule:'''6.1'''
*Schedule:'''tbd'''


'''Triggers'''
'''Triggers'''
Line 168: Line 193:


'''Actors'''
'''Actors'''
*User
* System Administrator (current state of implementation)
* ''User (next step of implementation)''


'''Pre-Conditions'''
'''Pre-Conditions'''
Line 174: Line 200:


'''Flow of Events'''
'''Flow of Events'''
*1. The user chooses to activate the account by following the link from the confirmation request.
# 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.
# 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.
# (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.
# 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.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.
#: 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.
# 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.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.
#: 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'''
# (Optionally) ''Extension point:'' '''UC_LA_UM_02 Edit account user'''
*7. The use case ends successfully.
# The use case ends successfully.


'''Post-Conditions / Results'''
'''Post-Conditions / Results'''
Line 197: Line 223:
'''Status/Schedule'''
'''Status/Schedule'''
*Status: '''in specification'''
*Status: '''in specification'''
*Schedule:'''6.1'''
*Schedule:'''tbd'''


'''Triggers'''
'''Triggers'''
Line 203: Line 229:


'''Actors'''
'''Actors'''
*Local Administrator
* System Administrator (current state of implementation)
* ''UserGroup Administrator (next step of implementation FW 1.2)''


'''Pre-Conditions'''
'''Pre-Conditions'''
Line 210: Line 237:
'''Flow of Events'''
'''Flow of Events'''


*1. The user chooses to create a new user group
# The user chooses to create a new user group
*2. The user specifies a NAME, LABEL (short name), TYPE, DESCRIPTION for the user group.  
# The user specifies a NAME, LABEL (short name), TYPE, DESCRIPTION for the user group.  
*3.    The user saves the newly created user group.
# The user saves the newly created user group.
*4.    The system prompts for definition of the group selectors
# The system prompts for definition of the group selectors
*5.    The user defines the group selectors by choosing:  
# 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 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 is 'local administrator' 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 is 'local administrator' for)
#* one or more user groups (only user groups where he has administrative rights for)
:* one or more user attributes (provided via Shibboleth)
#* 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.
#:: 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? --[[User:Kristina|Kristina]] 15:48, 15 February 2010 (UTC)
# 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'''
'''Post-Conditions / Results'''
Line 226: Line 254:
'''Open Question'''
'''Open Question'''
* Is a user group affiliated to an OU? (like user)
* 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. --[[User:Kristina|Kristina]] 15:48, 15 February 2010 (UTC)


===UC_LA_UM_07 Edit user group===
===UC_LA_UM_07 Edit user group===
Line 232: Line 261:
'''Status/Schedule'''
'''Status/Schedule'''
*Status: '''in specification'''
*Status: '''in specification'''
*Schedule:'''6.1'''
*Schedule:'''tbd'''


'''Triggers'''
'''Triggers'''
* The user wants to edit a [[ESciDoc_User_Group_Handler|user group]]  
* The user wants to edit a [[ESciDoc_User_Group_Handler|user group]]  
* ''Integrated in:'' '''UC_LA_AS_02 View account user groups list'''  
* ''Integrated in:'' '''UC_LA_AS_02 View account user groups list'''


'''Actors'''
'''Actors'''
*Local Administrator
* System Administrator (current state of implementation)
* ''UserGroup Administrator (next step of implementation FW 1.2)''


'''Pre-Conditions'''
'''Pre-Conditions'''
*The user has the privilege 'local administrator' for the selected user group
*The user has administrative rights for the selected user group


'''Flow of Events'''
'''Flow of Events'''
# The user chooses to edit a user group
# (Optionally) The user can edit the following parameter : NAME, LABEL (short name), TYPE, DESCRIPTION
# (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: <br/>
#:* 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)
# The user wants to view all members of this user group. The system displays all members of this user group.
# The user saves the changes of the user group.


*1. The user chooses to edit a user group
===UC_LA_UM_08 Confirm account user===
*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
'''Status/Schedule'''
**3.1.  The system displays all selectors of the user group
* Status: '''in specification'''
**3.2.   The user can change the selectors of the user group by defining new ones: <br/>
* Schedule: '''tbd'''
::* 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)
'''Motivation'''
::* one or more user groups (only user groups where he is 'local administrator' for)
* The user received a confirmation request for an account user and follows the given link to confirm the account user.
::* 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.
'''Pre-Condition'''
*5.     The user saves the changes of the user group.
* An account user has been created and is in state deactivated.  
* An confirmation mail has been send to the selected account user.
 
'''Steps'''
# The user chooses to confirm the account user by following the link to the confirmation request.
# The system prompts for a password and a repetition of the password.
# The user enters a password twice and confirms the input.
# The system checks, if both password strings are equal.
# 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 ===
'''User States''' <br>
An account user can have two different states:
# '''active:'''
## The account has been activated by the user and can be used.
# '''deactivated/inactive:'''
## The account has been created by the administrator but has not been activated yet by the user.  
## 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==
==Context Management==
Line 266: Line 330:
'''Status/Schedule'''
'''Status/Schedule'''
*Status: '''in specification'''
*Status: '''in specification'''
*Schedule:'''6.1'''
*Schedule:'''tbd'''


'''Triggers'''
'''Triggers'''
Line 272: Line 336:


'''Actors'''
'''Actors'''
*Local Administrator
* System Administrator (current state of implementation)
* ''Context Administrator (next step of implementation with FW 1.2)''


'''Pre-Conditions'''
'''Pre-Conditions'''
Line 278: Line 343:


'''Flow of Events'''
'''Flow of Events'''
*1. The user chooses to create a new context.
# 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.
# 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.
# (Optionally) The user chooses to view the organizational unit description.
**3.1. The system displays 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.
# 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”.  
# 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.
# ''Continue with:'' '''UC_LA_CM_02 Edit context'''. The use case ends successfully.


'''Post-Conditions / Results'''
'''Post-Conditions / Results'''
Line 294: Line 359:
'''Status/Schedule'''
'''Status/Schedule'''
*Status: '''in specification'''
*Status: '''in specification'''
*Schedule:'''6.1'''
*Schedule:'''tbd'''


'''Triggers'''
'''Triggers'''
*The user wants to edit the context attributes or the default metadata values.
*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_CM_01 Create a context'''.
* ''Included in:'' '''UC_LA_AS_03 View contexts list'''
* ''Included in:'' '''UC_LA_AS_03 View contexts list'''  


'''Actors'''
'''Actors'''
*Local Administrator
* 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'''
'''Pre-Conditions'''
*One context is selected (*).
*One context is selected.
*The context is in the state “created” or “opened”.
*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'''
'''Flow of Events'''
*1. The user chooses to edit the selected context or the context was selected by a previous use case.
# 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.
# 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.
# (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).
# (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)
#: 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.
#:* a. No items exist.
***b. At least one item exists. The system displays an error message. Continue with 4.
#:* 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'''  
# (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  '''
# (Optionally) ''Extension point:'' '''UC_LA_CM_07 Configure validation schema for a context  '''
*7. (Optionally) ''Extension point:'' '''UC_LA_PM_01 Edit context preferences'''
# (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.
# (Optionally) ''Extension point:'' '''UC_LA_CM_08 Grant rights to a context '''
# 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'''
'''Post-Conditions / Results'''
Line 328: Line 397:


'''Open Questions'''
'''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?.
* Defining the Genres is very pubman specific. perhaps this choice is only given when TYPE= PubMan?.


Line 336: Line 404:
'''Status/Schedule'''
'''Status/Schedule'''
*Status: '''in specification'''
*Status: '''in specification'''
*Schedule:'''6.1'''
*Schedule:'''tbd'''


'''Triggers'''
'''Triggers'''
Line 342: Line 410:


'''Actors'''
'''Actors'''
*Local Administrator
* 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'''
'''Pre-Conditions'''
*One context is selected where the user is 'local administrator' for.
*One context is selected where the user has administrative rights for.
*The context is in the state “created” or “closed”.
*The context is in the state “created” or “closed”.


'''Flow of Events'''
'''Flow of Events'''
*1. The user chooses to open a context.
# The user chooses to open a context.
*2. The system prompts the user to confirm the opening of the context.
# The system prompts the user to confirm the opening of the context.
**2.1. The user confirms to open 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.
#: 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.
# The system changes the state of the context to “opened” and displays a success message. The use case ends successfully.


'''Post-Conditions / Results'''
'''Post-Conditions / Results'''
Line 366: Line 436:
'''Status/Schedule'''
'''Status/Schedule'''
*Status: '''in specification'''
*Status: '''in specification'''
*Schedule:'''6.1'''
*Schedule:'''tbd'''


'''Triggers'''
'''Triggers'''
Line 372: Line 442:


'''Actors'''
'''Actors'''
*Local Administrator
* 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'''
'''Pre-Conditions'''
*One context is selected where the user is 'local administrator' for.
*One context is selected where the user has administrative rights for.
*The context is in the state “opened”.
*The context is in the state “opened”.


'''Flow of Events'''
'''Flow of Events'''
*1. The user chooses to close a context.
# The user chooses to close a context.
*2. The system prompts the user to confirm the closing of the context.
# The system prompts the user to confirm the closing of the context.
**2.1. The user confirms to close 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.
#: 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.
# The systems changes the state of the context to “closed” and displays a success message. The use case ends successfully.


'''Post-Conditions / Results'''
'''Post-Conditions / Results'''
Line 393: Line 465:
'''Status/Schedule'''
'''Status/Schedule'''
*Status: '''in specification'''
*Status: '''in specification'''
*Schedule:'''6.1'''
*Schedule:'''tbd'''


'''Triggers'''
'''Triggers'''
Line 399: Line 471:


'''Actors'''
'''Actors'''
*Local Administrator
* 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'''
'''Pre-Conditions'''
* One context is selected where the user has privileges as "Local Administrator".
*One context is selected where the user has administrative rights for.
* The context contains only items in state “pending”.
* The context is in state 'created'


'''Flow of Events'''
'''Flow of Events'''
*1. The user chooses to delete a context.
# 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.
# The user confirms to delete the context.
**2.1. The user confirms to delete the context and the “pending” items.
#: 2.1.  The user does not confirm to delete the context. - The selected context is unaffected. The use case ends without success.
**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.
# The system deletes the context and displays a success message. The use case ends successfully.
*3. The system deletes the items as well as the context and displays a success message. The use case ends successfully.


'''Post-Conditions / Results'''
'''Post-Conditions / Results'''
*The context and all items in state “pending” are deleted and no longer available for any system action.
*The context is deleted and no longer available for any system action.


===UC_LA_CM_06 Configure workflows for context ===
===UC_LA_CM_06 Configure workflows for context ===
Line 420: Line 493:
'''Status/Schedule'''
'''Status/Schedule'''
*Status: '''in specification'''
*Status: '''in specification'''
*Schedule:'''6.1'''
*Schedule:'''tbd'''


'''Triggers'''
'''Triggers'''
Line 427: Line 500:


'''Actors'''
'''Actors'''
*Local Administrator
* 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'''
'''Pre-Conditions'''
*One context is selected where is user is 'local administrator' for.
*One context is selected where the user has administrative rights for.
*The context is in state “created”
*The context is in state “created”


'''Flow of Events'''
'''Flow of Events'''
*1. The system displays the lists of available publication and modification workflows.
# The system displays the lists of available workflows.
*2. (Optionally) The user changes the desired publication workflow.
# (Optionally) The user changes the desired workflow.
*3. (Optionally) The user changes the desired modification workflow.
# The system prompts for the confirmation of the workflow changes.
*4.    The system prompts for the confirmation of the workflow changes.
#: 3.1. The user chooses to confirm the selection.
**4.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.2.  The user does not confirm the workflow selection for the context. - The selected context is unaffected. The use case ends without success.
# The system stores the selected workflows as defined for the context and displays a success message. The use case ends successfully.
*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'''
'''Post-Conditions / Results'''
*A publication and a modification workflow for the context is saved.
*A workflow for the context is saved.


===UC_LA_CM_07 Configure validation schema for a context ===
===UC_LA_CM_07 Configure validation schema for a context ===
Line 450: Line 524:
'''Status/Schedule'''
'''Status/Schedule'''
*Status: '''in specification'''
*Status: '''in specification'''
*Schedule:'''6.1'''
*Schedule:'''tbd'''


'''Triggers'''
'''Triggers'''
Line 457: Line 531:


'''Actors'''
'''Actors'''
*Local Administrator
* 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'''
'''Pre-Conditions'''
*One context is selected where the user is 'local administrator' for.
*One context is selected where the user has administrative rights for.
*The context is in state "created".
*The context is in state "created".


'''Flow of Events'''
'''Flow of Events'''
*1. The system displays the lists of available, predefined validation schemas.  
# 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.
# The system prompts to confirm the change of the validation schema.
**2.1. The user chooses to confirm the selection.
#: 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.
#: 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.
# The system assigns the validation schema to the selected context and displays a success message. The use case ends successfully.


'''Post-Conditions / Results'''
'''Post-Conditions / Results'''
*The validation schema are assigned to the context.
*The validation schema is assigned to the context.
 
===UC_LA_CM_08 Grant rights to a context ===
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'''
# 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).
# The user chooses to add this role.
# The user chooses one or more users he wants to grant the role.
# The systems prompts for conformation of the data.
# 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==
==Organization Management==
 
For cross-checking, please see also: [[PubMan_Func_Spec_Organizational_Unit_Management#General_rules]]


===UC_LA_OUM_01 Create organizational unit===
===UC_LA_OUM_01 Create organizational unit===
Line 481: Line 586:
'''Status/Schedule'''
'''Status/Schedule'''
*Status: '''in specification'''
*Status: '''in specification'''
*Schedule:'''6.1'''
*Schedule:'''tbd'''


'''Triggers'''
'''Triggers'''
Line 487: Line 592:


'''Actors'''
'''Actors'''
*Local Administrator
* System Administrator (current state of implementation)
* ''Organizational Unit Administrator (next step of implementation with FW 1.3)''


'''Pre-Conditions'''
'''Pre-Conditions'''
*The user can only create an organizational unit as children of the organizational unit he is local administrator for.
*The user can only create an organizational unit as children of the organizational unit he has administrative rights for.


'''Flow of Events'''
'''Flow of Events'''
*1. The user chooses to create an organizational unit.  
# The user chooses to create an organizational unit.  
*2. The system displays an organizational unit details view.
# 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.
# 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.
# 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'''
# (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'''
# (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'''
# (Optionally) ''Extension Point:'' '''UC_LA_PM_02 Edit organizational unit preferences'''  
*8. The user confirms the creation.  
# The user confirms the creation.  
*9. The system checks if an organizational unit with the given name already exists under the same parent.
# 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.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.
#: 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.
# 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'''
'''Post-Conditions / Results'''
*The new organizational unit in the state “created” is created.
*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===
===UC_LA_OUM_02 Open organizational unit===
Line 517: Line 620:
'''Status/Schedule'''
'''Status/Schedule'''
*Status: '''in specification'''
*Status: '''in specification'''
*Schedule:'''6.1'''
*Schedule:'''tbd'''


'''Triggers'''
'''Triggers'''
Line 523: Line 626:


'''Actors'''
'''Actors'''
*Local Administrator
* System Administrator (current state of implementation)
* ''Organizational Unit Administrator (next step of implementation with FW 1.3)''


'''Pre-Conditions'''
'''Pre-Conditions'''
*One organizational unit is selected where the user is local administrator for
*One organizational unit is selected where the user has administrative rights for
*The selected organizational unit is in status "created"
*The selected organizational unit is in status "created"
*If there is a parent organizational unit, the parent organizational unit is in status "opened"
*If there is a parent organizational unit, the parent organizational unit is in status "opened"


'''Flow of Events'''
'''Flow of Events'''
*1. The user chooses an organizational unit to change its state to "opened".  
# The user chooses an organizational unit to change its state to "opened".  
*2. The system displays an organizational unit details view.
# The system displays an organizational unit details view.
*3. (Optionally)'' Extension point:'' '''UC_LA_OUM_03 Edit organizational unit'''
# (Optionally)'' Extension point:'' '''UC_LA_OUM_03 Edit organizational unit'''
*4. The user confirms the opening.  
# 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.
# 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'''
'''Post-Conditions / Results'''
Line 545: Line 649:
'''Status/Schedule'''
'''Status/Schedule'''
*Status: '''in specification'''
*Status: '''in specification'''
*Schedule:'''6.1'''
*Schedule:'''tbd'''


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


'''Actors'''
'''Actors'''
*Local Administrator
* System Administrator (current state of implementation)
* ''Organizational Unit Administrator (next step of implementation with FW 1.3)''


'''Pre-Conditions'''
'''Pre-Conditions'''
*An organizational unit is selected where the user is 'local administrator' for.
*An organizational unit is selected where the user has administrative rights for.


'''Flow of Events'''
'''Flow of Events'''
*1. The user chooses to edit the selected organizational unit.  
# The user chooses to edit the selected organizational unit.  
*2. The system displays the details of the selected organizational unit in an edit view.
# 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.  
# (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.
# 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
#: 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'''
# (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'''
# (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'''  
# (Optionally) ''Extension Point:'' '''UC_LA_PM_02 Edit organizational unit preferences'''  
*8. The user confirms the changes.  
# The user confirms the changes.  
*9. The system stores the changes and displays a success message. The use case ends successfully.
# The system stores the changes and displays a success message. The use case ends successfully.


'''Post-Conditions / Results'''
'''Post-Conditions / Results'''
*Modifications to the selected organizational unit are saved.
*Modifications of the selected organizational unit are saved.


'''Additional Information'''
'''Additional Information'''
Line 581: Line 686:
'''Status/Schedule'''
'''Status/Schedule'''
*Status: '''in specification'''
*Status: '''in specification'''
*Schedule:'''6.1'''
*Schedule:'''tbd'''


'''Triggers'''
'''Triggers'''
Line 587: Line 692:


'''Actors'''
'''Actors'''
*Local Administrator
* System Administrator (current state of implementation)
* ''Organizational Unit Administrator (next step of implementation with FW 1.3)''


'''Pre-Conditions'''
'''Pre-Conditions'''
*An organizational unit is selected where the user has 'local administrator' privileges for.
*An organizational unit is selected where the user has administrative rights for.
*Selected organizational unit is in status "opened"
*Selected organizational unit is in status "opened"


'''Flow of Events'''
'''Flow of Events'''
*1. The user chooses to close the selected organizational unit.
# The user chooses to close the selected organizational unit.
*2. The system displays the details of the selected organizational unit in an edit view.  
# 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"
# 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
#: 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.
#:* 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.
#:* 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.
# 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.
# The system changes the state of the organizational unit to "closed" and displays a success message. The use case ends successfully.


'''Post-Conditions / Results'''
'''Post-Conditions / Results'''
Line 617: Line 723:


'''Actors'''
'''Actors'''
*Local Administrator
* System Administrator
* ''Organizational Unit Administrator (next step of implementation with FW 1.3)''


'''Pre-Conditions'''
'''Pre-Conditions'''
*One organizational unit is selected where the user is 'local administrator' for.
*One organizational unit is selected where the user has administrative rights for.
*The selected organizational unit is in status "created"
*The selected organizational unit is in status "created"


'''Flow of Events'''
'''Flow of Events'''
*1. The user chooses to delete the selected organizational unit.  
# The user chooses to delete the selected organizational unit.  
*2. The system displays the details of the selected organizational unit in an edit view.
# 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
# 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.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.
#: 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.
# The user confirms the deletion.
*5.    The system stores the changes and displays a success message. The use case ends successfully.
# The system stores the changes and displays a success message. The use case ends successfully.


'''Post-Conditions / Results'''
'''Post-Conditions / Results'''
Line 648: Line 755:


'''Actors'''
'''Actors'''
*Local Administrator
* System Administrator (current state of implementation)
* ''Organizational Unit Administrator (next step of implementation with FW 1.3)''


'''Pre-Conditions'''
'''Pre-Conditions'''
*An organizational unit to which predecessor should be added is selected
*An organizational unit to which predecessor should be added is selected
*The user administrative rights for the selected OU.


'''Flow of Events'''
'''Flow of Events'''
*1. The user chooses to add a predecessor to the selected organizational unit.  
# 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.
# 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.  
# 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 [[PubMan_History_of_affiliations#Introduction | type of relation]] (FUSION, REPLACEMENT, SPLITTING, SPIN-OFF, AFFILIATION) of the predecessor organizational unit to the organizational unit she is editing.  
# The user specifies the [[PubMan_History_of_affiliations#Introduction | 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.
# The user confirms the change. The system saves the change and displays a success message. The use case ends successfully.


'''Post-Conditions / Results'''
'''Post-Conditions / Results'''
Line 676: Line 785:


'''Actors'''
'''Actors'''
*Local Administrator
* System Administrator (current state of implementation)
* ''Organizational Unit Administrator (next step of implementation with FW 1.3)''


'''Pre-Conditions'''
'''Pre-Conditions'''
Line 687: Line 797:
==Preferences Management==
==Preferences Management==
This section is a loose idea collection for start.
This section is a loose idea collection for start.


=== UC_LA_PM_01 Edit context preferences ===
=== UC_LA_PM_01 Edit context preferences ===
Line 697: Line 806:


'''Actors Involved'''
'''Actors Involved'''
* Local Administrator
* System Administrator  
* Context Administrator
* Context Modifier


'''Prerequisites'''
'''Prerequisites'''
* The user chooses a context where he has local administrator rights for.
* The user chooses a context where he has administrative rights for.


'''Ideas'''
'''Ideas'''
Line 717: Line 828:


'''Actors Involved'''
'''Actors Involved'''
* Local Administrator
* System Administrator
* Organizational Unit Administrator


'''Prerequisites'''
'''Prerequisites'''
* The user chooses a context where he has local administrator rights for.
* The user chooses a context where he has administrative rights for.


'''Ideas'''
'''Ideas'''
Line 727: Line 839:


=== UC_LA_PM_03 Edit user preferences ===
=== UC_LA_PM_03 Edit user preferences ===
The user wants to edit system preferences for a specific user
The user wants to edit system preferences for a specific user.
 
See also [[PubMan_Func_Spec_User_Management#UC_PM_UM_06_change_user_preferences| User Management]]


'''Status/Schedule'''
'''Status/Schedule'''
Line 734: Line 848:


'''Actors Involved'''
'''Actors Involved'''
* Local Administrator
* System Administrator
* User Administrator


'''Prerequisites'''
'''Prerequisites'''
* The user chooses a context where he has local administrator rights for.
* The user chooses a context where he has administrative rights for.


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


==Administrative Search==
==Administrative Search==


=== UC_LA_AS_01 View account users list ===
=== UC_LA_AS_01 View account users list ===
The user wants to overview all account users he can manage.
The user wants to overview all account users he is allowed to manage.


'''Status/Schedule'''
'''Status/Schedule'''
Line 755: Line 868:


'''Actors Involved'''
'''Actors Involved'''
* System Administrator
* Local Administrator
* Local Administrator


'''Flow of Events'''  
'''Flow of Events'''  
# The user chooses to overview all account users.
# The user chooses to overview all account users.
# 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  
# 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).
# (Optionally) The user changes the sorting order (it should be possible to sort the list by all columns available in the list).
# (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.
# (Optionally) The user chooses another number of hits per page.
# (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.
# (Optionally) The user goes to a special page, to the last page or to the first page.
# (Optionally) The user goes to a special page, to the last page or to the first page.
# (Optionally)'' Extension point:'' '''UC_LA_UM_02 Edit account user'''
#: 5.1 The system displays the selected page.
 
# '' Extension point:'' '''edit account user'''
#: 6.1 If the user wants to edit a selected account user, include [[Func_Spec_Admin#UC_LA_UM_02_Edit_account_user|UC_LA_UM_02 Edit account user]].
# ''Extension point:'' '''deactivate account user'''
#: 7.1 If the user wants to deactivate a selected account user, include [[Func_Spec_Admin#UC_LA_UM_04_Deactivate_account_user|UC_LA_UM_04 Deactivate account user]].
# The use case ends successfully.


=== UC_LA_AS_02 View user groups list ===
=== UC_LA_AS_02 View user groups list ===
Line 774: Line 894:


'''Actors Involved'''
'''Actors Involved'''
* System Administrator
* Local Administrator
* Local Administrator


Line 793: Line 914:


'''Actors Involved'''
'''Actors Involved'''
* System Administrator
* Local Administrator
* Local Administrator


Line 812: Line 934:


'''Actors Involved'''
'''Actors Involved'''
* System Administrator
* Local Administrator
* Local Administrator


Line 830: Line 953:


'''Actors Involved'''
'''Actors Involved'''
* System Administrator
* Local Administrator
* Local Administrator
* User
* User
Line 851: Line 975:


'''Actors Involved'''
'''Actors Involved'''
* System Administrator
* Local Administrator
* Local Administrator


Line 857: Line 982:


'''Flow of Events'''
'''Flow of Events'''
*1.    The user enters an arbitrary search term in the simple search text field and submits.
# 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
# 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.1.  One or more objects were found, continue with 3.
**2.2.  No object was found, the system displays an error message.
#: 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
# 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).
# (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.
# (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.
# (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.
# (Optionally) The list can be filtered for object type USER, CONTEXT, ORGANIZATIONAL UNIT.
*8.    (Optionally) ''Extension point:'' '''UC_LA_UM_02 Edit account user'''
# (Optionally) ''Extension point:'' '''UC_LA_UM_02 Edit account user'''
*9.    (Optionally) ''Extension point:'' '''UC_LA_UM_07 Edit user group'''
# (Optionally) ''Extension point:'' '''UC_LA_UM_07 Edit user group'''
*10.    (Optionally) ''Extension point:'' '''UC_LA_CM_02 Edit context '''
# (Optionally) ''Extension point:'' '''UC_LA_CM_02 Edit context '''
*11.    (Optionally) ''Extension point:'' '''UC_LA_OUM_03 Edit organizational unit '''
# (Optionally) ''Extension point:'' '''UC_LA_OUM_03 Edit organizational unit '''
*12.    The use case ends successfully.
# The use case ends successfully.


'''Open Question'''
'''Open Question'''
Line 884: Line 1,009:


'''Actors Involved'''
'''Actors Involved'''
* System Administrator
* Local Administrator
* Local Administrator


Line 890: Line 1,016:


'''Flow of Events'''
'''Flow of Events'''
*1.    The user can search for:  
# The user can search for:  
::      USER NAME, USER EMAIL, USER LOGIN_NAME, USER GROUP NAME
#:      USER NAME, USER EMAIL, USER LOGIN_NAME, USER GROUP NAME
::      OU TITLE, OU DESCRIPTION, OU STATE
#:      OU TITLE, OU DESCRIPTION, OU STATE
::      CONTEXT NAME, CONTEXT DESCRIPTION
#:      CONTEXT NAME, CONTEXT DESCRIPTION
*2.    The system performs a search of all objects the user has 'local administrator' rights for, on the corresponding indexes.
# 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.1.  One or more objects were found, continue with 3.
**2.2.  No object was found, the system displays an error message.
#: 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
# 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).
# (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.
# (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.
# (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.
# (Optionally) The list can be filtered for object type USER, CONTEXT, ORGANIZATIONAL UNIT.
*8.    (Optionally) ''Extension point:'' '''UC_LA_UM_02 Edit account user'''
# (Optionally) ''Extension point:'' '''UC_LA_UM_02 Edit account user'''
*9.    (Optionally) ''Extension point:'' '''UC_LA_UM_07 Edit user group'''
# (Optionally) ''Extension point:'' '''UC_LA_UM_07 Edit user group'''
*10.    (Optionally) ''Extension point:'' '''UC_LA_CM_02 Edit context '''
# (Optionally) ''Extension point:'' '''UC_LA_CM_02 Edit context '''
*11.    (Optionally) ''Extension point:'' '''UC_LA_OUM_03 Edit organizational unit '''
# (Optionally) ''Extension point:'' '''UC_LA_OUM_03 Edit organizational unit '''
*12.    The use case ends successfully.
# The use case ends successfully.


'''Open Question'''
'''Open Question'''
Line 930: Line 1,056:


==Additional Information==
==Additional Information==
* The privileges of a local administrator are related to an organizational unit.
 
===eSciDoc Administrative Roles ===
A description of the eSciDoc administrative roles which are referenced in his specification can be found [[ESciDoc_Admin_Roles | here]].


===Solution Specific Specifications===
===Solution Specific Specifications===
Line 943: Line 1,071:
** http://colab.mpdl.mpg.de/mediawiki/ViRR_User_Management
** http://colab.mpdl.mpg.de/mediawiki/ViRR_User_Management


[[Category: Functional_specification|Local Admin]]
[[Category: Functional_specification|Administration]]

Latest revision as of 08:18, 27 March 2013

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"