Add a preview only mode to the navigation block

[fabiankaegy]

Part of #60316

The core navigation block currently does not render navigation menus for user roles that can view a menu but cannot edit it. This is problematic because when we try to show a locked preview of the a template whilst editing the current post to lower user roles they see the "This navigation Menu doesn't exist" fallback state in the preview.

To solve for this we should allow the Navigation block to exist in a read-/preview-only mode.

If a user has the capabilities to view a navigation menu but doesn't have the capabilities to edit that navigation menu they should be presented with this preview-only mode.

Proposed UX

The way I would handle this for the navigation specifically is similar to how we handled it in the Post Template block in #60326. The navigation block wrapper sets it's block editing mode to disabled or content only. So none of the child blocks ever get exposed. Also any of the block inspector controls are automatically disabled though this.

User roles that cannot edit a menu should not be able to change anything about its content. They may only move the block around or change the visual appearance of the navigation block itself.

[getdave]

Thank you for outlining this and for pushing for a good UX experience for users with lower permissions.

As you know, like Template Parts Navigation blocks reference a Post (using the ref attribute) which stores the inner blocks (the "Navigation Menu"). However, whereas Template Parts are a wrapper, the Navigation block is itself present on the page and can itself be styled.

Therefore, even if a user doesn't have permissions to edit a Navigation Menu I believe they should still be able to edit the block itself (layout, styles...etc).

What any implementation will need to do is disable the ability to reassign the Navigation Menu or modify its properties. That means in addition to locking down the inner blocks any implementation will also need to conditionalise the following:

• the "Menu inspector controls under "List View" tab have a means to do this

Menu inspector controls

• the Menu rename, delete and manage controls

Menu rename and delete

The only other area that might need checking is the automatic fallback mechanism which will attempt to avoid the block being empty by creating/fetching an appropriate Navigation Menu to use in case one is not already assigned as a ref. I'm hopeful that mechanic won't run for lower permissions users, but worth double checking.

I suspect there may be other areas but I'm not 100% - cc'ing @draganescu who will also have good insight.

In terms of code we already have some permissions going on within useNavigationMenu:

gutenberg/packages/block-library/src/navigation/use-navigation-menu.js

Line 17 in 1a11f07

const permissions = useResourcePermissions( 'navigation', ref );

In my opinion this hook is doing a lot of work and might be better as several smaller hooks but I could be wrong. That said you can likely use it to determine some permissions conditionalisation.

If that doesn't work then the raw query would need to be something like:

select( coreStore ).canUser( 'create', 'wp_navigation' )]

...and from that you can determine whether or not to display certain pieces of UI.

I hope that helps?

[draganescu]

Thanks for the ping @getdave and thanks for the issue @fabiankaegy - I don't even think it's an enhancement, sounds more like a bug to me. Maybe an initial iteration would try to disable any update (mark the block disabled) and then we can tweak details ...

Not much to add to Dave's analysis above.

[coder-rancho]

As @draganescu suggested, for the initial version we can just disable any updates. I've implemented the changes in #69794 and #69806.

cc: @t-hamano