-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Show a UI warning when user does not have permission to update/edit an existing Navigation block #37286
Show a UI warning when user does not have permission to update/edit an existing Navigation block #37286
Conversation
Size Change: +2.3 kB (0%) Total Size: 1.13 MB
ℹ️ View Unchanged
|
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. |
@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? |
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. |
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
|
// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems similar to #33003?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
I cannot test due to a npm outage, but the code looks good to me. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for making those late changes.
Thanks to everyone who helped with this, particularly @spacedmonkey for his REST API knowledge and @talldan and @adamziel for reviewing 🙇♂️ |
|
…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]>
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.js
files for terms that need renaming or removal).