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)
 
(22 intermediate revisions by 3 users not shown)
Line 1: Line 1:
==Open Points for discussion==
==Open Points for discussion==
* Definition of user group selectors: Shall the system display a list of all available organizational units or users? [[User:Kristina|Kristina]] 11:15, 4 November 2009 (UTC)
* Definition of user group selectors: Shall the system display a list of all available organizational units or users? [[User:Kristina|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)--[[User:Natasab|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? --[[User:Kristina|Kristina]] 11:02, 4 November 2009 (UTC)
:only to one according eSciDoc model --[[User:Natasab|Natasa]] 16:30, 6 November 2009 (UTC)
* Can the local admin change the password for each of "his" users. Is that what we want? --[[User:Kristina|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). --[[User:Kristina|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.--[[User:Natasab|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? --[[User:Kleinfercher|Friederike]] 09:49, 10 November 2009 (UTC)


== User Management==
== User Management==
Line 16: Line 24:
* Somewhere the predefined subject, text and link for the confirmation request should be specified --[[User:Kristina|Kristina]] 10:54, 4 November 2009 (UTC)
* Somewhere the predefined subject, text and link for the confirmation request should be specified --[[User:Kristina|Kristina]] 10:54, 4 November 2009 (UTC)
: This is defined in [[ Func_Spec_Local_Admin#UC_LA_PM_02_Edit_organizational_unit_preferences | UC_LA_PM_02]] --[[User:Kleinfercher|Friederike]] 14:31, 5 November 2009 (UTC)
: This is defined in [[ Func_Spec_Local_Admin#UC_LA_PM_02_Edit_organizational_unit_preferences | UC_LA_PM_02]] --[[User:Kleinfercher|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? --[[User:Kristina|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. --[[User:Kristina|Kristina]] 11:04, 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. --[[User:Kristina|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.--[[User:Kleinfercher|Friederike]] 10:58, 6 November 2009 (UTC)


=== UC_LA_UM_02 Edit account user ===
=== UC_LA_UM_02 Edit account user ===
Line 24: Line 32:
:* the user himself can also be an actor, not only the local admin
:* the user himself can also be an actor, not only the local admin
: Updated UC --[[User:Kleinfercher|Friederike]] 10:56, 6 November 2009 (UTC)
: Updated UC --[[User:Kleinfercher|Friederike]] 10:56, 6 November 2009 (UTC)
* That means that the local admin can change the password for each of "his" users. Is that what we want? --[[User:Kristina|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). --[[User:Kristina|Kristina]] 10:55, 5 November 2009 (UTC)


=== UC_LA_UM_04 Delete/inactivate account user ===  
=== UC_LA_UM_04 Delete/inactivate account user ===  
* Step 2-3: Hier ist irgendwie der Wurm drinn --[[User:Kristina|Kristina]] 11:10, 4 November 2009 (UTC)
* Step 2-3: Hier ist irgendwie der Wurm drinn --[[User:Kristina|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.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.--[[User:Natasab|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)
:* 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. --[[User:Kleinfercher|Friederike]] 15:11, 5 November 2009 (UTC)
:Update UC, hope its clearer now. --[[User:Kleinfercher|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. --[[User:Haarlaender|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 ;) --[[User:Kleinfercher|Friederike]] 09:45, 16 November 2009 (UTC)


=== UC_LA_UM_06 Create user group ===  
=== UC_LA_UM_06 Create user group ===  
Line 39: Line 48:
**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
**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 --[[User:Kleinfercher|Friederike]] 09:55, 4 November 2009 (UTC)
::Changed in UC --[[User:Kleinfercher|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 ===  
=== UC_LA_CM_02 Edit context ===  
* Extension point to UC_LA_CM_07 Assign validation rules to a context is missing --[[User:Kristina|Kristina]] 11:27, 4 November 2009 (UTC)
* Extension point to UC_LA_CM_07 Assign validation rules to a context is missing --[[User:Kristina|Kristina]] 11:27, 4 November 2009 (UTC)
: Integrated in UC --[[User:Kleinfercher|Friederike]] 16:21, 4 November 2009 (UTC)
: Integrated in UC --[[User:Kleinfercher|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 --[[User:Natasab|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. --[[User:Natasab|Natasa]] 16:55, 6 November 2009 (UTC)
: Updated wording in UC --[[User:Kleinfercher|Friederike]] 08:07, 9 November 2009 (UTC)


=== UC_LA_CM_05 Delete a context ===
=== UC_LA_CM_05 Delete a context ===
Line 49: Line 67:
:: 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".--[[User:Kleinfercher|Friederike]] 16:18, 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".--[[User:Kleinfercher|Friederike]] 16:18, 4 November 2009 (UTC)


--[[User:Natasab|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==
== Organizational Unit Management==
Line 63: Line 89:
* Step 4: What types of relations are available? --[[User:Kristina|Kristina]] 12:49, 4 November 2009 (UTC)
* Step 4: What types of relations are available? --[[User:Kristina|Kristina]] 12:49, 4 November 2009 (UTC)
: Integrated in UC --[[User:Kleinfercher|Friederike]] 16:27, 4 November 2009 (UTC)
: Integrated in UC --[[User:Kleinfercher|Friederike]] 16:27, 4 November 2009 (UTC)
For cross-checking, please see also:
[[PubMan_Func_Spec_Organizational_Unit_Management#General_rules]]


== Preference Management==
== Preference Management==
Line 73: Line 103:
* 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). --[[User:Kristina|Kristina]] 10:48, 5 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). --[[User:Kristina|Kristina]] 10:48, 5 November 2009 (UTC)
: Integrated 'Date last modified' in UC --[[User:Kleinfercher|Friederike]] 14:01, 5 November 2009 (UTC)
: Integrated 'Date last modified' in UC --[[User:Kleinfercher|Friederike]] 14:01, 5 November 2009 (UTC)
=== UC_LA_AS_05 View user groups list for account user ===
* 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. --[[User:Haarlaender|MarkusH]] 13:34, 12 November 2009 (UTC)


== General Feedback ==
== General Feedback ==
Line 79: Line 113:
* 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). --[[User:Kristina|Kristina]] 10:51, 29 October 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). --[[User:Kristina|Kristina]] 10:51, 29 October 2009 (UTC)
* Will CoNE be of any importance in this scenario, or is this independent from Admin Solution? --[[User:Kleinfercher|Friederike]] 16:22, 3 November 2009 (UTC)
* Will CoNE be of any importance in this scenario, or is this independent from Admin Solution? --[[User:Kleinfercher|Friederike]] 16:22, 3 November 2009 (UTC)
* What is the difference between a publication and a modification workflow? --[[User:Kleinfercher|Friederike]] 10:50, 4 November 2009 (UTC)

Latest revision as of 11: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)