Difference between revisions of "ESciDoc Access Rights"
Jump to navigation
Jump to search
Line 49: | Line 49: | ||
<td>pending</td> | <td>pending</td> | ||
<td>Colaborator</td> | <td>Colaborator</td> | ||
<td> | <td>Component (thus Item implicitly)</td> | ||
<td>No</td> | <td>No</td> | ||
</tr> | </tr> | ||
Line 63: | Line 63: | ||
<td>submitted</td> | <td>submitted</td> | ||
<td>Colaborator</td> | <td>Colaborator</td> | ||
<td> | <td>Component (thus item implicitly)</td> | ||
<td>No</td> | <td>No</td> | ||
</tr> | </tr> | ||
Line 77: | Line 77: | ||
<td>released</td> | <td>released</td> | ||
<td>Colaborator</td> | <td>Colaborator</td> | ||
<td>Context, Item, | <td>Component (thus item implicitly)</td> | ||
<td>No</td> | |||
</tr> | |||
<tr> | |||
<td>released</td> | |||
<td>Audience</td> | |||
<td>Component (thus item implicitly)</td> | |||
<td>Yes => Access level can be Public XOR Internal* XOR Group*</td> | |||
</tr> | |||
<tr> | |||
<td>withdrawn</td> | |||
<td>Depositor (if owner)<br/>DataAdmin<br/>QARole</td> | |||
<td>Context</td> | |||
<td>No</td> | |||
</tr> | |||
</table> | |||
===Access rules table for items=== | |||
<table border="1" cellpadding="4" cellspacing="0"> | |||
<tr> | |||
<th>Item status</th> | |||
<th>Who may access</th> | |||
<th>Where is access level defined</th> | |||
<th>Check for access level</th> | |||
</tr> | |||
<tr> | |||
<td>pending</td> | |||
<td>Depositor (only if owner)<br/>DataAdmin<br/></td> | |||
<td>Context</td> | |||
<td>No</td> | |||
</tr> | |||
<tr> | |||
<td>pending</td> | |||
<td>Colaborator</td> | |||
<td>Context, Item</td> | |||
<td>No</td> | |||
</tr> | |||
<tr> | |||
<td>submitted, in-revision</td> | |||
<td>Depositor (if owner)<br/>DataAdmin<br/>QARole</td> | |||
<td>Context</td> | |||
<td>No</td> | |||
</tr> | |||
<tr> | |||
<td>submitted</td> | |||
<td>Colaborator</td> | |||
<td>Context, Item</td> | |||
<td>No</td> | |||
</tr> | |||
<tr> | |||
<td>released</td> | |||
<td>Depositor (if owner)<br/>DataAdmin<br/>QARole</td> | |||
<td>Context</td> | |||
<td>No</td> | |||
</tr> | |||
<tr> | |||
<td>released</td> | |||
<td>Colaborator</td> | |||
<td>Context, Item</td> | |||
<td>No</td> | <td>No</td> | ||
</tr> | </tr> |
Revision as of 22:09, 3 October 2008
Work in progress
- based on meeting NBU, UTS, MFR
Related discussion[edit]
see ESciDoc Institutional Visibility Discussion
Retrieval of items and components[edit]
- Rule of thumb: a component (i.e. its content) cannot be evtl. retrieved by the user if she has privilege to view it's enclosing item
Description of the roles/groups in the access component rules table[edit]
- 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.
- Audience - role granted to users, user groups that can access the content when item is released
- Internal - access level is allowed for above mentioned roles of Depositor, DataAdmin, QARole
- Public - no access level restriction
- Group - Groups of users (account users, unregistered users) that can be authorized via single criteria or combination of:
- 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 component rules table[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 or group that can access the content associated with the component of the item.
- Where is role defined - The eSciDoc resource type for which the role or group has been associated when granting privilege for access
- Check for access level - Whether or not to check the access level for this role/group under specified conditions
Access rules table for Components[edit]
Item status | Who may access | Where is access level defined | 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 => Access level can be Public XOR Internal* XOR Group* |
withdrawn | Depositor (if owner) DataAdmin QARole |
Context | No |
Access rules table for items[edit]
Item status | Who may access | Where is access level defined | Check for access level |
---|---|---|---|
pending | Depositor (only if owner) DataAdmin |
Context | No |
pending | Colaborator | Context, Item | No |
submitted, in-revision | Depositor (if owner) DataAdmin QARole |
Context | No |
submitted | Colaborator | Context, Item | No |
released | Depositor (if owner) DataAdmin QARole |
Context | No |
released | Colaborator | Context, Item | No |
released | Audience | Component (thus item implicitly) | Yes => Access level can be Public XOR Internal* XOR Group* |
withdrawn | Depositor (if owner) DataAdmin QARole |
Context | No |
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: