MM 6.1 Collection sharing

Collection sharing types

There exist 3 types of collection shares.

[Owner] Sharing collections you have created with [Link, Email, Users, Groups]

By creating a collection share, you will become its owner, hence there can only ever be one owner per collection share. The owner holds a special status in the share, as its rights determine what download options and metadata fields the recipients will be able to have/see. Recipients with “Can administer collection” will have all the same rights as the owner, but will not be able to give more rights to the collection than the owner has. For example, if the owner has no download rights and chooses to share the collection with no download rights, then an “administrator“ cannot upgrade the collection share’s download rights.

When sharing a collection, all sub collections beneath it will automatically be shared with the same rights. It’s not possible to avoid sharing all sub collections together with the collection they belong to.

Recipients with “Can administer collection“ will be able to share the collection, and any sub collections, onward as a new share of the same collection. They cannot add more users/groups to the original share.

Recipients with “Can administer collection“ will only be able to create new collections with the assets shared with them, if they already had access to the assets before the assets were shared with them. In other words, recipients of collections do not get more rights to share assets by receiving a collection share.

Compounding [Access type]s with multiple shares to the same user

As a rule of thumb, you can only share a collection with a user/group once. However:

• Users can be in groups, and as all groups can have the collection once, the user can receive multiple collection shares with differing access types this way.

• Additionally, if a user has gotten both one user share + one or more group shares, they can also then get another collection share via link/email sharing (these two function in the exact same way - one just sends out an email and the other does not).

• In both of the above instances, where a recipient has gotten multiple collection shares: when the recipient accesses the collection, the highest [Access type] will be granted to the recipient.

  • An example: A user named “Derek Bojama“ gets the collection named “Spring collection“ shared with his user directly with the [Access type]=View + from the Group “Sales group“ he gets [Access type]=Admin, and then gets shared a link ([link] or [Email] - they both give the same [Access type]=View). When he accesses the link he will get [Access type]=Admin to “Spring collection“, as this is the highest level among his shares.

Multi-downloading (live-exporting) metadata fields in collections with parents and children

Let’s say that we have three collections: Root collection, Sub collection, and Sub sub collection - where, Sub collection is in Root collection, and Sub sub collection is in Sub collection.

• On Root-collection, the metafields A and B have been shared with me.

  • Hence in collections Root collection, Sub collection, and Sub sub collection I now have access to see + live-export metafields A and B

• On Sub collection, the metafields B and C have been shared with me.

  • Hence in collections Sub collection and Sub sub collection I now have access to see + live-export metafields A + B + C

• On Sub sub collection, the metafields C and D have been shared with me.

  • Hence in Sub sub collection I now have access to see + live-export metafields A + B + C + D

Recap

• Root collection grants me access to see + live-export A + B

• Sub collection grants me access to see + live-export A + B + C

• Sub sub collection grants me access to see + live-export A + B + C + D

Multi-downloading/live-exporting metadata fields

Now, when I multi-download/live-export Root collection, it'll download all assets in Root collection, Sub collection, and Sub sub collection with the metafields A + B.

Multi-downloading Sub collection will download all assets in Sub collection and Sub sub collection with the metafields A + B + C.

Multi-downloading Sub sub collection will download all assets in Sub sub collection with the metafields A + B + C + D.

Multi-downloading (live-exporting) metadata fields in collections with parents and children

Let’s say that we have the same three collections again: Root collection, Sub collection, and Sub sub collection - where they’re still the following: Sub collection is in Root collection, and Sub sub collection is in Sub collection.

• On Root collection, there is one video asset

• On Sub collection, there is one PDF asset

• On Sub sub collection, there is one image asset

Multi-downloading/live-exporting asset types

Root collection

When multi-downloading Root collection, I will be presented with the option to choose one or more qualities for “Videos” that my user has access to. I do not have the option to select qualities for either PDFs or Images. I select “quality=mp4_480”, and download:

• 1 video, quality=mp4_480

• 1 PDF, quality=original

• 1 Image, quality=original

Sub collection

When multi-downloading Sub collection, I will be presented with the option to choose one or more qualities for “PDF” that my user has access to (usually only original for PDF). I do not have the option to select qualities for Images. I select “quality=original” and download:

• 1 PDF, quality=original

• 1 Image, quality=original

Sub sub collection

