Page 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.

...

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

...

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.

...

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

...

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:

...

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:

...

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:

...

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).

...

• 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 It will not appear in the list if you do not have at least read rights to a default metadata field, it will not appear in the list. 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 - 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 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 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 free-text search will not return the metagroup, hence why this is a valid test).

...

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]

...

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: