Feature: Read-only documents

[madsrasmussen]

Description

This feature adds the ability to set a workspace in a read-only state. Each part of the workspace can then behave based on the state.

The PR introduces a couple of parts to enable this feature:

Part 1: State Managers

The "core" of the feature is the new "State Manager" system. A state manager holds an array of state entries. If the array has any entries that state is considered "on".

We introduce a "ReadOnly" state manager that can be used in a workspace context. There is one for "standard" workspaces and one for workspaces with variant data.

Implementation https://github.com/umbraco/Umbraco.CMS.Backoffice/blob/v14/feature/readonly-properties/src/packages/core/utils/state-manager/state.manager.ts

Part 2: Language Permissions

We want to set a property to read-only if the current user does not have access to edit that language/culture.

The language access permission settings on a user group should be considered a feature owned by the Language package/module even though that part of the permission UI is not extendable yet.

It should therefore be possible for the Language package to determine what to do when a user doesn't have access to a language. This is solved by adding a "Workspace Context" extension that sets the read-only state based on the current user language permissions.

This will allow other packages to follow the same principle if they want to set the workspace read-only state. Ex: The Workflow Package wants to make a document read-only if it is part of a workflow.

Implementation: https://github.com/umbraco/Umbraco.CMS.Backoffice/blob/v14/feature/readonly-properties/src/packages/language/permissions/language-access.workspace-context.ts

Part 3: Readonly badge on languages

An additional UX improvement in this PR is to show what languages are read-only in the document language picker:

Screenshot:

Part 4: Properties reacting to the read-only state manager

The Property Dataset Context The Property Dataset checks if the active culture is read-only. and sets the state as observable.

The Property Context The property context checks if a specific property is read-only depending on whether it's varying or invariant (invariant properties can always be edited).

Part 5: Readonly Property Editor UI's

We want as many property editor UIs to implement a read-only mode to achieve the best UX for read-only properties. We can't expect all UI's to support this mode so we have a fallback overlay.

It is possible to set the supportsReadOnly field as part of the Property Editor UI Manifest if the UI has a read-only mode. If this is not set we will add a fallback overlay that prevents interaction.

Part 6: Writable Property Condition

This PR adds a condition to check if a property is writable (not read-only). It is currently used to filter our property actions that should not be shown for read-only documents.

Implementation: https://github.com/umbraco/Umbraco.CMS.Backoffice/blob/v14/feature/readonly-properties/src/packages/core/property/conditions/writable-property.condition.ts

Current core Property Editor UI's that support read-only

• label
• text
• textarea
• number
• tags

What to test:

• Limit a user to only have access to certain languages
• Check that language is marked as read only
• Check that you can interact with the read-only supported property editor but not update the value
• Check that you can't interact with the property editors that not support read-only mode

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] Chore (minor updates related to the tooling or maintenance of the repository, does not impact compiled assets)