When multi-downloading Sub sub collection, I will be presented with the option to choose one or more qualities for “Images” that my user has access to. I select “quality=jpeg small” and “quality=jpeg big” and download:

• 1 Image, quality=jpeg small

• 1 Image, quality=jpeg big

Sharing types

There exist 4 types of sharing - which all have their own sharing options:

[Link] Sharing as a link

• Expiration date

• Specify metadata fields

• Download rights

[Email] Sharing with one or more email addresses

• Expiration date

• Specify metadata fields

• Download rights

• Receivers

• Message

[Users] Sharing with one or more users

• Expiration date

• Specify metadata fields

• Access type

• Download rights

• Add users

• Message

[Groups] Sharing with one or more groups

• Expiration date

• Specify metadata fields

• Access type

• Download rights

• Add groups

• Message

The sharing options explained

Access period [Link, Email, Users, Groups]

You have the option to define the timespan (in days) for which this collection should be active:

• Start date

  • On the date defined here, it will be valid as of 00:00:01 on that day. E.g., if the 5th of October is selected, it will be active as of 00:00:01 on the 5th of October. (From+include)

• End date

  • On the date defined here, it will be valid until 23:59:59 on that day. E.g., if the 5th of October is selected, it will be active until 23:59:59 on the 5th of October. (To+include)

Both the start and the end date may be the same date. This would result in a one-day/24-hour share.

The timezone will always be the server’s.

Example: Say that your server is on UTC +0 and that you are on UTC +2. You then create a collection share and send it off to a person whose location is in UTC +8. Then, on the date you selected:

This also means that, if you were to share with a person who’s in a timezone like UTC -10 from a server that is in UTC +0, then from the recipient’s point of view, the collection is available at 4 PM in the afternoon, the day before the start date (and, conversely, it will also expire at 4 PM the day before the end date).

Specify metadata fields [Link, Email, Users, Groups]

• By default, some metadata fields will be added:

  • Defined by a higher level user (e.g., admin) in General → General settings → Collections → METADATA SHOWN FOR SHARES.

  • It will not appear in the list if you do not have at least read rights to a default metadata field. Therefore, it will not appear for recipients.

  • You can remove all the default metadata fields (“Title” included) without it causing any issues.

• You can add all metadata fields that your user has, at least, read rights to:

  • If you have shared a metadata field and then lose read rights to the metadata field, the share will retain the metadata field; however, the recipient(s) will no longer be able to see the metadata field.

    • While you, as the sharer, have no read rights to the metadata field, you cannot remove the metadata field from the share. But again, the recipient(s) likewise will not see the metadata field, so this is not seen as an issue.

  • Re-adding read rights to the metadata field for the sharer - will make the recipient(s) regain access to the metadata field.

• The recipient(s) will be granted read rights to the metadata fields you choose (i.e., not write rights)

  • Please note that, for each user, we hide empty metadata fields that they only have read rights to. So, if a recipient has an issue with seeing a metadata field, it’s probably caused by it being empty. (Side note: booleans cannot be empty)

    • Freetext searching at the top of the asset editor for a hidden metadata field will reveal the metagroup it’s a part of. This can be used to quickly see if the metadata field was shared but is just hidden due to no content. (If they have no rights to it, the free-text search will not return the metagroup, hence why this is a valid test).

Download rights [Link, Email, Users, Groups]

You have the following sharing options:

None

• Recipients will not get any collection download options.

Can download metadata

Recipients can download metadata for all assets in the collection - from the share panel only.

Only shown to the sender if they have the roles:

Or

Can download assets

Recipients will get the option to download all assets in the collection - from the share panel only.

Only shown to the sender if it has the following roles:

Or

Can download assets and metadata

Recipients will get the option to download all assets and metadata for all assets in the collection - from the share panel only.

Only shown to the sender if it has the following roles:

Or

Access type [Users, Groups]

Depending on which [Access type] you select, the recipient will be able to do the following - for both the collection and any of its sub collections:

Message [Email, Users, Groups]

• The message is a required field for sharing with email, users, and groups. The recipients will see the text in their email inbox and under the notification bell when they log in.

• Collections shared with groups, and then subsequently adding more people to the group, will result in the recipients not seeing the collection sharing message.

• The message is saved in the collection share and can be edited in the same place you edit other elements for the share. Upon resharing, the message will be sent out again, but this time only to email inboxes.

Add users [Users]

