Talk:ESciDoc Access Rights

Meeting 19th march 2009: Consequences on eSciDoc Access rights on Enduser-features / "institutional visibility"

User Interface[edit]

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

Proposal for renaming labels (GUI)[edit]

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

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)

Changed :) --Natasa 16:56, 25 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)

Component visibility: Audience[edit]

Audience is

not a user role, but a set of users and/or user groups
a value for component visibility
allows specific users to access components marked with file visibility "audience" of released items.
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.

Further information is available in the minutes form ESciDoc Developer Workshop 2008-09-30

Scope[edit]

In section component visibility the article stats:

are granted with the role Audience for a defined scope.

Is this still in sync with the refined concept? What would be the "defined scope"? --Inga 20:22, 25 March 2009 (UTC)

Changed. Audience is not a role. --Natasa 08:16, 1 April 2009 (UTC)

Audience as term[edit]

DCMI defines/uses the term audience in following way:

Element Description: A class of entity for whom the resource is intended or useful.
A class of entity may be determined by the creator or the publisher or by a third party.

This definition does not include the access restriction mechanism envisioned by the eSciDoc concept. Maybe eSciDoc should use another term to avoid confusion? --Inga 20:08, 1 April 2009 (UTC)

Sorry, too late now for the infrastructure. This issue was agreed with FIZ longer time ago and is implemented in such manner. DCMI to my understanding does not consider any access-rights implementation. The access rights are separate issue. If we stick to "intended" in the description, and that it is "determined by the creator or the publisher or by a third party" it does not say anything about implemented/or not implemented access mechanisms. So we may have one underneath or not in any case :) --Natasa 08:10, 2 April 2009 (UTC)

Handling user groups: New and extended use cases[edit]

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 xx 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.

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.

assign privileges

extend use case for new or existing users, when assigning them user privileges, admin can assign the specific user as member of a specific user group.

view user groups and their members for specific context: Possibility to add new members to group.

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.
- what is this supposed to mean? doesn't closing a group simply mean canceling the memberships of all members - which will implicitely revoke all privileges they gained by the membership?--Robert 20:50, 25 March 2009 (UTC)

"close" user group is actually misleading. I think in this case it is meant "revoke all privileges from user group". In fact I am not aware on "close" user group functionality agreed with FIZ :) --Natasa 08:13, 2 April 2009 (UTC)

Future development: Instead of one generic "audience" level, user can assign visibility to components to various user groups (additive)

clarified on the meeting. Visibility is audience but in addition various user groups can be assigned to be audience. --Natasa 16:55, 25 March 2009 (UTC)

Role: Collaborator[edit]

Basic role info: Collaborator

is a user role which allows access to items and its components
access can be provided on
- item level or
- on context level or
- 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)

Ok, that's what is actually meant. --Natasa 08:14, 2 April 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)

Collaborator-viewer[edit]

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)
sounds to me as if the first type of collaborator is rather an observer. --Robert 20:56, 23 March 2009 (UTC)
What is the use case for collaborator-viewer? Note: If the administrators defined a specific workflow which is necessary to publish an item, the system shouldn't allow bypassing this setup by opening a back door to pending or submitted item --Inga 20:26, 25 March 2009 (UTC)

"Observer" is very exact and better term --Natasa 09:37, 2 April 2009 (UTC)

QA workspace for Collaborator[edit]

Do we need QA workspace for collaborators, 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)

Collaboration on item level[edit]

Question: Are we sure that PubMan users would like to specify "collaboration" on item level? That sounds pretty inconvenient and cumbersome to me. --Inga 20:45, 23 March 2009 (UTC)

In fact there is already a requirement from an institute. Secretary is a depositor, but all authors of the paper should be able to edit this paper (in any stage - but of course based on defined publication workflow). This is the use case for collaboration on item level. --Natasa 16:54, 25 March 2009 (UTC)

I agree that it's very easy to think up this use case, but I doubt it would be heavily used on PubMan - because

the secretary would need to administrate this on a item to item basis -> compare to file share where privileges are usually assigned on a directory level (= QArole to all users of the department)

is the secretary even in a position to administer this, i.e. grant collaborator privileges to users?--Robert 20:57, 25 March 2009 (UTC)

Will not be done via eSciDoc Admin, but via PubMan. According discussions with FIZ, each owner of an item/container should have privileges to assign collaborator role for his items/containers. --Natasa 08:22, 1 April 2009 (UTC)

PubMan is not an authoring tool like GoogleDocs where the scientists would collaborate on the content. It's "just" about the metadata... --Inga 19:03, 25 March 2009 (UTC)

