Block workspace: Enforce "AllowEditInvariantFromNonDefault" in variant blocks (closes #20633)

[madsrasmussen]

Fixes https://github.com/umbraco/Umbraco-CMS/issues/20633

This PR implements the configuration for “AllowEditInvariantFromNonDefault” for variant blocks.

To achieve a clear separation between the configuration and the Document/Block implementation, I have moved the configuration enforcement into its own controller and registered it as a workspace context for the Document and Block workspaces.

Test cases of AllowEditInvariantFromNonDefault:

Setup

• 2 languages
• Document (Vary by culture)
  • Text 1 (Vary by culture)
  • Text 2 (Shared)
  • Block List 1 (Vary by culture). With a Block 1 and Block 2.
  • Block List 2 (Shared). With a Block 1 and Block 2.
• Blocks
  • Block 1 (Vary by culture)
    • Text 1 (vary by culture)
    • Text 2 (shared)
  • Block 2 (shared)
    • Text 1
    • Text 2

Case: True

From default language: All properties are always writable From non-default language: All properties are always writable

Case False

Result:

From default language: All properties are always writable From non-default language:

• Document
  • Text 1: writeable
  • Text 2: readonly
  • Block List 1: writeable
  • Block List 2: readonly. can open blocks. Can not create or delete blocks.
• Blocks
  • Block 1
    • Text 1: writeable
    • Text 2: readonly
  • Block 2
    • Text 1: readonly
    • Text 2: readonly

[nhudinh0309]

Tested and found a few issues:

Case: false

• Still able to edit invariant text properties inside a variant block in a non-default language.

Case: true

• Invariant text properties are not editable in non-default languages.
• Invariant block lists are not editable in non-default languages.
• Variant text properties inside invariant blocks are not editable in non-default languages.
• Invariant text properties inside invariant blocks are not editable in non-default languages.

@madsrasmussen: Could you take a look?

[madsrasmussen]

Hi @nhudinh0309

Thanks for testing! Based on your result, the two results are almost reversed. I have investigated to see if that was the case, but I can not replicate your findings.

I have added a video to show how it looks in my setup:

AllowEditInvariantFromNonDefault: false = Shared Properties are read-only on non-default cultures. AllowEditInvariantFromNonDefault: true = All properties can be edited.

Can you double-check that you didn't get them reversed by mistake?

https://github.com/user-attachments/assets/bd041400-f7d5-42d9-997b-4ea0cf5e6c69

[nhudinh0309]

Hi @madsrasmussen,

I retested all three cases:

• AllowEditInvariantFromNonDefault = false
• AllowEditInvariantFromNonDefault = true
• Not setting the value in appsettings.json (default = false)

Everything works as expected. My earlier issues came from misunderstanding the default value (I thought it was true)

Sorry for the confusion and for taking your time on this and thanks for checking it again!

[nielslyngsoe]

Just for someone reading along, I have now been updating this PR to handle Invariant Blocks within Variant Blocks.

[andr317c]

We are running into issues when using invariant blocks on our acceptance tests in this PR . Here is the test run. At the root of the content node, it seems to work fine with the user not being able to edit invariant fields on non default languages, but when the user then navigates inside a block list, the invariant field is then editable. See GIF :

[iOvergaard]

Hey @andr317c, I hit the same issue while testing. The bug is that rules are created with datasetVariantId: "da-DK", but invariant element types have datasetVariantId: null (set in block-workspace.context.ts:169-170), so the rule matching fails. I have a fix ready that adds rules for invariant datasetVariantId when viewing from non-default languages.