Difference between revisions of "Talk:ESciDoc Access Rights"
Jump to navigation
Jump to search
| Line 2: | Line 2: | ||
==Submission Easy/Full== | ==Submission Easy/Full== | ||
*add new file visibility level "audience" for uploaded files | |||
==View item== | ==View item== | ||
*type of access/visibility | *type of access/visibility for each component is visible to all users | ||
*Improvement sorting: sort by items with attached fulltexts. within fulltexts, sort by visibilities (future development) | *Improvement sorting: sort by items with attached fulltexts. within fulltexts, sort by visibilities (future development) | ||
*see also under point collaborator | |||
==Admin solution (user roles, context)== | ==Admin solution (user roles, context)== | ||
*During assignemtn of user privileges, user needs to be able to assign role audience and/or role collaborator (no use case modificaiton needed) | *During assignemtn of user privileges, user needs to be able to assign role audience and/or role collaborator (no use case modificaiton needed) | ||
*OPEN: Where to describe the assignement of context properties? => User needs to assign property "collaboration" for a complete context (i.e. all items in this context will be accessible/visible to all collaborators roles) | |||
*Where to describe the assignement of context properties? | |||
User needs to assign property "collaboration" for a complete context (i.e. all items in this context will be accessible/visible to all collaborators roles) | |||
*new use case: create user group (all org unit users, specific account users) | *new use case: create user group (all org unit users, specific account users) | ||
**Admin decides to create user group | **Admin decides to create user group | ||
| Line 17: | Line 16: | ||
**There is no restriction on viewing users from other org units. admin can select users from different org units .therefore, checkboxes should be chosen to select users. | **There is no restriction on viewing users from other org units. admin can select users from different org units .therefore, checkboxes should be chosen to select users. | ||
**Nice to have scenario: In addition, when assigning user privileges for a user, admin can assign the specific user as member of a specific user group. | **Nice to have scenario: In addition, when assigning user privileges for a user, admin can assign the specific user as member of a specific user group. | ||
*New use case: view user groups and their members for specific context. Possibility to add new members to group. | |||
*New use case: view user groups for specific context. Possibility to add new members to group. | |||
*Future development: Instead of one generic "audience"level, user can assign visibility to components to various user groups (additive) | *Future development: Instead of one generic "audience"level, user can assign visibility to components to various user groups (additive) | ||
== | ==Collaborator== | ||
*Visibility internal: can be accessed by QA role, but not viewed/opened by QA role. Does this make sense? Might be improvement for later. (not R5) | *Visibility internal: can be accessed by QA role, but not viewed/opened by QA role. Does this make sense? Might be improvement for later. (not R5) | ||
*Possible improvement for standard workflwo: owner can always modify his own items, independent from state of item. (not R5) | *Possible improvement for standard workflwo: owner can always modify his own items, independent from state of item. (not R5) | ||
*Basic user info: | *Basic user info: Collaborator | ||
**a | **is a user role which allows access to items and its components | ||
** | **access can be provided on item level or | ||
**collaborators can access items during all states (from pending to released) | **access can be provided on context level | ||
** | **collaborators can access items during all states (from pending to released) | ||
**OPEN: is it technically possible that collaborators can modify the collab item while pending, submitted, in revision, released? If yes, we need to define for which states. | |||
*Do we need QA workspace for Collaborator, as he can access and modify?=> Proposal simple solution: No need for own workspace. The items, where I have access to as collaborator, should be listed under "my items". In addition, we need filter method to sort by "my own items" (i.e. i am depositor/owner) and "items for which i am collaborator". If filtering is not possible, we have to add specific icons(or similar) for the two types of items (i.e. my items or collaborator items) | *Do we need QA workspace for Collaborator, as he can access and modify?=> Proposal simple solution: No need for own workspace. The items, where I have access to as collaborator, should be listed under "my items". In addition, we need filter method to sort by "my own items" (i.e. i am depositor/owner) and "items for which i am collaborator". If filtering is not possible, we have to add specific icons(or similar) for the two types of items (i.e. my items or collaborator items) | ||
*How to mark item as being accessible for collaborators or remove this possibility?: On view item page, we include new tab "collaboration". On this tab, QA role and Owner can see the item log (or parts of it, where collaborators have accessed and modified) and can add or remove the possibility for collaborators to access/modify this explicit item.In this context, he needs to have an info-button (link to context-sensitive help collaboration) to explain what does role collaborator mean. | *How to mark item as being accessible for collaborators or remove this possibility?: On view item page, we include new tab "collaboration". On this tab, QA role and Owner can see the item log (or parts of it, where collaborators have accessed and modified) and can add or remove the possibility for collaborators to access/modify this explicit item.In this context, he needs to have an info-button (link to context-sensitive help collaboration) to explain what does role collaborator mean. In case the role for collaboration has been defined for the complete scope of a context, the item property "collaboration item" cannot be removed. In this case, an information has to be displayed that "collaboration" has been defined for complete scope. | ||
In case the role for collaboration has been defined for the complete scope of a context, the item property "collaboration item" cannot be removed. In this case, an information has to be displayed that "collaboration" has been defined for complete scope. | |||
==Audience== | ==Audience== | ||
Audience is | Audience is | ||
Revision as of 12:02, 19 March 2009
Meeting 19th march 2009: Consequences on eSciDoc Access rights on Enduser-features / "institutional visibility"
Submission Easy/Full[edit]
- add new file visibility level "audience" for uploaded files
View item[edit]
- type of access/visibility for each component is visible to all users
- Improvement sorting: sort by items with attached fulltexts. within fulltexts, sort by visibilities (future development)
- see also under point collaborator
Admin solution (user roles, context)[edit]
- During assignemtn of user privileges, user needs to be able to assign role audience and/or role collaborator (no use case modificaiton needed)
- OPEN: Where to describe the assignement of context properties? => User needs to assign property "collaboration" for a complete context (i.e. all items in this context will be accessible/visible to all collaborators roles)
- new use case: create user group (all org unit users, specific account users)
- Admin decides to create user group
- He provides name and context for whcih user group is valid
- Option a) user selects from org tree a specific org unit. Below the selected org unit, he can view all users affiliated to this org unit tree (or at least the first 20). He can select either the complete org unit (i.e. implicitly all users of this org unit) or he can select specific users to be added. In any case, after saving the action, he should get info message, that xxnumber of users have been added to his user group.
- There is no restriction on viewing users from other org units. admin can select users from different org units .therefore, checkboxes should be chosen to select users.
- Nice to have scenario: In addition, when assigning user privileges for a user, admin can assign the specific user as member of a specific user group.
- New use case: view user groups and their members for specific context. Possibility to add new members to group.
- Future development: Instead of one generic "audience"level, user can assign visibility to components to various user groups (additive)
Collaborator[edit]
- Visibility internal: can be accessed by QA role, but not viewed/opened by QA role. Does this make sense? Might be improvement for later. (not R5)
- Possible improvement for standard workflwo: owner can always modify his own items, independent from state of item. (not R5)
- Basic user info: Collaborator
- is a user role which allows access to items and its components
- access can be provided on item level or
- access can be provided on context level
- collaborators can access items during all states (from pending to released)
- OPEN: is it technically possible that collaborators can modify the collab item while pending, submitted, in revision, released? If yes, we need to define for which states.
- Do we need QA workspace for Collaborator, as he can access and modify?=> Proposal simple solution: No need for own workspace. The items, where I have access to as collaborator, should be listed under "my items". In addition, we need filter method to sort by "my own items" (i.e. i am depositor/owner) and "items for which i am collaborator". If filtering is not possible, we have to add specific icons(or similar) for the two types of items (i.e. my items or collaborator items)
- How to mark item as being accessible for collaborators or remove this possibility?: On view item page, we include new tab "collaboration". On this tab, QA role and Owner can see the item log (or parts of it, where collaborators have accessed and modified) and can add or remove the possibility for collaborators to access/modify this explicit item.In this context, he needs to have an info-button (link to context-sensitive help collaboration) to explain what does role collaborator mean. In case the role for collaboration has been defined for the complete scope of a context, the item property "collaboration item" cannot be removed. In this case, an information has to be displayed that "collaboration" has been defined for complete scope.
Audience[edit]
Audience is
- a user role
- a file visibility
- allows specific users to access released items and their components with file visibility "audience".
- The depositor/owner has no possibility to check the respective users/user groups with "audience rights" during submission. This has to be agreed on beforehand.
Todos:
- New use cases?
- Modify existing use cases?
- update PubMan Action Matrix
Related ToDos:
- PubMan Copyright => Update submission?
- Look-up services => Update view item?