Site editor related links are exposed to non-admin users

[t-hamano]

Description

When generating a link to a page in the site editor, it is determined whether the site editor can be accessed, mainly through the following code, and the link destination is changed depending on the result.

gutenberg/packages/edit-post/src/components/header/more-menu/manage-patterns-menu-item.js

Lines 11 to 23 in 771acf4

	const url = useSelect( ( select ) => {
	const { canUser } = select( coreStore );
	const defaultUrl = addQueryArgs( 'edit.php', {
	post_type: 'wp_block',
	} );
	const patternsUrl = addQueryArgs( 'site-editor.php', {
	path: '/patterns',
	} );
	// The site editor and templates both check whether the user has
	// edit_theme_options capabilities. We can leverage that here and not
	// display the manage patterns link if the user can't access it.
	return canUser( 'read', 'templates' ) ? patternsUrl : defaultUrl;

However, in the latest version of Gutenberg, canUser( 'read', 'templates' ) returns true for non-administrator users, and they are now considered to have "access to the site editor." As a result, when you run the command, you will receive an error indicating that access is not possible.

Step-by-step reproduction instructions

• Create a user with the Editor role and log in as that user.
• Open the post editor.
• When you start the command, you should see items like Styles, Templates, etc.
• If you click on those items, you should see an error.
• The "Manage all patterns" link should give you a similar error.

Screenshots, screen recording, code snippet

74b016a86c8e6130d47a3af5309f25e7.mp4

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[t-hamano]

I think this issue is caused by #60317.

[bacoords]

Thanks for confirming as I was seeing this in my PRs.

That said, I would also like to throw out the idea that if the ability for editors to read templates were determined not be a regression, perhaps the way we check for a user's ability to access the Site Editor could change.

Perhaps outside the scope of this, but it could be cleaner if we had a core-data function that more closely corresponded to current_user_can() or something similar that we could directly pass user capabilities (i.e. 'edit_theme_options') to.

[fabiankaegy]

Great find. And yes that seems like my PR introduced this. I would say though that instead of changing the access levels back the way to fix this is using the canUser( 'create', 'templates' ) check.