Show a UI warning when user does not have permission to update/edit an existing Navigation block #37286
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
getdave
changed the title
|
Size Change: +2.3 kB (0%) Total Size: 1.13 MB
ℹ️ View Unchanged
|
getdave
commented
Dec 10, 2021
|
I like this PR, it preserves everything in the post while limiting just the single restricted functionality. It looks like something that other entity-based blocks could use, too. Perhaps the logic here would make a good |
|
IMO we should make the blocks that cannot be edited read only and show the permission message in the inspector or in a flash notification when editing is attempted, so that we don't clutter the layouts so much :) Particularly if we'll add this to other entity based blocks. |
|
Glad you folks believe this is a better route forward. If we can agree to merge this PR, then I can iterate on disabling the UI iterations. In terms of time and scope, can we try and land a solution for the Navigation block only? If that can be abstracted for other blocks then great, but with limited time left I believe we need to focus on the Nav block only. |
|
@jasmussen @javierarce Pinging you both here to see if you have any opinions on how to show the UI warning to the user. |
I updated the implementation to use the global |
|
@getdave This does not handle the case where a user edits a post that contains a navigation post that they can not access. Screen.Recording.2021-12-13.at.16.13.35.movIn this screencast, you can see an admin add a navigation post then a contributor try and edit that post. The REST API 404s but that is not error handling in the editor. |
@spacedmonkey I don't understand this. I tested it and I couldn't replicate. Did I miss a step? Screen.Capture.on.2021-12-13.at.16-59-13.mp4
|
|
@getdave The difference seems to be that you created a new menu, I used an existing menu that was created as part of FSE. I ran my test again, got different buggy results. But when I select the block, I do get an error message. |
|
@spacedmonkey Those replication steps didn't work either. I tried:
Screen.Capture.on.2021-12-14.at.09-14-40.mp4Not sure why you're getting different results here. Could you try rebuilding and then running the test again and noting down the exact steps to replicate what you're experiencing? One thing I noted was that (for some reason) then Menu you are selecting has no items. Was that intentional? |
38 tasks
|
Steps to replicate.
|
Screen.Recording.2021-12-14.at.11.31.36.mov |
|
I think it should be possible to make the blocks mostly non-editable. Possibly it just requires setting I think it could be worth trying it out in a separate PR as a small follow-up. |
talldan
reviewed
Dec 15, 2021
|
I think the flaky test system had an issue with the forward slash in the test description, so I've changed the test description. Hopefully that makes it pass. |
Yes let's tackle this separately. |
Thanks @spacedmonkey. That's actually intended based on @jasmussen's comment
|
ockham
reviewed
Dec 15, 2021
Comment on lines
+822
to
+825
| // Expect a console 403 for request to Navigation Areas for lower permisison users. | ||
| // This is because reading requires the `edit_theme_options` capability | ||
| // which the Contributor level user does not have. | ||
| // See: https://github.com/WordPress/gutenberg/blob/4cedaf0c4abb0aeac4bfd4289d63e9889efe9733/lib/class-wp-rest-block-navigation-areas-controller.php#L81-L91. |
There was a problem hiding this comment.
AFAIK it's entirely expected. In this case the contributor user should not have permission and thus 403 is expected. Running the same test as Admin would see no 403 as they have the requisite capability.
getdave
added
the
Backport to WP 6.7 Beta/RC
adamziel
reviewed
Dec 15, 2021
adamziel
reviewed
Dec 15, 2021
|
I cannot test due to a npm outage, but the code looks good to me. |
talldan
reviewed
Dec 16, 2021
talldan
approved these changes
Dec 16, 2021
talldan
deleted the
try/nav-block-show-permission-notice-when-unable-to-save
branch
|
Thanks to everyone who helped with this, particularly @spacedmonkey for his REST API knowledge and @talldan and @adamziel for reviewing 🙇♂️ |
|
tellthemachines
removed
the
Backport to WP 6.7 Beta/RC
tellthemachines
pushed a commit
that referenced
this pull request
Dec 21, 2021
…n existing Navigation block (#37286) * Show warning when user has insufficient permision to edit the given Nav * Move warning underneath block but allow viewing * Sync warning display with entity loading * Include ref as effect dependency * Revert unintentional edit to comment placement * Show permisisons warning using global notices system * Hide delete and rename inspector items based on perms * Switch to snackbar notice * Add e2e test covering update permission notice * Try removing forward slash to see if test passes * Remove usage of uniqueId Resolves https://github.com/WordPress/gutenberg/pull/37286\#discussion_r769211397 * Update error message to use clearer terminology Addressses https://github.com/WordPress/gutenberg/pull/37286\#discussion_r769214084 * Fix test to match code error message string change * Move permissions selectors to existing hook * Add explaination of requirement for 403 expect for Nav Areas * Attempt to fix flaky test on CI * Remove ref as a dependency to useSelect Co-authored-by: Daniel Richards <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Explores part of #36286 (comment) to display a warning to the user if they have insufficient permissions to edit/update the given Navigation block.
This also disallows renaming or deleting the Navigation via the Inspector controls sidebar.
Note this does not cover the creation of brand new Navigations, but rather the scenario whereby another user has created the Navigation and a lower permission user is attempting to edit it.
Having spoken with release leads, as requested I have raised this Trac ticket.
How has this been tested?
Also check you cannot delete or rename the Navigation using the Inspector controls under "Advanced".
Note you are not stopped from attempting to update. It might be possible to somewhat disable the component but that will be handled in a follow up.
Screenshots
Types of changes
Bug fix (non-breaking change which fixes an issue)
Checklist:
*.native.jsfiles for terms that need renaming or removal).