• This list will be populated with all users in the system who have an email attached. The email does not have to be valid.

• If you add multiple users while sharing, these users will all receive their own, albeit identical, shares - that all can be individually updated, reshared, and deleted.

• It will show an error if you try sharing with yourself or other users who have already received a collection user share (Meaning that, if they have received the collection as a group first, and then have a user share, they will be getting a new share).

  • If you share with multiple users, and your user or an existing user is included, it will show the error. It will, however, share with all other valid users.

  • (If you wish to update an existing user share, you must do this from the ‘Overview of shares’ menu option.)

Add groups [Groups]

• This option will only be visible to you if you have the role:

• Like the users, all groups you add will receive their own individual share.

• Users in groups in groups (and users in groups in groups in groups ad infinitum) will all receive the same rights to the collection and its sub collections.

• You can group share to a group (or group in group) that the owner is already a part of.

• New users added to the group after the share has been made, will instantly get access to the collection, though they will not get the initial sharing email and notification, so the [Message] will not be visible to them.

• Same as for [Users] you cannot share a collection with the same group twice. Again, if you add multiple groups when sharing, and e.g. one already has received the collection share, the UI will show an error, but all valid groups will have it shared with them.

Updating shares

You can update all shares. The elements you can edit on existing shares, are exactly the same as when you created the share the first time.

Upon pressing ‘Update’, the recipients will instantly have their rights changed. No notifications or emails will be sent.

Resend invite

Resending the invite will only send a new email, not a notification.

The email will look exactly the same as the initial invite/share - with the same message.

To change the message of the ‘Resend invite’ function, you must first edit the message from the ‘Edit share’.

Disabling sharing externally [Link, Email]

Higher level users (e.g., admins) have the option to disable external sharing in General → General settings → Collections. In here you have the toggle ‘Enable external collection sharing’ which, if disabled, will remove the [link] and [email] sharing tabs from all users.

All unique [Access type] sharing combinations

Sharing a collection in miscellaneous ways will likewise result in different [Access type]s. The following tables aim to provide a clear understanding of what to expect in any given share combination.

Please be aware that, regardless of whether you share with e.g., View rights first, and Admin rights later - or - Admin rights first, and then View rights later - the result will be the same; the highest access will be applied.

Sharing a collection with the same user multiple times

We have the following unique scenarios:

1. User View + User View = View

2. User View + User Edit = Edit

3. User View + User Admin = Admin

4. User Edit + User Edit = Edit

5. User Edit + User Admin = Admin

6. User Admin + User Admin = Admin

As [User] and [Group] are fundamentally the same, and [Link] and [Email] are fundamentally the same - thus, we only have to make one comparison. As [Link] and [Email] always will only share as View, we have the following unique scenarios:

1. Link View + User View = View

2. Link View + User Edit = Edit

3. Link View + User Admin = Admin

As [Group] uses the exact same logic as [User], only one is needed to validate this. Hence, only sharing [Group] as View is sufficient

1. Group View = View

As [Email] uses the exact same logic as [Link], only one is needed to validate this. Hence, only sharing [Email] as View is sufficient

1. Email = View

Sharing a collection with the same user multiple times - both as child and as parent

The above scenarios were all for one collection shared in multiple ways. You also have the option to share collections as a part of other collections.

Please note that Edit is not added here, as it will function the same as View + Admin.

For example, we have two collections: Root collection and Sub collection, where Sub collection is a child of Root collection.

When sharing Root collection as View (Share A), and then sharing Sub collection as Admin (Share B), you will have View rights on Root collection, and Admin rights on Sub collection, regardless of how you access these collections. So, as mentioned earlier, when you have a collection (Sub collection) shared with you, both as the root (Share B) + as the child (Share A), you will have two ways of entering it from the Collections menu. One where you can access it directly (go directly to Sub collection, Share B), and one where you have to go through its parent folder (first Root collection and then Sub collection, Share A).

Regardless of which way you access Sub collection, you will have Admin rights.

The unique scenarios:

1. User parent View + User child View =

   1. View on the parent

   2. View on the child

2. User parent Admin + User child View =

   1. Admin on the parent

   2. Admin on the child

3. User parent View + User child Admin =

   1. View on the parent

   2. Admin on the child

Fields in use as of 5.6.2

The following roles will come into effect as of 5.6.2. They exist in 5.6.1, but are not enforced: