Talk:ESciDoc Access Rights

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]

New system roles needed: "collaborator" and "audience".

"audience" is not a role --Natasa 13:04, 19 March 2009 (UTC)

AHJAHAHAHAH! But is mentioned on main page..."Audience - role granted to users,..."--Ulla 13:05, 19 March 2009 (UTC)

OPEN: Where to describe the assignment 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)

In user management, escidocadmin, in the same manner as user gets privileges for depositing into the context, user will be granted a role "collaborator" on context.--Natasa 13:05, 19 March 2009 (UTC)

new use case: create user group (e.g. all org unit users, e.g. specific account users)
- Admin decides to create user group
- He provides name and context for which user group is valid

if here administrative context is meant (e.g. pubman collection)- the above is not true. --Natasa 13:12, 19 March 2009 (UTC)

- 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.
New use case: assign privileges to user group
- admin selects user group defined for specific context
- admin selects one or more system rules to the group
- admin saves.
Extension use case "assign privileges": For new or existing users, when assigning them user privileges, 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: close user group
- admin selects user group
- admin closes group, with some comment.
- The privileges assigned on group level for this specific group are de-activated for each member. In case member had individual privileges , these privileges remain valid.
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 workflow: 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 or
- access can be provided on component level --Natasa 13:15, 19 March 2009 (UTC)
  As mentioned on main page access to item and component level are only provided combined: "Component (thus item implicitly), Item (thus all Components implicitly)". That's why we did not mention the component extra.--Friederike 08:10, 20 March 2009 (UTC)
- collaborators can access items during all states (from pending to released)
- OPEN: is it technically possible that collaborators can modify the shared item while pending, submitted, in revision, released? If yes, we need to define for which states.(Proposal: allow for all states. to be checked with Nicole/Natasa and MPI PL)
  There are two different types of collaborator roles now. One role is collaborator (only to access/view items), and another is the role of collaborator-modifier (in this case actually the role only gives grants for update, but in fact publication workflow rules apply as well). --Natasa 13:15, 19 March 2009 (UTC)
Do we need QA workspace for Collaborator, as he can access and modify?=> No good solution at hand. Proposal simple solution: No need for own workspace. The items, where I have access to as collaborator, should be listed under "my items": This means, that in addition to my own items (i.e. i am the owner), all items which have property "collaboration item" and are in the context(s) for which i have collaborator rights, are listed. All items, which have property "collaboration item" are marked with a symbol/icon. In addition, the user can filter for context(s) in the "My items" workspace. (So each collaboration might define/create its own context, and collaboration items can be filtered according to the context).Still, there is no possibility to filter/restrict the collaboration items for collaborations with specific users.

yes, this is best, to use it under My items. So to have "my items" workspace visible, user should have privileges as depositor or as collaborator-modifier to the context, or any of the items/components in this context. --Natasa 13:22, 19 March 2009 (UTC)

How to mark item as being accessible for collaborators or remove this possibility?:
- Item is created. Automatically, a separate tab "Collaboration" is provided on view item page. This tab can be accessed and modified by owner(?) and QAroles.(OPEN: behavior should be consistent with Local tags=> who can access/modify local tags? If only QA role can modify local tags, might be useful to be consistent)
  No, this will never be part of the item property and local tags. In next release (1.2 that is to come from FIZ in June) we will have a possibility to check if there are collaborators or not for this item. The argumentation: if you remove all collaborators from the item, you still need to modify local tags, as this item is no longer collaborated item. this will change the item version. Not good :) --Natasa 13:22, 19 March 2009 (UTC)
- Owner and QA roles can mark and un-mark the item as "collaboration item" on this tab. In case the role for collaboration has been defined for the complete scope of a context, the item cannot be un-marked. In this case, an information has to be displayed that "collaboration" has been defined for complete scope.In this context, user needs to have an info-button (link to context-sensitive help collaboration) to explain what does it mean to mark an item as collaboration item.
- Additionally, Collaborators can view this tab, but cannot mark/unmark.
- The users have no possibility to check the respective users/user groups with "collaborator rights" on the collaboration tab. This has to be agreed on beforehand.

- As soon as an item is marked as collaboration item, QA role, Owner and Collaborators can see the item log (or parts of it, where collaborators have accessed and modified)
TODO: Update use case view item for extensions "edit local tags" and "edit collaboration". Check with Natasa=>design?

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.

Proposal re-name of labels (GUI):
- during submission, public visibility is default. User is asked if he wants to restrict access. If yes, he has to choose between:
  - private
  - audience ( nicer label would be: group)
- on view item page:
  - rename "visibility" to "access"
  - maybe visualize level of access with icons/colors

Item[edit]

As Items can be marked as "collaboration items", we need new property (?). See collaborator workspace discussion.

no property should be written with respect to access rights if item is a collaboration item:) --Natasa 12:38, 19 March 2009 (UTC)

Todos[edit]

check with Nicole: Do we need role DataADmin for R5?
- MPI PL requirement?
Should collaborator be able to modify items?
- Assumption: yes, in all states (pending, submitted-in revision, released)
Write detailed new use cases
Update PubMan Action Matrix
Update view item use case
Prepare entry page to "PubMan access rights" (Melanie, in progress)
Synchronize information provided on various pages in CoLab, incl. PubMan Visibility, PubMan Func Spec Browsing and Displays and PubMan File Properties --Inga 19:30, 23 March 2009 (UTC)