Talk:Func Spec Admin
Revision as of 15:11, 5 November 2009 by Kleinfercher (talk | contribs) (→UC_LA_UM_04 Delete/inactivate account user)
Open Points for discussion[edit]
- Definition of user group selectors: Shall the system display a list of all available organizational units or users? Kristina 11:15, 4 November 2009 (UTC)
User Management[edit]
- User accounts:
- for both create/edit account user, it should be stated that these are the use cases that are valid only for local user management.
- it should also be stated, that in case of identity provider e.g. LDAP, these are externally implemented.
- there is the concept of the user-attributes that needs to be provided with the newest core-service. However it is not fully clear how the implementation would happen. Would be known after stable 1.2 core-service release.
- Integrated in UC --Friederike 09:47, 4 November 2009 (UTC)
- User groups:
- maybe a bit clearer description on editing of the user group.
- it's cumbersome to state that user would like to change "affiliated persons in the user group". When editing a user group, user is modifying the selectors of the user group (thus implicitly users that are members of the user group).
- Integrated in UC --Friederike 09:47, 4 November 2009 (UTC)
UC_LA_UM_01 Create account user[edit]
- Somewhere the predefined subject, text and link for the confirmation request should be specified --Kristina 10:54, 4 November 2009 (UTC)
- This is defined in UC_LA_PM_02 --Friederike 14:31, 5 November 2009 (UTC)
- That means that one user can only belong to one organizational unit. Perhaps sometimes a user belongs to more than one? --Kristina 11:02, 4 November 2009 (UTC)
- This use case should be extended by the use case Assign priviledges to the user, because without priviledges, the user can not work. --Kristina 11:04, 4 November 2009 (UTC)
UC_LA_UM_02 Edit account user[edit]
- in UC_LA_UM_05 Activate user you say, that edit account user can be used as extension point --Kristina 10:54, 4 November 2009 (UTC)
- this has to be listed in this use case as possible trigger
- the user himself can also be an actor, not only the local admin
- That means that the local admin can change the password for each of "his" users. Is that what we want? --Kristina 11:01, 4 November 2009 (UTC)
- If someone else is editing my account, it would be nice if I get an e-Mail notification about this changes. Another question would be if it is alos usefull to send a e-Mail notification when I myself change my account (some providers offers such functionality). --Kristina 10:55, 5 November 2009 (UTC)
UC_LA_UM_04 Delete/inactivate account user[edit]
- Step 2-3: Hier ist irgendwie der Wurm drinn --Kristina 11:10, 4 November 2009 (UTC)
- 2.1 Wenn nur items in state pending existieren, dann step 5 (account user wird deleted). Sollte hier nicht erst die Liste mit allen pending alben gezeigt werden (step 3)
- 2.2 Wenn es auch items in anderen stati als pending gibt, sollte der user nur inactive gesetzt werden (step 6)
- Update UC, hope its clearer now. --Friederike 15:11, 5 November 2009 (UTC)
UC_LA_UM_06 Create user group[edit]
Context Management[edit]
- it is wrong to have one publication or one modification workflow available
- these settings are part of the admin descriptor (depending on the type of the context i.e. PubMan, Faces etc..) - admin descriptors may have different settings
- Changed in UC --Friederike 09:55, 4 November 2009 (UTC)
UC_LA_CM_02 Edit context[edit]
- Extension point to UC_LA_CM_07 Assign validation rules to a context is missing --Kristina 11:27, 4 November 2009 (UTC)
- Integrated in UC --Friederike 16:21, 4 November 2009 (UTC)
UC_LA_CM_05 Delete a context[edit]
- Post-Conditions / Results: The context and all items in state “pending” are deleted and no longer available for any system action.
- Which items in the state pending? I thought when a context is still in the state pending, no corresponding items can be created? --Kristina 11:25, 4 November 2009 (UTC)
- This UC does not make any assumption on the state of a context. a context can be deleted in any state, only precondition is: the context has no items in any state other than "pernding".--Friederike 16:18, 4 November 2009 (UTC)
Organizational Unit Management[edit]
UC_LA_OUM_01 Create organizational unit[edit]
- A lot of aspects within this UC are also part of the edit UC. Wouldn't it be nicer yust to mention the create functionalities here and then continue with UC Edit Organizational Unit? --Kristina 12:45, 4 November 2009 (UTC)
UC_LA_OUM_02 Open organizational unit[edit]
- In this UC, some functionalities from edit OU are integrated, but not all. Wouldn't it be nicer to make an extension point to edit? --Kristina 12:44, 4 November 2009 (UTC)
- Integrated in UC --Friederike 13:25, 5 November 2009 (UTC)
UC_LA_OUM_06 Add predecessor to an organizational unit[edit]
- Between Step 2 and 3: The system displays a list with all organizational units that can be used as predecessor (I don't know the exact requirements, but I think a sentence like this is needed). --Kristina 12:48, 4 November 2009 (UTC)
- Step 4: What types of relations are available? --Kristina 12:49, 4 November 2009 (UTC)
- Integrated in UC --Friederike 16:27, 4 November 2009 (UTC)
Preference Management[edit]
Administrative Search[edit]
UC_LA_AS_01 View account users list[edit]
- Step 2: Display ROLE with CONTEXT --> this can be a longer list. Perhaps that should only be displayed in a detailed view, but not in a list view? --Kristina 12:56, 4 November 2009 (UTC)
- From this list, not only edit but also some other actions like UC_LA_UM_03 Assign privileges to account user and UC_LA_UM_04 Delete/inactivate account user should be possible. --Kristina 13:01, 4 November 2009 (UTC)
- I think the creation dates of a user should also be displayed in the list (perhaps I am looking for the user I just created several minutes ago). --Kristina 10:48, 5 November 2009 (UTC)
- Integrated 'Date last modified' in UC --Friederike 14:01, 5 November 2009 (UTC)
General Feedback[edit]
- When creating or changing a user account, the corresponding user gets a information message. It would be verry good, if this messages are easily changeable by the local admin and also by us (e.g. via static html pages) as the requirements for these texts can change from institution to institution (and also from solution to solution). --Kristina 10:51, 29 October 2009 (UTC)
- Integrated in Preference Management UC --Friederike 09:29, 3 November 2009 (UTC)
- It would be nice that all lists that occur in the admin interface are sorted alphabetically (perhaps the sorting can be changed to last created/edited, too). --Kristina 10:51, 29 October 2009 (UTC)
- Will CoNE be of any importance in this scenario, or is this independent from Admin Solution? --Friederike 16:22, 3 November 2009 (UTC)
- What is the difference between a publication and a modification workflow? --Friederike 10:50, 4 November 2009 (UTC)