Pattern overrides: ensure an additional meta capability for override capability

[annezazu]

Pulling this question out of yesterday's hallway hangout on WordPress 6.5:

Question from Jorbin: “Do pattern overrides include capability checks so that it is possible for someone to be able to use the pattern and the overrides without editing the pattern as a whole? What I am thinking is having a meta capability for managing the pattern and then a separate meta cap for doing overrides.”

This was underscored by others on the call as important to have. You can listen to the question/discussion starting here. It's only 1-2 minutes! Can someone chime in to clarify? @talldan as we chatted a bit about this. @aaronjorbin so you know this has been followed up on.

[aaronjorbin]

Thanks so much for kicking this off @annezazu!

To add some additional context around this, one use case that I'm thinking of is a related posts block on a media site. For that you might want:

1. A set of users who can manage the pattern as a whole.
2. A set of users who should be able to do the overrides.
3. A set of users who can only add the block and not add any overrides whatsoever.

[talldan]

Thanks for the question @aaronjorbin!

We're presently using the existing capabilities at the moment:

1. The users who can edit the original pattern haven't changed, it's still the same requirements for editing the wp_block post type. Anyone that can do that can also define the parts of the pattern can be overridden.
2. For inserting a pattern block instance and setting override values in that instance, that comes down to the permissions of the post the pattern is inserted into. The overrides are considered content of the post (the data is saved as an attribute of the pattern block, so doesn't affect the original pattern in any way).
3. This one isn't currently possible. Given the way 1 & 2 are implemented, I think this would mean capabilities that allow inserting blocks but not editing the block content. It could be something to think about for the future, but maybe more as a generic feature (not just patterns) that might apply to any block types in connection with block locking or similar features.

[kraftner]

Related: #28895 (comment)

[gziolo]

I don't think this issue should have the [Type] Question anymore. It contains enough context to validate the idea and start exploring possible solutions. In fact, it's time to establish some best practices for these new power features, as we recently ran into a similar challenge of how to expose the UI for managing Block Bindings in the editor only to user that have proper permissions:

• Block Bindings: Add canUpdateBlockBindings editor setting wordpress-develop#7258

I also learned that so far in the editor, some features are gated through block editor setting, like Block Locking Settings in WordPress 6.0. While it works pretty well, it isn't the simplest thing to discover, see example:

add_filter(
	'block_editor_settings_all',
	function( $settings, $context ) {
		// Allow for the Editor role and above - https://wordpress.org/support/article/roles-and-capabilities/.
		$settings['canLockBlocks'] = current_user_can( 'delete_others_posts' );

		// Only enable for specific user(s).
		$user = wp_get_current_user();
		if ( in_array( $user->user_email, [ '[email protected]' ], true ) ) {
			$settings['canLockBlocks'] = false;
		}

		// Disable for posts/pages.
		if ( $context->post && $context->post->post_type === 'page' ) {
			$settings['canLockBlocks'] = false;
		}

		return $settings;
	},
	10,
	2
);

Interestingly enough, by design, this feature is enabled in the UI through the client-side setting that only gets modified if a different setting is set on the server through this filter:

gutenberg/packages/block-editor/src/store/defaults.js

Lines 157 to 158 in 82bc72d

	// Allows to disable block locking interface.
	canLockBlocks: true,

This issue is also related to an existing issue for regular patterns:

• Patterns: ability to disable creation of patterns for certain roles/permissions #28895