hydroshare / IrodsShare

HydroShare access control model for use in Irods and other Irods-based projects.
1 stars 0 forks source link

published -> discoverable, immutable #14

Open alvacouch opened 9 years ago

alvacouch commented 9 years ago

If something is published, it should behave as if the immutable (and discoverable) flags have also been set. Making something published should not be possible to undo except as an administrator. Undo should reproduce the exact flag state before it was published.

alvacouch commented 9 years ago

published -> immutable now. Not sure that it should imply discoverable. Question is whether public and published should be orthogonal?

dtarb commented 9 years ago

Lets avoid embedding limiting policies in the functionality of this library. Therefore I suggest that published be orthogonal to discoverable and public in terms of functionality. We have

By leaving the setting of public and discoverable flags to the interface all the above seems possible. It might be possible to simplify and encourage a resource being made public once published by having the API call default to setting the public flag, requiring a specific argument to retain current settings of public and discoverable.

alvacouch commented 9 years ago

Currently public implies discoverable and published implies immutable. should I undo that?

dtarb commented 9 years ago

No. This is correct.

horsburgh commented 9 years ago

I think published should imply discoverable - and that should be part of the agreement when a user chooses to publish a resource. I can understand (but don't really advocate for) the use case of limiting access to published content (e.g., the journal subscription use case). But, I don't understand limiting access to discovering that a "published" resource exists. Why would we want to limit access to metadata? If we don't want to actively pursue this, then why don't we just implement it the way we want it to work?