Assign users and roles to a new collection

[jmcglone]

Via a GUI, setup a new collection and assign it a collection admin and depositor. Enable a super user to assign multiple collection admins to the collection. Enable a super user to assign multiple collection depositors to the collection. Enable a collection admin to assign other collection admins to the collection. Enable a collection admin to assign collection depositors to the collection.

[gordonleacock]

Carried over from #38: This is now pending some investigation by roger, nabeela, and myself. One key issue is do we store collection_managers and collection_depositors as 1) part of the collection meta data or 2) in a db using active record. A second key issue is how do we enable the proper permissions using that data in the various collection use cases (create a new collection, edit a collection, delete a collection, etc) presumably in the appropriate controllers.

I had been going down path 1) when we decided this need more investigation. Jose send a message to hydra-tech asking about people previous experiences with this issue which you can see here together with a response from Justin (https://groups.google.com/forum/#!topic/hydra-tech/-1IIzDP8U7U).

[njaffer]

@gordonleacock thanks for sharing the info! Here is another link that talks about Admin sets: https://wiki.duraspace.org/display/hydra/Collections,+Admin+Sets,+Display+Sets

I would suggest that we all study the idea of Admin Sets and Display Sets and meet on Monday to brainstorm!

[respinos]

I'd recommend everyone spend some time setting up collections and access in the Deep Blue Dev environment, too.

-R

On Fri, Nov 6, 2015 at 9:21 AM, Nabeela Jaffer notifications@github.com wrote:

@gordonleacock https://github.com/gordonleacock thanks for sharing the info! Here is another link that talks about Admin sets: https://wiki.duraspace.org/display/hydra/Collections,+Admin+Sets,+Display+Sets

I would suggest that we all study the idea of Admin Sets and Display Sets and meet on Monday to brainstorm!

— Reply to this email directly or view it on GitHub https://github.com/mlibrary/hydra-prototype/issues/68#issuecomment-154420517 .

[njaffer]

Any one has any insight into Avalon? It seems like Collection Admin concept is used there as well. Found this link useful: https://wiki.duraspace.org/display/hydra/Collections+and+Admin+Sets

[njaffer]

@respinos , good idea! Should we setup the access using the rake test that you have on the read me page? and setup Collection through UI? or Console?

[njaffer]

Another resource: https://github.com/projecthydra-labs/hydra-works/issues/17

[respinos]

Sorry, @njaffer: I meant the other Deep Blue Dev ;-)

http://dev.deepblue.lib.umich.edu:8080

The Hydra community is very rooted in a particular approach to access control, and it'd be good for all of us to be on the same page as to where we're heading!

On Fri, Nov 6, 2015 at 10:33 AM, Nabeela Jaffer notifications@github.com wrote:

@respinos https://github.com/respinos , good idea! Should we setup the access using the rake test that you have on the read me page? and setup Collection through UI? or Console?

— Reply to this email directly or view it on GitHub https://github.com/mlibrary/hydra-prototype/issues/68#issuecomment-154439347 .

[respinos]

Updated the prototyping plan on the wiki; attached below. Please send questions/comments!

• define Deposit mode for WebACL (extends http://www.w3.org/ns/auth/acl#Access)
• define Manage mode for WebACL
• define DefaultReadAccess mode for WebACL
• extend Collection
  • deposit_users
  • deposit_groups
  • manage_users
  • manage_groups
  • default_read_access - if this is empty, MHydra will assume "public" (Hydra's version of DSpace's Anonymous)
  • the anonymous user has the groups public --- so xx_groups need to be set to [ public ]
• update ability.rb
  • use Hydra::Ability as guide for parameterized cancancan tests
  • e.g. can :deposit, Collection, Work do |collection, obj|
  • ability logic would
  • load the Collection from Fedora (for now)
  • test whether current_user is in deposit_users or current_user.groups is in deposit_groups
• set the default permissions on work and files as they're created in the collection
  • read and discover should be simple, most of the time
  • edit should be the current_user and the managers of the collection

[gordonleacock]

See also: https://wiki.duraspace.org/display/hydra/Administrative+Sets

[respinos]

Expanding on the setting of default Item permissions...

item.apply_depository_metadata(user) sets the owner and grants Write access to user. What's not obvious is that user also gets read/discover permissions --- is Hydra using heuristics (if you can write/modify an item, you need to be able to read/discover it)?

Is it going too far for MHydra to implement "no explicit users/groups == anonymous/public"?

For indexing purposes, the collection managers will need to be added to read_users at least. Maybe just edit_users.

[respinos]

From hydra-access-controls ability.rb:

# edit implies read, so read_users is the union of edit and read users
def read_users(id)
  doc = permissions_doc(id)
  return [] if doc.nil?
  rp = edit_users(id) | (doc[self.class.read_user_field] || [])
  Rails.logger.debug("[CANCAN] read_users: #{rp.inspect}")
  return rp
end