Introduce asset permission model

[sminnee]

Acceptance criteria

• "Viewers" and "Editors" are properties on Folder and Files, with the default to inherit from parent, just like Pages
• These fields appear on the folder/file detail froms
• Default canView() and canEdit() implementations make use of these
• 100,000 files, 1,000 per folder, are supported
• For debate: should we use new SiteConfig fields for root permission or separate fields for pages and files?
• Files with canView() = false for the current user aren't displayed in asset admin
• Files with canEdit() = false for the current user show a readonly from in asset admin

Assumption: existing level of optimisation in SiteTree::batch_permission_check() is sufficient.

Tasks

• Implement abstract hierarchal permission calculator based on current SiteTree permissions
• Update SiteTree to use new permission model
• Update File to use this permission module
• Update SiteTree unit tests
• Permission model unit tests
• Asset admin behat tests for permissions / readonly
• Verify NFR (100,000 files, 1,000 folders)
• Ensure readonly mode is visible in the asset-admin
• Ensure view / editor groups are editable within the asset edit form for files and folders
• Ensure that multi-select of groups can be done in react (upgrade or create new react component).

Pull Requests

• API Implement InheritedPermission calculator #6877
• API Implement inherited file permissions silverstripe-assets#13
• API Refactor inherited permissions silverstripe-cms#1811
• API Implement file permission model silverstripe-asset-admin#465
• API Make text fields real inputs silverstripe-admin#54
• API Refactor inheritable permissions silverstripe-siteconfig#57

---

Right now asset-admin is built to respect canView() and canEdit() permissions of files, however there is no default permission model provided.

We should have some permission model built in that allows protected files and folders, similar in concept to the default page permissions.

We may wish to make this functionality provided-by-default but able-to-be-removed, so that developers can replace the default scheme in its entirety with something else.

[tractorcow]

👍

Something like an extremely bare-bones secureassets would be nice.

[chillu]

We're doing group selection via a simple CheckboxSetField for now, since that already exists as a React component. To be replaced with a react-select based MultiSelectField React component in silverstripe/silverstripe-admin#52

[tractorcow]

All tasks done, pull request coming later.

[tractorcow]

I'll rebase once i18n rewrite and behat fixes are merged and green.