/
Understanding Permission Templates and Visibility

Samvera Community Wiki

Understanding Permission Templates and Visibility

Nov 06, 2017

 

Table of Contents

Visibility

Visibility is stored in the solr doc as follows:

  • if visibility='open' (aka public), the solr doc read_access_group_ssim includes 'public'

  • if visibility='authenticated' (aka institutional), the solr doc read_access_group_ssim includes 'registered'

  • if visibility='restricted' (aka private), nothing is added to the solr doc

 

Permission Templates

For Admin Sets:

Original implementation

CREATE TIME: admin_sets add access to the solr doc at create time via AdminSetCreateService

  • set in solr doc from AdminSetCreateService#create

    • read group: 'public'  (for visibility)

    • edit group: admin

    • creator: creator user (not given access via edit user)

  • set in permissions table from AdminSetCreateService#create_permission_template and #access_grants_attributes

    • MANAGE group: admin

    • MANAGE user: creator user

  • set in permissions table from AdminSetCreateService#create_default_access_for

    • DEPOSIT group: registered


UPDATE TIME: admin_sets adjust the above at udpate time via PermissionTemplateForm and via AdminSet (model)

  • set in solr doc from AdminSet (model) #update_access_control! when called from PermissionTemplateForm#update_management which is only called when a manager is added or deleted

    • edit user: all users with MANAGE permissions (includes creator user)

    • edit group: all groups with MANAGE permissions

    • NOTE: creator gets edit access via this method because set with MANAGE access during create AND this method is ONLY called when MANAGE participants are added or deleted

    • NOTE: no read users/groups are added which doesn't matter only because the read group was set to Public above which means everyone can read

  • set in permissions table from PermissionTemplateForm#update -> #update_participants_options -> #update_permission_template -> AdminSet (model) #update

    • adds/removes row from access table with agent_id, agent_type (e.g. 'user' | 'group'), access (e.g. 'manage', 'deposit', 'view') values set in the form


Slight modification during sprint

CREATE TIME: admin_sets add access to the solr doc at create time via AdminSetCreateService

  • set in solr doc from AdminSetCreateService#create

    • read group: 'public'  (for visibility)

    • DO NOT SET edit group: admin

    • creator: creator user (not given access via edit user)

  • set in permissions table from AdminSetCreateService#create_permission_template and #access_grants_attributes

    • MANAGE group: admin

    • MANAGE user: creator user

    • NEW -- call AdminSet (model) #update_access_controls! to set solr doc edit permissions

  • set in permissions table from AdminSetCreateService#create_default_access_for

    • DEPOSIT group: registered


UPDATE TIME: admin_sets adjust the above at udpate time via PermissionTemplateForm and via AdminSet (model)

  • set in solr doc from AdminSet (model) #update_access_control! when called from PermissionTemplateForm#update_management which is only called when a manager is added or deleted

    • edit user: all users with MANAGE permissions (includes creator user)

    • edit group: all groups with MANAGE permissions

    • NOTE: creator gets edit access via this method because set with MANAGE access during create AND this method is ONLY called when MANAGE participants are added or deleted

    • NOTE: no read users/groups are added which doesn't matter only because the read group was set to Public above which means everyone can read

  • set in permissions table from PermissionTemplateForm#update -> #update_participants_options -> #update_permission_template -> AdminSet (model) #update

    • adds/removes row from access table with agent_id, agent_type (e.g. 'user' | 'group'), access (e.g. 'manage', 'deposit', 'view') values set in the form

 


All this is consistent with the Collections permissions approach EXCEPT

  • collections set read_groups and read_users based on VIEW access

  • admin_sets allow everyone to view all admin sets. This is incompatible with collection type approach and will need to be revisited before admin_sets can become just another collection type.

Impact of Participants on admin_set/collection and works

For Admin Sets:

permission_
template_
access

admin set solr doc

ability: can? create_in_adminset

can access through UI via Dashboard → Administrative Sets

work solr doc

comments

permission_
template_
access

admin set solr doc

ability: can? create_in_adminset

can access through UI via Dashboard → Administrative Sets

work solr doc

comments

Definition on participants tab:

Managers of this administrative set can

edit the set metadata, participants, and release and visibility settings (via Dashboard → Administrative Sets)
edit work metadata (controlled by manager having edit_access on work)
add to or remove files from a work (controlled by manager having edit_access on work)
add new works to the set

NOTE: Manager is granted access to works and their files only FOR WORKS CREATED AFTER USER BECAME MANAGER

Additional things a manager can do not specifically mentioned in the definition

move works to another set where user is manager
move works to another set where user is depositor
view the admin set through Dashboard → Administrative Sets
delete empty admin set (NOT in the definition, but you can do this with edit_access)

 

Any differences from Collections? (checked if same)

edit the collection metadata, sharing, discovery, etc.
edit work metadata (works created directly in collection)
add to or remove files from a work
add new works to the collection

 

move works to another collection where user is manager

move works to another collection where user is depositor

remove works from collection (not allowed for admin sets)
delete empty collection
delete collection with works (not allowed for admin sets)

:manage

edit_access

true

YES

edit_access

Admin user creating the admin set is not given edit_access as a user until a manager is added.  This does not have much of an impact as the user is part of the admin group and gets access through that group.

Depositors of this administrative set can

can add new works to this administrative set.

:deposit

N/A

true

NO

 

Access to works are granted only for works the user creates.

Viewers of this administrative set can

view works in the set regardless of the visibility settings applied to the work. For example, viewers can view works in this set even if the works are currently embargoed or restricted.

Additional functionality expected not directly mentioned in the definition

view the admin set through Dashboard → Administrative Sets  (NOT in the definition, but QA expected to be able to do this)

:view

N/A

false

NO

read_access

The user is NOT given read access to the admin set and therefore cannot view the admin set through the UI.

 

For Collections:

permission_
template_
access

definition in UI

collection solr doc

ability: can? create_in_collection

work solr doc

comments

permission_
template_
access

definition in UI

collection solr doc

ability: can? create_in_collection

work solr doc

comments

Managers of this collection can

add to and remove works from the collection
modify collection metadata (including metadata, branding, sharing (to set roles), discovery (aka visibility), relationships (for nesting))
delete the collection

:manage

 

edit_access

true

edit_access

admin is always a manager

:deposit

Depositors of this collection can

  • view the collection

  • add works to it, even if the visibility permissions of the collecton otherwise would not permit them to view it.

read_access

true

 

access to works are granted only for works the user creates

:view

Viewers of this collection can

  • view it even if the visibility permissions of the collection otherwise would not permit them to view it.

read_access

false

read_access

 

 

NOTE: There is a  difference in definitions and in read_access set on admin_sets and collections for depositors and viewers.  I would propose that Admin Sets use the same behavior as collections.  This change will results in Depositors and Viewers being able to view the admin show page of the admin set AND see them listed in Managed Collections tab in Dashboard → Collections. 

This makes sense for viewers since they must have some special connection with the admin set to be able to see works in it even when they are embargoed or private.  This can make sense for depositors when there are multiple admin sets being used for organization.

My concern is for the special case of a site using a default admin set because they have to.  Users must be able to deposit in it.  In this case, the default admin set is the full set of all works in the repository.  It does not make sense for users to view the show page for that admin set or see it in Managed Collections.