Difference between revisions of "PubMan Func Spec Visibility"

From MPDLMediaWiki
Jump to navigation Jump to search
 
(95 intermediate revisions by 6 users not shown)
Line 1: Line 1:
'''WORK IN PROGRESS!!!'''
'''WORK IN PROGRESS!!!'''
==Definitions and user role descriptions==
===Item===
===Component===
===Content===


==Visibility for items==
=Visibility for items=
Item visibility in PubMan depends on user roles. See [[ESciDoc_Access_Rights#Access_rules_table_for_Items| Access rules for Items]]
Item visibility in PubMan depends on item status and user role:
If an item is in state "released" or "withdrawn", any user can see and access the item, i.e. the item skeleton and the metadata of the publication. Still, component visibility and access to content, i.e. access to full text of the respective publication, can be restricted according to the user role and visibility level of the component. See [[ESciDoc_Access_Rights#Access_rules_table_for_Components|Access rules for Components]]


==Visibility for item components==
{| border="1"
|width="300pt"|'''Item status'''
|width="400pt"|'''Who may access'''
|-
|pending
|Depositor (only if owner) <br>
Collaborator
|-
|submitted (as well as submitted, in re-vision)
|Depositor (only if owner)<br>
Moderator (QARole)<br>
Collaborator
|-
|released
|any user
|-
|withdrawn
|any user (only with known eSciDoc ID)
|}
<br>
=Visibility for item components=


===Visibility levels for item components===
There are two levels of visibility for components in PubMan:
* ''public'' and
* ''private (''is to be renamed to ''restricted'').
By default, component visibility level is set to ''public'' during easy and full submission.
 
For ''restricted'' there are two further possibilities:
* ''private'' and
* ''audience''.
For both visibility level, ''private'' and ''audience'' it's possible to provide an embargo date. If a user is not the owner and does not have special rights to access the component(s) of an item, the respective component(s) is/are not visible to the user until the visibility is re-set to public, most probably after the embargo period..
 
<br>
Component visibility in Pubman depends on item status, access level of component and user role:


There are two levels of visibility for components in PubMan:
{| border="1"
* "public" and
|width="100pt"|'''Item status'''
* "private" (is to be renamed "restricted").
|width="200pt"|'''Access level of component'''
By default, component visibility level is set to "public" during easy and full submission.
|width="250pt"|'''Who may access'''
|-
|'''pending'''
|-
|pending
|'''public'''
|Depositor (only if owner) <br>
Collaborator
|-
|pending
|'''restricted - private'''
|Depositor (only if owner)<br>
Collaborator
|-
|pending
|'''restricted - audience'''
|Depositor (only if owner) <br>
Collaborator
|-
|'''submitted'''
|-
|submitted
|'''public'''
|Depositor (only if owner)<br>
Moderator (QARole)<br>
Collaborator
|-
|submitted
|'''restricted - private'''
|Depositor (only if owner)<br>
Moderator (QARole)<br>
Collaborator
|-
|submitted
|'''restricted - audience'''
|Depositor (only if owner)<br>
Moderator (QARole)<br>
Collaborator
|-
|'''released'''
|-
|released
|'''public'''
|all users
|-
|released
|'''restricted - private'''
|Depositor (only if owner) <br>
Moderator (QARole) <br>
Privileged Viewer
|-
|released
|'''restricted - audience'''
|Depositor (only if owner)<br>
Moderator (QARole) <br>
Respective Usergroup / Organizational Unit<br>
Privileged Viewer
|}
<br>


For "restricted" there are two possibilities:
=Institutional Visibility Scenario=
* "private" and
By assigning institutional visibility to components of an item, the user is able to choose an audience group which is privileged to access restricted components of released items. Every user independently of his/her role can be "audience".  
* "audience".  
==Where is the access level of the component defined?==
Both, "private" and "audience" can have restriction "embargo", which means, if a user is not the owner of an item but has special rights to access the component(s) of this item, the respective component(s) are not visible to the user until the embargo time is over.
*''audience'' privileges can be assigned for single components


* public access means, any user of PubMan can access the item component
==What has to be done on admin interface?==
* restricted access means, only the owner of an item and selected users can access item component
*the admin is responsible for creating collaborative usergroups
** for private access this means, the owner of an item can access the item component
**not for R5, but later: local admin on each institute
** for audience access this means, in addition to the owner of an item users belonging to specific user groups can access the item component
*the user sets file visibility on audience level and informs the admin about the desired members of the audience group (selectable by Organizational Units for now) and the chosen name of the collaboration group
**future development: choose single persons to create a usergroup
*the admin creates the respective audience group -> informs the enrollee
*one audience usergroup can consist of multiple Organizational Units
*name of the usergroup = new value for audience selection during submission
*notify user when a user group is created for OU when there is no user associated with this OU
<br>
*for BT: creation of a dummy audience group -> for demonstration on PubMan workshop


===Assign visibility level for component(s)===
==PubMan workflow for assigning institutional visibility during submission==
*the user uploads a file
*as mentioned above, the system default visibility level for components is "public"
*the user wants to change visibility level
*he/she chooses component visibility level "restricted"
*afterwards the user chooses, whether the restricted access should be "private" or "audience"
*he/she chooses visibility level "audience"
*when he/she submits/releases the item, a message shows up, that visbility is set on "audience" and that the user has to apply for the creation of one or multiple usergroups by contacting the admin (-> needs also documentation in PubMan Help)
*after the creation of the desired audience group/s by the admin, on the audience tab it's possible for the user to choose the respective audience group from a list of displayed user groups
**all existing audience usergroups are displayed in this select list (sort by name)
*** NOTE: users has to be defined on department level instead of institute level
*the user is able to choose more than one audience usergroup
**future development: provide possibility to choose single persons of various OUs for audience groups
*any user within the chosen user group(s) can access the item component as soon as the item is released (but no right to modify for ''audience'' group)
*after an item is released it is possible to add/de-select usergroups at any time
<br>


* As mentioned above, the system default visibility level for components is "public".
==Who is able to assign audience privileges?==
* The user wants to change the visibility level.
*the visibility level for a component can be assigned/changed by
* The user chooses component visibility level "restricted".
**the owner of the item (Depositor)
* The user chooses, if the restricted access should be "private" or "audience".
**a user with QA role (Moderator)
** The user chooses the visibility level "private". Any user with user role privileged viewer for the item context can now access the item component and its content.
**NOTE: a Collaborator-Modifier is not able to assign audience priviliges to user groups; he/she is able to upload a file and set visibiity on "audience", but the audience usergroup/s has/have to be chosen by the Depositor or QARole
** The user chooses the visibility level "audience".
*** The user can choose a user group from the list of user groups displayed. These user groups are based on organizational unit level. More than one organizational unit can belong to a user group. For the future, organizational units and single users can be mixed within a user group.
*** Any user within the chosen user group(s) can now access the item component and its content.
* The visibility level for a component can be changed by the owner of the item and a user with QA role.


==Collaborator user roles==
==PubMan Item View==
: Ich wuerde hier den Collaboration nicht einzeln beschreiben! Oder soll das fuer alle QARollen auch passieren?
*metadata information
**component ''x''
*** visibility:
::a) "''visibility for usergroup x''" (prefered scenario)
::b) "''restricted-audience''" (alternative scenario - depends on FIZ)


The Collaborator is a user role that can be assigned to give user access on context level and item level. Access on component level will be possible in the future.
==PubMan Advanced Search==
*query for visibility "audience" is possible
**but no possibility to search for special usergroups


The Collaborator is split in two roles:
==New Use Cases==
* Collaborator who has only rights to view items in all states
*UC create audience usergroup on PubMan (audience tab)
* Collaborator who has rights to view and modify
*UC create audience usergroup for context on admin interface
*UC assign privileges to user group for context (e.g. all secretaries are Depositors)
*UC add members to audience usergroup (at first (R5) just the list of OUs;  later a list of single persons)
<br>


=Definitions and user role descriptions=


==Definition of used terms==


{| border="1"
|width="150pt"|'''Term'''
|width="900pt"|'''Definition'''
|-
|'''Item'''
|In PubMan an item contains all metadata and its attached files describing a special type of document which is stored in the repository.
|-
|'''Content'''
|Content is only the binary content (simply the file) which is uploaded to PubMan.
|-
|'''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.
|-
|'''Context'''
|Context are the administrative units for management of the publication items. One or more organizational units are responsible for a context.
|}


==Definition of mentioned user roles==


{| border="1"
|width="150pt"|'''Term'''
|width="900pt"|'''Definition'''
|-
|'''Depositor'''
|Role that when granted allows to ''create items'' in the repository and ''manage items'' (including components and their content) he/she created in accordance with the overall workflow rules.
|-
|'''Moderator'''
|QARole
Is responsible for the ''quality assurance'' of the data.
|-
|'''Collaborator'''
|Two different types of collaborators: ''collaborator-viewer'' & ''collaborator-modifier''.
Role that when granted allows ''access and/or modify the containers, the items, their components and the internally managed content'' independently of item state.
|-
|'''Privileged Viewer'''
|Role that when granted ''allows to access all components and their content of a released item'' in one context/collection independently of visibility.
|}


=Related Pages=
*[http://colab.mpdl.mpg.de/mediawiki/PubMan_Func_Spec_User_Management#UC_PM_UM_10_create_user_group UC Create Usergroup]
*[http://colab.mpdl.mpg.de/mediawiki/PubMan_Func_Spec_User_Management#UC_PM_UM_11_Grant_or_revoke_audience_privileges_for_files UC Grat or revoke aufience privileges for files]
*[http://colab.mpdl.mpg.de/mediawiki/PubMan_Func_Spec_User_Management#UC_PM_UM_12_Revoke_audience_privileges_for_files UC Revoke audience privileges for files]


[[Category:PubMan|Visibility]]
[[Category:PubMan_Functional_Specification|Visibility]]

Latest revision as of 09:52, 16 December 2011

WORK IN PROGRESS!!!

Visibility for items[edit]

Item visibility in PubMan depends on item status and user role:

Item status Who may access
pending Depositor (only if owner)

Collaborator

submitted (as well as submitted, in re-vision) Depositor (only if owner)

Moderator (QARole)
Collaborator

released any user
withdrawn any user (only with known eSciDoc ID)


Visibility for item components[edit]

There are two levels of visibility for components in PubMan:

  • public and
  • private (is to be renamed to restricted).

By default, component visibility level is set to public during easy and full submission.

For restricted there are two further possibilities:

  • private and
  • audience.

For both visibility level, private and audience it's possible to provide an embargo date. If a user is not the owner and does not have special rights to access the component(s) of an item, the respective component(s) is/are not visible to the user until the visibility is re-set to public, most probably after the embargo period..


Component visibility in Pubman depends on item status, access level of component and user role:

Item status Access level of component Who may access
pending
pending public Depositor (only if owner)

Collaborator

pending restricted - private Depositor (only if owner)

Collaborator

pending restricted - audience Depositor (only if owner)

Collaborator

submitted
submitted public Depositor (only if owner)

Moderator (QARole)
Collaborator

submitted restricted - private Depositor (only if owner)

Moderator (QARole)
Collaborator

submitted restricted - audience Depositor (only if owner)

Moderator (QARole)
Collaborator

released
released public all users
released restricted - private Depositor (only if owner)

Moderator (QARole)
Privileged Viewer

released restricted - audience Depositor (only if owner)

Moderator (QARole)
Respective Usergroup / Organizational Unit
Privileged Viewer


Institutional Visibility Scenario[edit]

By assigning institutional visibility to components of an item, the user is able to choose an audience group which is privileged to access restricted components of released items. Every user independently of his/her role can be "audience".

Where is the access level of the component defined?[edit]

  • audience privileges can be assigned for single components

What has to be done on admin interface?[edit]

  • the admin is responsible for creating collaborative usergroups
    • not for R5, but later: local admin on each institute
  • the user sets file visibility on audience level and informs the admin about the desired members of the audience group (selectable by Organizational Units for now) and the chosen name of the collaboration group
    • future development: choose single persons to create a usergroup
  • the admin creates the respective audience group -> informs the enrollee
  • one audience usergroup can consist of multiple Organizational Units
  • name of the usergroup = new value for audience selection during submission
  • notify user when a user group is created for OU when there is no user associated with this OU


  • for BT: creation of a dummy audience group -> for demonstration on PubMan workshop

PubMan workflow for assigning institutional visibility during submission[edit]

  • the user uploads a file
  • as mentioned above, the system default visibility level for components is "public"
  • the user wants to change visibility level
  • he/she chooses component visibility level "restricted"
  • afterwards the user chooses, whether the restricted access should be "private" or "audience"
  • he/she chooses visibility level "audience"
  • when he/she submits/releases the item, a message shows up, that visbility is set on "audience" and that the user has to apply for the creation of one or multiple usergroups by contacting the admin (-> needs also documentation in PubMan Help)
  • after the creation of the desired audience group/s by the admin, on the audience tab it's possible for the user to choose the respective audience group from a list of displayed user groups
    • all existing audience usergroups are displayed in this select list (sort by name)
      • NOTE: users has to be defined on department level instead of institute level
  • the user is able to choose more than one audience usergroup
    • future development: provide possibility to choose single persons of various OUs for audience groups
  • any user within the chosen user group(s) can access the item component as soon as the item is released (but no right to modify for audience group)
  • after an item is released it is possible to add/de-select usergroups at any time


Who is able to assign audience privileges?[edit]

  • the visibility level for a component can be assigned/changed by
    • the owner of the item (Depositor)
    • a user with QA role (Moderator)
    • NOTE: a Collaborator-Modifier is not able to assign audience priviliges to user groups; he/she is able to upload a file and set visibiity on "audience", but the audience usergroup/s has/have to be chosen by the Depositor or QARole

PubMan Item View[edit]

  • metadata information
    • component x
      • visibility:
a) "visibility for usergroup x" (prefered scenario)
b) "restricted-audience" (alternative scenario - depends on FIZ)

PubMan Advanced Search[edit]

  • query for visibility "audience" is possible
    • but no possibility to search for special usergroups

New Use Cases[edit]

  • UC create audience usergroup on PubMan (audience tab)
  • UC create audience usergroup for context on admin interface
  • UC assign privileges to user group for context (e.g. all secretaries are Depositors)
  • UC add members to audience usergroup (at first (R5) just the list of OUs; later a list of single persons)


Definitions and user role descriptions[edit]

Definition of used terms[edit]

Term Definition
Item In PubMan an item contains all metadata and its attached files describing a special type of document which is stored in the repository.
Content Content is only the binary content (simply the file) which is uploaded to PubMan.
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.
Context Context are the administrative units for management of the publication items. One or more organizational units are responsible for a context.

Definition of mentioned user roles[edit]

Term Definition
Depositor Role that when granted allows to create items in the repository and manage items (including components and their content) he/she created in accordance with the overall workflow rules.
Moderator QARole

Is responsible for the quality assurance of the data.

Collaborator Two different types of collaborators: collaborator-viewer & collaborator-modifier.

Role that when granted allows access and/or modify the containers, the items, their components and the internally managed content independently of item state.

Privileged Viewer Role that when granted allows to access all components and their content of a released item in one context/collection independently of visibility.

Related Pages[edit]