Talk:ESciDoc Access Rights
Revision as of 10:08, 28 November 2008 by Natasab (talk | contribs) (→Access rules table for Items)
Description of the roles/groups in the access rules tables[edit]
Unclear: Are these access rules only concerning pubMan? Or are these access rules for all solutions (as the page title says)? Because there is no information about containers, which would be relevant for Faces.
- In my understanding these roles are important for both items and containers. However, as this section was only about access to Fulltext, and containers do not have fulltext (i.e. components+content) associated they were not mentioned in here. --Natasa 09:44, 28 November 2008 (UTC)
- Depositor - role that when granted allows to create items in the repository and manage items (including components and their content) she created in accordance with the overall workflow rules.
- DataAdmin - role that when granted allows to create items and manage items (including components and their content) independently from their ownership and in accordance with the overall workflow rules.
- QARole - placeholder for roles in the system that are responsible for the quality assurance of the data e.g. Metadata editor, Moderator, Authority, Rights checking.
- Collaborator - role granted to users, user groups that can access the content and items under specified conditions of item and version statuses.
- Should be can access and modify the containers, the items, their components and the internally managed content--Natasa 09:56, 28 November 2008 (UTC)
- where internaly managed content - are files uploaded and not the locators --Natasa 09:56, 28 November 2008 (UTC)
- Audience - role granted to users, user groups that can access the component and its content when item is released in case when visibility for the component is set to "Audience".
- can access the containers, the items, their components and the internally managed content--Natasa 09:56, 28 November 2008 (UTC)
- where internaly managed content - are files uploaded and not the locators --Natasa 09:56, 28 November 2008 (UTC)
Unclear: Difference between Collaborator and Audience:
- Why can the collaborator access the content and the audience access the component and its content?
- typo, both were meant for component and its content, i also extended the definition to "internaly managed content" --Natasa 09:56, 28 November 2008 (UTC)
* Whats the difference between these two?
- Collaborator can work on items i.e. update, modify etc., while audience can only view them --Natasa 09:56, 28 November 2008 (UTC)
- additionally, audience is only applicable for released items/containers, while collaborator is applicable for any status (pending, submitted, released), see table --Natasa 09:56, 28 November 2008 (UTC)
* What exactly is the content of a component (we always thought that a component is a fulltext)? :* Content (e.g. just full text of a component ???)
- Content is only the binary content (simply the file which is uploaded) uploaded to eSciDoc (i.e. internaly managed) --Natasa 09:56, 28 November 2008 (UTC)
:* Component (e.g. Metadata and full text???)
- Component can contain also some metadata and a pointer to the content. The content in eSciDoc can be internally managed (what in pubman is called "File", or externally referenced - what in pubman is called "Locator"). In core services i.e. in the components.xsd schema of eSciDoc this is known as "storage" property of the component. Thus there are three types of storage property: "internal-managed", mentioned above, "external-url" - mentioned above, external-managed means a "special locator" where eSciDoc is moderating the access to this component. We do not use at present "external-managed" --Natasa 09:56, 28 November 2008 (UTC)
Question: This definitions are diffferent from the definitions given by FIZ (API Documentation Role). Why? --Kristina 08:39, 27 November 2008 (UTC)
- Answer: Two different role specifications for coreservice and solutions. Therefor the PubMan roles are different to coreservice roles. --Nicole
- Also from historical reasons, as we were not certain on what are our roles. We do have however the possibility to define our roles as they should be (and probably we should actually try to do it after we get the improvements from FIZ regarding access to content) --Natasa 09:59, 28 November 2008 (UTC)
Component visibility[edit]
- Internal - content of the component can be accessed by Depositor (owner), DataAdmin, QARole
- (owner) - here is meant not any user in role of Depositor, but only the user who has the Role of Despositor and who created the item (that's owner) --Natasa 10:04, 28 November 2008 (UTC)
- Public - no access level restriction
- Audience - content of the component can be accessed by Depositor(owner), DataAdmin, QARole and additional users or groups of users are granted with the role Audience for a defined scope. Groups of users can be defined via:
- List of organizational units
- List of account users
- Shibboleth attributes
- Key/Certificate based (unregistered user) (status: not planned for release 1.0 of core services)
- Audience and Collaborator roles differ by their access rights during the Item workflow. In addition, Colaborator role may have modification privileges (not yet described in here).
Description of the access rules tables[edit]
- Item status - the public-status of the item. Item may have different public status then the status of the last version of the item.
- Who may access - Name of the role with which user should be granted to access the item and or the content associated with the component of the item.
- Where is role defined - The eSciDoc resource type for which the role has defined scope when granting privilege for access
- Check for access level - Whether or not to check the access level for this role/group under specified conditions
- Where is access level defined (scope) - points to a resource where the access level is defined, i.e. a user has been granted with a role for a resource
A Description for "Where is access level defined (scope)" is missing.
- Done --Natasa 10:06, 28 November 2008 (UTC)
Access rules table for Items[edit]
| Item status | Who may access | Where is access level defined (scope) |
|---|---|---|
| pending | Depositor (only if owner) DataAdmin |
Context |
| pending | Colaborator | Context, Item |
| submitted, in-revision | Depositor (if owner) DataAdmin QARole |
Context |
| submitted, in-revision | Colaborator | Context, Item |
| released | any user | System |
| withdrawn | Depositor (if owner) DataAdmin QARole |
Context |
withrawn: unclear, every user should be able to access this item via a given url. The item should be accessible via the ws of the depositor (owner) and the dataAdmin. Why not the Collaborator.
- That was also proposal from Dev. Was decided by SvM not to offer withdrawn items to anybody but to the internal users i.e. depositor, data Admin. And probably the decision is good and makes sense as i see no reason why would a Collaborator need to work with withdrawn items when nobody else can --Natasa 10:08, 28 November 2008 (UTC)
Access rules table for Components[edit]
| Item status | Who may access | Where is access level defined (scope) | Check for access level |
|---|---|---|---|
| pending | Depositor (only if owner) DataAdmin |
Context | No |
| pending | Colaborator | Component (thus Item implicitly) | No |
| submitted, in-revision | Depositor (if owner) DataAdmin QARole |
Context | No |
| submitted | Colaborator | Component (thus item implicitly) | No |
| released | Depositor (if owner) DataAdmin QARole |
Context | No |
| released | Colaborator | Component (thus item implicitly) | No |
| released | Audience | Component (thus item implicitly) | Yes => Visibility level can be Public XOR Internal* XOR Audience* |
| withdrawn | Depositor (if owner) DataAdmin QARole |
Context | No |
withdrawn: this would mean change of existing implementation where a withdrawn full text can not be accessed any more.
Example[edit]
- Item A is created by Depositor D in context C and consist of:
- Component C1
- Component C2
- QA User 1 - has QA role assigned for context C
- QA User 2 - has QA role assigned for context C, context D
Case 1[edit]
- Depositor D gives Internal access for Component C2 and Public access for Component C1
- Depositor D gives additionally access to Colaborator User U and to Colaborator Person P for Component C2
- Colaborator User U - is account user and is known to the system via his/her user account
- Colaborator Person P - is a system visitor who received a security "Key" from Depositor D with which s/he can access the Component C2
- According to the upper table:
- When item is in Pending status, beside Depositor D:
- Component C1 can be accessed by DataAdmin
- Component C2 can be accessed by Colaborator User U, Colaborator Person P and DataAdmin
- Implicitly: Item retrieval allowed for Colaborator User U, Colaborator Person P and DataAdmin
- When item is in Submitted status, beside Depositor D:
- Component C1 can be accessed by DataAdmin, QA User 1, QA User 2
- Component C2 can be accessed by Colaborator User U, Colaborator Person P, DataAdmin, QA User 1, QA User 2
- Implicitly: Item retrieval allowed for Colaborator User U, Colaborator Person P, DataAdmin, QA User 1, QA User 2
- When item is in Pending status, beside Depositor D:
- When item is in Released status, beside Depositor D:
- Component C1 can be accessed by any user (i.e. Audience=Public)
- Component C2 can be accessed by Colaborator User U, Colaborator Person P, DataAdmin, QA User 1, QA User 2
- Implicitly: Item retrieval allowed for all users
- When item is in Withdrawn status, beside Depositor D:
- Component C1 can be accessed by DataAdmin, QA User 1, QA User 2
- Component C2 can be accessed by DataAdmin, QA User 1, QA User 2
- Implicitly: Item retrieval allowed for all users
- When item is in Released status, beside Depositor D:
Case 2[edit]
- Depositor D gives Internal access for Component C2 and MPG wide access for Component C1
- Depositor D gives additionally access to Colaborator User U and to Colaborator Person P for Component C2
- Colaborator User U - is account user and is known to the system via his/her user account
- Colaborator Person P - is a system visitor who received a security "Key" from Depositor D with which s/he can access the Component C2
- According to the upper table:
- When item is in Pending status, beside Depositor D:
- Component C1 can be accessed by DataAdmin
- Component C2 can be accessed by Colaborator User U, DataAdmin and Colaborator Person P
- Implicitly: item retrieval allowed for Colaborator User U, DataAdmin and Colaborator Person P
- When item is in Submitted status, beside Depositor D:
- Component C1 can be accessed by DataAdmin, QA User 1, QA User 2
- Component C2 can be accessed by Colaborator User U, Colaborator Person P, DataAdmin, QA User 1, QA User 2
- Implicitly: item retrieval allowed for Colaborator User U, DataAdmin and Colaborator Person P, QA User 1, QA User 2
- When item is in Released status, beside Depositor D:
- Component C1 can be accessed by any user that comes from MPG (i.e. Audience="MPG wide")
- Component C2 can be accessed by Colaborator User U, Colaborator Person P, DataAdmin, QA User 1, QA User 2
- Implicitly: item retrieval allowed for all users
- When item is in Withdrawn status, beside Depositor D:
- Component C1 can be accessed by DataAdmin, QA User 1, QA User 2
- Component C2 can be accessed by DataAdmin, QA User 1, QA User 2
- Implicitly: item retrieval allowed for all users
- When item is in Pending status, beside Depositor D: