Difference between revisions of "ESciDoc Access Rights"

From MPDLMediaWiki
Jump to navigation Jump to search
(→‎Component visibility: sentence marked because "audience" is no longer understood as role)
 
(3 intermediate revisions by 2 users not shown)
Line 15: Line 15:


===Component visibility===
===Component visibility===
*''Internal'' - content of the component can be accessed by Depositor (owner), DataAdmin, QARole
*''Public'' - no access level restriction
*''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:
*''Internal'' - content of the component can be accessed by Depositor (owner), DataAdmin, QARole, Collaborator (?)
*''Audience'' -  content of the component can be accessed by Depositor (owner), DataAdmin, QARole, Colaborator (?) 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 organizational units  
**List of account users
**List of account users
Line 26: Line 26:


==Description of the access rules tables==
==Description of the access rules tables==
<div style="color:red">'''NOTE: Has to be updated!'''</div>
*'''Item status''' - the public-status of the item. Item may have different public status then the status of the last version of the item.
*'''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.
*'''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.
Line 251: Line 252:
* Related discussion: [[ESciDoc_Institutional_visibility| ESciDoc Institutional Visibility Discussion]]
* Related discussion: [[ESciDoc_Institutional_visibility| ESciDoc Institutional Visibility Discussion]]
[[Category:ESciDoc|Access Rights]]
[[Category:ESciDoc|Access Rights]]
[[Category:Faces]]
[[Category:PubMan]]
[[Category:Functional specification]]
[[Category:Functional specification]]

Latest revision as of 11:23, 4 August 2009

Description of the roles/groups in the access rules tables[edit]

Please Note:
Following definitions apply to eSciDoc solutions only. In addition to this, the coreservice defines roles for accessing content (API Documentation Role), which are different to the solution-oriented rule.
This section handles access to item components only, e.g. the full text attached to a publication item. Therefore no information about containers is mentioned. (But these roles are important for both, items and containers.)

  • 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 and modify the containers, the items, their components and the internally managed content (content = uploaded files and not the locators).
  • Audience - set of users, user groups that can access the containers, the items, their components and the internally managed content (content = uploaded files and not the locators) when item is released in case when visibility for the component is set to "Audience". Various roles can be set-up as "Audience".

Definitions for used terms:

  • Content: Content is only the binary content (simply the file) which is uploaded to eSciDoc (i.e. internal managed)
  • Component: Component can contain also some metadata and a pointer to the content. The content in eSciDoc can be internal 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".

Component visibility[edit]

  • Public - no access level restriction
  • Internal - content of the component can be accessed by Depositor (owner), DataAdmin, QARole, Collaborator (?)
  • Audience - content of the component can be accessed by Depositor (owner), DataAdmin, QARole, Colaborator (?) 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]

NOTE: Has to be updated!
  • 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.
Access means only retrieval of a view item version page, no modification.
  • 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

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 any user System

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), Item (thus all Components implicitly), Context (thus all Items, all components implicitly) No
submitted, in-revision Depositor (if owner)
DataAdmin
QARole
Context No
submitted Colaborator Component (thus item implicitly), Item (thus all Components implicitly), Context (thus all Items, all components implicitly) No
released Depositor (if owner)
DataAdmin
QARole
Context No
released Colaborator Component (thus Item implicitly), Item (thus all Components implicitly), Context (thus all Items, all components implicitly) No
released Audience Component (thus item implicitly) Yes => Visibility level can be Public XOR Internal* XOR Audience*
withdrawn Depositor (if owner)
DataAdmin
QARole
Collaborator
Context (for Collaborators: Context, Item, Component) No

Access rules table for Containers[edit]

Item status Who may access Where is access level defined (scope) Remarks
pending Depositor (only if owner)
DataAdmin
Context
pending Collaborator Context, Container
released any user System But the components of the items within the container are only visible as above specified.
withdrawn any user System But the components of the items within the container are only visible as above specified.

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

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

Discussions[edit]