Difference between revisions of "Talk:ESciDoc Access Rights"

Revision as of 11:23, 28 November 2008

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

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]

Description of the access rules tables[edit]

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.

Again, decision by SvM. DevTeam is fine with any solution. At present PubMan does not allow download of Files for withdrawn items, neither the itemhandler however does - so i do not see how this would change the implementation at any level. --Natasa 10:12, 28 November 2008 (UTC)

@@ Line 1: / Line 1: @@
 ===Description of the roles/groups in the access rules tables===
-<font color="#FF0000">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.</font>
-: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. --[[User:Natasab|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 <font color="#FF0000">can access the content and items</font> 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'''--[[User:Natasab|Natasa]] 09:56, 28 November 2008 (UTC)
-:: where '''internaly managed content''' - are files uploaded and not the locators --[[User:Natasab|Natasa]] 09:56, 28 November 2008 (UTC)
-*'''Audience''' - role granted to users, user groups that <font color="#FF0000">can access the component and its content</font> 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'''--[[User:Natasab|Natasa]] 09:56, 28 November 2008 (UTC)
-:: where '''internaly managed content''' - are files uploaded and not the locators --[[User:Natasab|Natasa]] 09:56, 28 November 2008 (UTC)
-<font color="#FF0000">Unclear: Difference between Collaborator and Audience:
-* Why can the collaborator access the '''content''' and the audience access the '''component and its content'''? </font>
-**typo, both were meant for component and its content, i also extended the definition to "internaly managed content" --[[User:Natasab|Natasa]] 09:56, 28 November 2008 (UTC)
-<font color="#FF0000">* Whats the difference between these two?</font>
-**Collaborator can work on items i.e. update, modify etc., while audience can only view them --[[User:Natasab|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 --[[User:Natasab|Natasa]] 09:56, 28 November 2008 (UTC)
-<font color="#FF0000">* What exactly is the content of a component (we always thought that a component is a fulltext)? </font>
-<font color="#FF0000">:* Content (e.g. just full text of a component ???) </font>
-::Content is only the binary content (simply the file which is uploaded) uploaded to eSciDoc (i.e. internaly managed) --[[User:Natasab|Natasa]] 09:56, 28 November 2008 (UTC)
-<font color="#FF0000">:* Component (e.g. Metadata and full text???)</font>
-::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" --[[User:Natasab|Natasa]] 09:56, 28 November 2008 (UTC)
 <font color="#FF0000">
@@ Line 27: / Line 5: @@
 * 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) --[[User:Natasab|Natasa]] 09:59, 28 November 2008 (UTC)
 ====Component visibility====
-**''Internal'' - content of the component can be accessed by Depositor <font color="#FF0000">(owner)</font>, DataAdmin, QARole
-:<font color="#FF0000">(owner)</font> - 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) --[[User:Natasab|Natasa]] 10:04, 28 November 2008 (UTC)
-**''Public'' - no access level restriction
-**''Audience'' -  content of the component can be accessed by Depositor<font color="#FF0000">(owner)</font>, 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===
-*'''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
-<font color="#FF0000">
-A Description for "Where is access level defined (scope)" is missing.</font>
-:Done --[[User:Natasab|Natasa]] 10:06, 28 November 2008 (UTC)
 ===Access rules table for Items===
@@ Line 173: / Line 134: @@
 :Again, decision by SvM. DevTeam is fine with any solution. At present PubMan does not allow download of Files for withdrawn items, neither the itemhandler however does - so i do not see how this would change the implementation at any level. --[[User:Natasab|Natasa]] 10:12, 28 November 2008 (UTC)
-====Example====
-* '''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====
-*'''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====
-*'''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