PubMan Func Spec Visibility

From MPDLMediaWiki
Revision as of 16:00, 25 May 2009 by Juliane (talk | contribs) (added links to respective use cases)
Jump to navigation Jump to search

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]