Welcome. This is an introduction to extensions being made to expand the functionality and configurability of collections in Hyrax. There were two working groups that identified requirements and designed layout mockups. An implementation sprint is currently underway and nearing completion. This video will give you a look at the collections extensions functionality that is coming soon.
I'm logged in as an admin user at this point so that I can see the full set of admin menu options. Down in settings you will see Collection Types. I'm going to click this to see a list of collection types.
A major challenge that was identified by the working group is that not all applications think of collections the same way. Just adding new functionality that would be available to all collections would not work. This led us to the concept of a collection type that allows you to configure how collections behave. Additionally, within one application, there can be multiple types of collections.
The system architect for an application can decide how many collection types are needed and the characteristics a collection type should have. Since this is a new concept, there are examples given in the descriptive text of the screen. You can see that it lists User Collections that any user can create to organize their work, Exhibits which can only be created by curation staff for the purpose of public consumption, Controlled Collections which correspond to organizational units like university level, school level, department level, and Community Collections which can be used to create DSpace type communities and collections. The types listed here provide examples of what you might want to do. The actual names and characteristics of the collection types for a given site are designed by you to meet the needs of your application.
So let's take a look. There are two collection types that are pre-defined for you. User Collections are defined to bring in the functionality of the pre-extensions collection behaviors. When you migrate to Hyrax with Collection Extensions, all existing collections are assigned the type User Collection. You won't have to take any action for this to happen. It is the default behavior of collection extensions to make this assignment. To see how the User Collections type is configured, we will click Edit.
You have the ability to rename the User Collection type. And you can update the description. The end user will see a list of collection types in a modal when creating a new collection if they have permissions to create collections of more than one type. If they can only create one type of collection they will go straight to the new collection form.
On the settings tab, you will begin to get a feel for the enhancements that were made to collections. There are a number of checkboxes that define the behaviors of a collection type.
Let's take a quick look at each of the settings.
- Nestable - This allows collections of the same type to be nested within each other.
- Discovery - Can a user set this collection to Public allowing it to show up in search results?
- Sharing - Can users identify other users who can help maintain and manage collections?
- Multiple Membership - Can a work be in more than one collection of this type.
You'll note that these basic settings are all on for User Collections. This matches the existing functionality of collections in Hyrax, except that it adds the ability to nest which is new with the collection extensions. These settings are not editable to maintain backward compatibility.
The last 3 are not allowed for general collections at this time. They are specific to Admin Sets. More design work is required to determine if and how these 3 settings would work for collections other than admin sets. I'll talk more about those when we look at the Admin Set configuration.
- Require Membership
- Workflow
- Visibility
The final configuration you can make is in the Participants tab. Here you can identify individuals or groups that can manage collections of this type. And which users can create collections of this type.
Managers of a collection type are given edit access to all collections of that type at the point when the collection is created. For User Collections, you will likely set the manager to be the admin group. If you have a type Library Exhibits, you might want to have one or two library staff users who can manage these collections. This can reduce the burden on the IT staff to handle basic management of collections.
Creators will have edit access to collections they create, but otherwise have no special permissions to other collections of this type. Again you can set up creators to match the needs of a particular collection type. For User Collections, all registered users can create these. But for the Library Exhibits example, there may be a group of librarians who can create these.
And you can see here that for the predefined User Collections type, managers are set to admins only and creators are set to all registered users.
It is important to note that access related to participants is granted at the time the collection is created. If you later remove an individual and add another one, this will impact future collections when they are created, but will not change permissions on existing collections. It is recommended that you grant participant permissions to a group instead of an individual. For example, you can create a group 'library exhibit managers'. Then if a person changes jobs or responsibilities, it is a matter of removing the user from the group and adding their replacement to the group. The new user will get appropriate edit access to the collections as a collection type manager through their group affiliation.
Now let's take a quick look at Admin Set types. This type, like User Collections, is predefined.
On the descriptions tab, you can change the description. You cannot change the Type Name. During this initial implementation, Admin Sets are not implemented as collections. They are exposed through the UI as though they are collections to create a consistent UI for users. The reason they are not implemented as collections is that they have additional functionality that was not brought into collections with this first implementation sprint for collection extensions. We have set the stage for admin sets to become regular collections in the future.
So what might those settings look like? By the current definition of admin sets, they are...
- NOT nestable
- NOT discoverable
- CAN be shared
- can NOT have multiple membership
- DO require membership
- CAN define workflow
- CAN define visibility
It is the last 3 settings that are currently unique to admin sets. Those settings are disabled for regular collections types. This is were additional design would be needed to resolve how workflows and visibility settings would interact if they are defined on collections of various types and a work can belong to multiple of those collections.