Difference between revisions of "Talk:ESciDoc Access Rights"
| Line 86: | Line 86: | ||
<td>pending</td> | <td>pending</td> | ||
<td>Colaborator</td> | <td>Colaborator</td> | ||
<td>Component (thus Item | <td>Component (thus Item implicitly)</td> | ||
<td>No</td> | <td>No</td> | ||
</tr> | </tr> | ||
Revision as of 16:52, 8 December 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 | any user | System |
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)
- Outcome SvM Meeting: changes proposed, not critical: for withdrawn items, in addition to QA/Dpoesitor/DataAdmin, also collaborator should be able to view component (as he collaborated in creating it, and might want to re-use parts of it.)
Unclear: what does access mean? Editing, or access to escidocURI? For PubMan: withdrawn items should not be editable. In addition, withdrawn items should be "viewable" by providing concrete PID of withdrawn item (i.e. Metadata and number of components, i.e. view item version) but we are not clear, if this fact is described in the table. --Ulla 15:57, 8 December 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 Collaborator |
Context (for Collaborators: Context, Item, Component) | 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)