Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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.

...

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.

...

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 video 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 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 my user has access to. I select “quality=jpeg small” and “quality=jpeg big” and download:

...

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

...

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:

...

  • 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 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) 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 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 freetext search will not return the metagroup, hence why this is a valid test).

...

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

  • It will show an error , if you try sharing with yourself or other users who have already received the a collection user share as a user (Meaning that, if they have received it the collection as part of a group first, and then have a user share, they will get 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 have to do this from the ‘Overview of shares’ menu option.)

  • You cannot share a collection

Add groups [Groups]

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

...

User share v / User share >

View

Edit

Admin

View

View

Edit

Admin

Edit

 -

Edit

Admin

Admin

 -

 -

Admin

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

Link share v / User share >

View

Edit

Admin

View

View

Edit

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

Group >

View

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

Email >Email>

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

...

User share Child v / User share Parent >

View

Admin

View

View on child

View on parent

Admin on child

View on parent

Admin

Admin on child

Admin on parent

-

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

...

Collection_can_share_mail

Allows the user to share with an external e-mail email (available from 5.6.1, but not used before 5.6.2)

Collection_can_share_zip

Allows the user to share asset(s) as a zip (available from 5.6.1, but not used before 5.6.2)

Collection_can_share_user

Allows the user to share collections with other users (available from 5.6.1, but not used before 5.6.2)

Collection_can_share_link

Allows the user to share a collection as a link (available from 5.6.1, but not used before 5.6.2)

...