Hi Inga, I think this is about us, but the following case: a publication with multiple authors, first MPI authors enters publication item, but all authors might want to add 'local tags' to that item, so that these tags can be used as selection criteria for their personal webpages! I think this is collaborator role on an item level and a real issue about the metadata.--Karin 20:27, 25 March 2009 (UTC)

Dear Karin, thanks for providing further details. I understand that scientists want to select items for a personal web page, but I'm not sure if this should be implemented "on the item". For me it looks like an overhead, that the first author need to provide the metadata and to select all co-authors as collaborators in addition. What happens if a new user is created - who was co-author of some publications before. Do all item owners need to update their "collaboration items" respectively? Alternative: In flickr, everyone can create any sets of pictures without requiring the owner to allow this explicitly. --Inga 20:55, 25 March 2009 (UTC)

It would be sufficient to add this user to "my collaborators group", and assign the group privilege for an item. --Natasa 08:22, 1 April 2009 (UTC)

So the idea is that each depositor maintains it's own user "my collaborators group". If a new member enters the department, all groups will be updated by the depositors accordingly? But I thought that groups can be managed by an administrator only. --Inga 20:27, 1 April 2009 (UTC)

In R5 --Natasa 09:34, 2 April 2009 (UTC)

However my original point was: If the use case is only about tagging an item for re-use in another context it might be laborious to store the information with the item (which requires a certain set of privileges) --Inga 20:27, 1 April 2009 (UTC)

The "local tagging" of an item is one of possible item modification - similar as modification of the metadata "title". Collaborators may update both "local tag" and "title" if they are allowed so (i.e. have modifying rights). We can not indeed prescribe the reasons "why" they may or may not do so. --Natasa 09:34, 2 April 2009 (UTC)

After reading the article PubMan_Feeding_local_webpages, I understood the envisioned design. But I'm still not sure if the usage of "local tags" is a reliable solution for the problem described by Karin. "Selecting a subset of released items" is a user-centered task for me - why to store it as an integral part of the item? Anyway, we can stop the discussion if the decision has been taken --Inga 19:19, 8 April 2009 (UTC)

Use case "component visibility" versus use case "collaboration"[edit]

In addition, I would suggest not to mix up

use case "provide access to components". It's probably a good idea to provide some additional access levels for components of released (!!!) items (e.g. security key, etc.). Anyway, if the administrators defined a specific workflow which is necessary to publish an item, the system shouldn't allow bypassing this setup by opening a back door to pending or submitted item --Inga 20:45, 23 March 2009 (UTC)

The access and a visibility "audience" is taking care of this issue. Collaboration is a special case, see above --Natasa 16:54, 25 March 2009 (UTC)

Do you agree that item components do not become visible to "public" or "audience" before the corresponding item version has been released? --Inga 19:21, 25 March 2009 (UTC)

Okay, that's how it's currently specified in the section Audience below --Inga 19:46, 25 March 2009 (UTC)

the use case "collaborate". If a group of people would like to collaborate on (a set of) items, this should be implemented with an specific context and related qa roles --Inga 20:45, 23 March 2009 (UTC)

This is also to be enabled with the collaborator role (to be assigned on a specific context). The difference between qa roles and a collaborator role is: collaborator can not submit or release an item, can only edit/modify an item in any state (but of course, depending on the workflow). --Natasa 16:54, 25 March 2009 (UTC)

I don't feel up to the mark any longer, but wasn't the "Metadata editor" supposed to be an user without submit and release privileges? But this role is currently restricted to submitted items? In addition: modifying a released item probably means submitting a new item version? --Inga 19:13, 25 March 2009 (UTC)

The "Metadata editor" role is defined for context and not for particular item and only for submitted items (collaborators may do so also on pending items). And yes, every modification is a new item version. The target status depends on decision of the user - he may save it as pending, submit/release it (depending on PubMan workflow). --Natasa 08:22, 1 April 2009 (UTC)

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)

How to mark item as being accessible for collaborators or remove this possibility?[edit]

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?

Item retrieval for pending/submitted items?[edit]

What is meant by "Implicitly: Item retrieval allowed for xxx"? Not via PubMan search I hope? --Inga 21:26, 23 March 2009 (UTC)

No, not via pubman search. --Natasa 16:57, 25 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)
- And in accordance with the respective publication workflow /(i.e. whenever Depositor is able to modify an item)
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)

Following CoLab pages need synchronization or need to be checked for PubMan visibility[edit]

Further questions and ideas[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)

Do not understand this point. If QA role can access the content with visibility "private" (and imho it can) - why QA role is not able to view/open this content? This is the same. --Natasa 09:36, 2 April 2009 (UTC)

Possible improvement for standard workflow: owner can always modify his own items, independent from state of item. (not R5)

except when the item is in state "withdrawn" --Natasa 09:36, 2 April 2009 (UTC)