Content Comparison

As of MM5.6.1, the way that collection-sharing has changed. This document aims to explain how the system actually works, not how it should work.

...

There exist 3 types of collection shares.

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

...

When sharing a collection, all sub-collections beneath it will automatically be shared with the same amount of rights. It’s not possible to not share 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 an existing 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.

...

As a rule of thumb, you can only share a collection with a user - or /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. Literally no difference).

• In both of the above instances, where a recipient has gotten multiple collection shares: When 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] , doesn’t matter - they both give the same [Access type]=View), then accessing . When he accesses the link he will get [Access type]=Admin to “Spring collection“, as this is the highest of all 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, obviously, Sub - collection is in Root - collection, and Sub - sub - collection is in Sub - collection.

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

  • Hence with 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, I have been shared the metafields B and C have been shared with me.

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

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

  • Hence with 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

...

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, I have there is one video asset

• On Sub - collection, I have there is one PDF asset

• On Sub - sub - collection, I have there is one image asset

Multi-downloading/live-exporting asset types

Root

...

collection

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

• 1 video, quality=mp4_480

• 1 PDF, quality=original

• 1 Image, quality=original

Sub

...

collection

MultiWhen multi-downloading Sub - collection, I will be presented with the option to choose one or more qualities for PDF 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

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

...

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 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 (including)

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

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

...

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 who’s sitting 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 O’clock in the afternoon the day before the start date (and, conversely, it will also expire at 4 O’clock 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.

  • If you do not have , at least , read rights to a default metadata field, it will not appear in the list. Therefore It , 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 - then the share will actually 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 recipient(s) again 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 in the top of the asset editor , for a hitten hidden metadata field , it’ll will reveal the metagroup it’s a part of. This can be used as a way 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 freetext search will not return the metagroup, hence why this is a valid test).

...

Only shown to the sender if it has they have the roles:

...

OROr

...

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:

...

• 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 have result in the recipients not see seeing the collection sharing message.

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

...

• 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 individually be updated, reshared, and deleted.

• It will show an error, if you try sharing with yourself - or - other users that who have already have received the collection share as a user (if they have received it as part of a group, they will get 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 other users.

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

• You cannot share a collection

...

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] fundamentally are the same, and [Link] and [Email] are fundamentally the same - 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 a child and as a parent

...

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

So, let’s for example say that we have two collections: Root-collection and Sub-collection, where Sub-collection is a child of Root-collection.

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 said 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

...