Difference between revisions of "Talk:Func Spec Admin"

From MPDLMediaWiki
Jump to navigation Jump to search
m (Talk:Func Spec Local Admin moved to Talk:Func Spec Admin: The role of a local admin will not exist anymore, but different admin roles for different tasks)
 
(No difference)

Latest revision as of 13:05, 17 May 2010

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)
it depends on the user requirements. A group selector can be anthing of list of OU, list of users or user-attributes (or their combination)--Natasa 16:30, 6 November 2009 (UTC)
  • Can a user only belong to one organizational unit. Perhaps sometimes a user belongs to more than one? --Kristina 11:02, 4 November 2009 (UTC)
only to one according eSciDoc model --Natasa 16:30, 6 November 2009 (UTC)
  • Can the local admin 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)
the answer to this question depends on where editing of the user account is happening: in the identity provider (IDP) solution or in local eSciDoc user database. As we are aiming to decouple this from eSciDoc, i would assume that this depends on the set-up of the IDP in use.--Natasa 16:30, 6 November 2009 (UTC)
  • UC_LA_UM_07 Edit user group: Should a user get an information message when he was added to a user group? --Friederike 09:49, 10 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)
  • 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 is extended by 'Edit account user', which is extended by 'Assign privileges', thus this UC is extended implicitly.--Friederike 10:58, 6 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
Updated UC --Friederike 10:56, 6 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)
would not recommend deletion of an account user.--Natasa 16:32, 6 November 2009 (UTC)
  • 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)
  • In my opinion it should not be possible to delete an user at all. If the user has created any objects, there will always be references from these objects to the user account. Apart from that the coreservice doesn't even provide methods for deletion of user acounts. --MarkusH 13:02, 12 November 2009 (UTC)
Ok, thanks for the feedback. Will delete this func. this was in the original UC from PubMan so I thought it is possible ;) --Friederike 09:45, 16 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)
  • create context should not include definition of available genres. Genre definitions are only applicable for now to PubMan type of context and these are part of the admin descriptor (is that what is in the use case mentioned as "context preferences"?)


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)
context references validation schema and not validation rules (validation schema contains set of validation rules). We should use correct naming convention in here --Natasa 16:55, 6 November 2009 (UTC)
  • validation schema, allowed genres, workflows all of these are part of the context admin descriptor (i.e. context settings and configuration) which of those are defined and which not, depends on the type of the context e.g. Faces context do not care on validation rules at the moment, nor on allowed genres and that is fine. Similar is the case for VIRR context. More or less, every type of the context would have own structure of the admin descriptor. --Natasa 16:55, 6 November 2009 (UTC)
Updated wording in UC --Friederike 08:07, 9 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)

--Natasa 16:43, 6 November 2009 (UTC)In general to better understand limitations on whan can be done with a context in which state:

  • when context is created (no items can be associated to this context) (in this case context can be deleted)
  • when context is opened (items can be associated to this context) (in this case context can not be deleted, only closed)
  • when context is closed (no items can be associated to this context)

i.e. context can be deleted only when in state "created" and in no other state. User privileges.. these can be assigned only on "opened" or "closed" context. To have clear overview, i think a table such as created for organizational units (see below) should be created and validated. (somewhere there was maybe a specification for a context mngmt, have to find it)

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)

For cross-checking, please see also:

PubMan_Func_Spec_Organizational_Unit_Management#General_rules

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)


UC_LA_AS_05 View user groups list for account user[edit]

  • This won't be easily possible with the current coreservice, because a user can also be part of a user group if he is e.g. in an organization or a "user group in a user group". There's currently no method providing the functionality to directly get all user groups a user is assigned to, independently of the hierarchy. Imo only direct assignments (user is a selector of a user group) could be retrieved via a filter. --MarkusH 13:34, 12 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)