Collection Types: Create participants partial of the new/edit form

[elrayle]

Descriptive summary

Add code to implement the Participants tab partial for the new/edit form views for collection types. This partial is shared by both the new and edit form views.

Rationale

See model issue for rationale.

Implementation

Files:

• app/views/hyrax/admin/collection_types/_form_participants.html.erb

Expected user interactions

Create the UI view for adding participants for a collection type.

The form fields allow the user to select a group or user and apply a participant role to that group/user. The roles for collection types includes...

• [x] Collection Manager
• [x] Collection Creator

The form will also include a listing of groups/users assigned to each participant role.

Exact text for the page is in the mockup below.

SPECIAL NOTE on Admin Sets:

For the initial implementaiton, the Admin Set underlying code will not change. But to a user, the Admin Set will appear to be a collection type.

To make the illusion happen...

• [x] as part of the hyrax generation process, a collection type will be created for Administrative Sets and the id will be recorded in a variable that can be checked by this UI (see issue #1342 for Admin Set Generator)
• [x] the initial values for these settings are set by the generator to be the set of admins
• [x] just like other types, these values can be changed at any time

Mockup

Related work

Collection Types feature	Issue
Admin Set Generator	#1342
User Collection Generator	#1485
Routes	#1347
Controller	#1341
Model	#1343
View - Index	#1349
View - New/Edit	#1348
Partial - Description	#1344
Partial - Settings	#1346
Partial - Participants	this issue

[elrayle]

@laritakr is pondering an alternative to this. Here is my proposed implementation.

Make use of existing permission_templates infrastructure with some modifications...

• Modify permission_templates table to...
  • add column source_type with values (admin_set, collection_type, collection)
  • rename column admin_set_id to source_id and it will hold the object id of the admin set, collection type, or collection
• permission_templates_access table is unchanged

Impact on admin_sets

• Code that queries the permission_templates table may need to update queries to check source_type=='admin_set'. If they only access by id, then this won't be an issue.

Impact on collection_type

• When creating a modal, you query permission_templates for type=collection_type to create the list of valid collection types for the current user.
• When the collection is created, you query permission_templates joined with permission_templates_access for source_type=collection_type && access=manager in order to add write acl for the new collection. I think this would actually be accomplished by setting edit_access=[manager ids + creator's id] on the object and hyrax will create the acl for you in fedora.

Impact on collections

• The code for processing permission templates for collections will be almost identical to that of admin_sets. More on that in the collections issue #1378.

[laritakr]

I am not comfortable with reusing permission templates and permission template accesses for collection types, for several reasons:

• The purpose of these objects is to store visibility in the database for fedora objects, as an extension of Fedora, and to define permission for the new Fedora objects that are added. Putting collection types into permission templates is a misuse of the concepts.
• The visibility settings do not apply to collection types
• The participants as currently used are defined to map to the fedora access list, and require program logic to translate to the workflow what the roles actually mean.
• Collection types are at a higher conceptual level than admin sets and other collections. Adding Permission Templates at the CollectionType level would further muddy the concepts.

As Collection Types are entirely outside of Fedora, we should not be reusing a construct which was created to serve as an extension of the Fedora object, particularly when the implementation of Admin Sets and Permission Templates are already troublesome.

Instead, @jeremyf and I promote the use of workflows and workflow roles for controlling who can act on collection types. I have done a lot of analysis on permissioning in Hyrax (and the entire stack), and everything I've found points to the need to integrate all permissions into the workflow structure. (Tomorrows tech call will be an initial introduction of this to the community, but the working document is located here for review and comment.) This is what workflows are designed to do... using them will be a much better fit and require less future rework as well.

However, recognizing that we are not yet at a point where this is a simple implementation, we propose that, for now, we create a new database table for collection type participants. This will allow for a cleaner refactor into workflows at a later point than having collection types mixed into the mess that is permission templates and admin sets.

Permission templates would still be modified for use with collections themselves, by modifying the permission_templates table to store the fedora id for all collections:

• rename admin set id to a more generic fedora id (source_id?)
• add collection type (or source_type) with values admin_set or collection, if needed for querying purposes, to avoid the need to access Fedora to get it.

[elrayle]

I am OK with your proposal to use a separate tables for collection_types and the same tables admin_sets and collections. I would note that the permission_templates and permission_templates_access do not extend any fedora objects. The values in those tables are used when creating a work to determine the initial settings for edit_access and read_access. Once the work is saved, the work no longer has any connection with permission_template or permission_template_access.

[laritakr]

The Admin Set is a fedora object. The permission template is one-to-one with it, to give the details needed for permissions on its child objects. From that perspective, I consider it a conceptual extension of the fedora object itself, because any object which is used to control the creation of lower level objects needs the attributes that tell it how to create those objects.

[elrayle]

Ah, I see where you are coming from. That makes sense.

[kdid]

Work completed so far-

• Adds collection_type_participants db migration and associated model, controller and form
• Adds ability to add collection type participant through the UI

Work/issues remaining-

• [ ] Needs tests
• [ ] Form validations
• [x] Error success, messages
• [x] View still needs to show the list of current participants
• [x] View still needs functionality to remove collection_type_participants (remove button on list of current participants)
• [x] Javascript/Autosuggest users functionality not done
• [ ] #1650 Adjustments to the app/views/admin/collection_types/_form.html.erb view/partial will be needed. I just moved <%= render 'form_participants' %> to below the other form tag as it wont work nested in the other form. (needs to be similar to how the admin sets participants tab works)
• [ ] Causing issues with two existing tests in _form.html.erb_spec.rb
  • the 3 tabs check is checking for panel content so failing since form isn't persisted.
  • I think the necessary collection_type_participant fixture isn't present

[kdid]

@elrayle - I did a bit more work on this. Partial pull request here: https://github.com/samvera/hyrax/pull/1534

Branch here: https://github.com/samvera/hyrax/tree/collections-1345-collection-type-participant

Complete

• Migration for database table collection_type_participants that stores participant access info
• Adds Admin::CollectionTypeParticipantsController, CollectionTypeParticipantForm, CollectionTypeParticipant model associated tests
• Adds/views/hyrax/admin/collection_types/_form_participants.html.erb and /views/hyrax/admin/collection_types/_form_participants_table.html.erb

Remaining Issues:

• 1650 The /views/hyrax/admin/collection_types/_form.html.erb view needs to be rearranged. The _form_participants.html.erb partial cannot nest within the other form but that form is spanning the other two tabs. I moved the participants partial under the submit button as a temporary measure during development, but it needs permanent solution. Maybe if the form.persisted? is true the first tab could become the "Metadata and Discovery" and contain the other two partials? That way the form could live within the first tab pane and not span them all.

[kdid]

New PR https://github.com/samvera/hyrax/pull/1546

[kdid]

@elrayle - should I go ahead and close this? I think the bulk of the work is done, at least as a first pass. The /views/hyrax/admin/collection_types/_form.html.erb issue could be a good one for Adam to look at if it's not already being addresses.

[elrayle]

Remaining Work:

• 1581 change to add manage instead of manager to access table

• 1581 change to add create instead of creator to access table

• 1582 write service to get list of collection types a user is allowed to create

  • all types when current user has manage access for collection types by being a user with manage access
  • all types when current user has manage access for collection types by being in a group with manage access
  • collection types where current user is has create access
  • collection types where current user is in a group that has create access