...
- 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. WeI'll talk more about those when we look more at these in a bitat the Admin Set configuration.
- Require Membership
- Workflow
- Visibility
...
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 creations 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 adding and removing them from the group. They 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. 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. In the future, admin sets may become regular collections with a specific pattern of settings.
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.