Talk:PubMan Func Spec Visibility

Visibility for item components

Both, "privat" 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.

I assume that this feature would be wanted for "public" as well --Inga 18:17, 25 March 2009 (UTC)

But when component is "public" embargo period has no effect. In the workflow, embargo date imposes audience or private visibility. When embargo period is finished, the visibility is set to Public. --Natasa 07:50, 1 April 2009 (UTC)

i wonder if it wouldn't be easier to view the embargo as orthogonal to visibility, i.e. define the envisioned/planned/target visibility, and regard the embargo just as a time of no-access until this target visibility takes effect. - at least that was my first intuition of what an embargo means, plus i'd think it would be easy to implement.--Robert 17:23, 1 April 2009 (UTC)

Maybe this shift would also enable an "auto-submit" and/or "auto-release" after expiration, because the user explicitly selected the visibility and the system only enforces this decision after the embargo expired --Inga 19:18, 1 April 2009 (UTC)

[...] a user with user role "privileged viewer" can access the item component and its content

isn't the role "privileged viewer" superfluous, once we have restricted access governed by user groups - thus making the distinction between "private" and "audience" superfluous, too?--Robert 18:20, 25 March 2009 (UTC)

The "privileged viewer" role was introduced before any audience roles was introduced, as we did not have any groups. The scope on which privileged viewer role was introduced before was a "context". The "audience" is a visibility level of a component. Therefore, when we set-up for a component visibility "audience" and define for which user groups is allowed, these user groups in fact are getting a role "privileged viewer" for the appointed component to my understanding.

i'm confused. is audience a role? and didn't the privileged viewers get access for restricted components of type "private"? so i'd maintain, the distinction between "audience" and "private" remains unclear to me.--Robert 17:12, 1 April 2009 (UTC)

No, audience is not a role. Every user can have audience privileges. If you are audience you can access restricted components of released items. The privileged viewer can also access restricted files of released items. The difference is, that users with audience privileges can only access selected restricted components and only these components with visibility set on "restricted-audience", but not files with visibility set on "restricted - private". A privileged viewer however is able to see both types of restricted components. And moreover he/she is able to see all restricted components of released files in one context. --Juliane 14:42, 3 April 2009 (UTC)

Note: "privileged viewer" is a role defined for the "coreservice" and not mentioned on ESciDoc_Access_Rights#Description_of_the_roles.2Fgroups_in_the_access_rules_tables --Inga 18:28, 25 March 2009 (UTC)

regarding "Depositor (only if owner)": how can a depositor not be owner of an item?--Robert 11:29, 30 March 2009 (UTC)

User may have a role of depositor for a context, but does not have to create ALL items in the context e.g.

  Robert has Role of Depositor for Ctx 1
  Natasa has Role of Depositor for Ctx 2
  Robert creates item1
  Natasa creates item2
  Robert is Depositor (and owner of item1, but not item 2)
  Natasa is Depositor (and owner of item 2, but not item 1)

Hopefully this clarifies --Natasa 07:50, 1 April 2009 (UTC)

yes, thanks. but i still think, the "only if owner" is superfluous, because we also don't qualify the other roles like "Collaborator (only if collaborator for this item)".--Robert 17:16, 1 April 2009 (UTC)

Closed

What is the difference between the item component and its content? --Inga 18:22, 25 March 2009 (UTC)

if with this question is meant what is the "access level difference" -> the difference is the content retrieval e.g. component has properties and metadata. For released items, component metadata (as well as item metadata) are always visible, but not the content. --Natasa 07:50, 1 April 2009 (UTC)

Sorry Natasa, this question was related to a former version of the article. The question lost its context after: http://colab.mpdl.mpg.de/mediawiki/index.php5?title=PubMan_Visibility&diff=prev&oldid=31329 ;) --Inga 19:35, 1 April 2009 (UTC)

Institutional Visibility Scenario

The current scenario only describes how to define access for individual item components. Maybe it's a good idea to restrict the complete concept to this functionality - and to forget about visibility attribute on item level. --Inga 13:54, 31 March 2009 (UTC)

You're right -> we decided to configure the scenario like you proposed :) Thanks! --Juliane 14:47, 3 April 2009 (UTC)

PubMan workflow for defining Collaborators/collaborative groups

The specification states:

workflow overrules collaboration type -> when item is released, the collaboration is over 

Isn't this contradicting the use case (see Talk:ESciDoc_Access_Rights#Collaboration_on_item_level). What happens if the collaborators/co-authors haven't manage to contribute their modifications before the workflow has been finished? --Inga 20:24, 1 April 2009 (UTC)

was canceled already :) --Juliane 14:49, 3 April 2009 (UTC)

General

• I am not sure if it is a good idea to put information about file visibility and item collaboration on one page, as these two issues were and are often mixed up, even as they are two complete different issues (they only have the use of user groups in common).--Friederike 12:23, 3 April 2009 (UTC)

thanks for your input -> I've created a new page and transfered the Collabroation Scenario to it --Juliane 19:16, 3 April 2009 (UTC)

Coordinated Universal Time

Publication Management