WordPress.org

Make WordPress Core

Opened 10 months ago

Last modified 5 months ago

#45423 assigned defect (bug)

Use custom capabilities for the block editor's reusable blocks.

Reported by: peterwilsoncc Owned by:
Milestone: 5.3 Priority: normal
Severity: normal Version: 5.0
Component: Role/Capability Keywords: needs-patch needs-unit-tests
Focuses: Cc:

Description

The new wp_block post type for reusable blocks is currently mapped to the post post types capabilities, including some work-arounds in map_meta_cap() for the purpose.

To allow for custom roles limiting users to editing/reading certain post types (for example a "Page Editor" or "Photo manager") these ought to have their own capabilities, consistent with other built in post types.

This will also allow web site owners to customize existing roles; for example to allow authors to edit another user's reusable blocks or for contributors to create them.

Follow up from #45098.

Attachments (2)

45423.diff (4.6 KB) - added by peterwilsoncc 10 months ago.
45423.2.diff (23.8 KB) - added by peterwilsoncc 8 months ago.

Download all attachments as: .zip

Change History (16)

#1 @matveb
10 months ago

  • Milestone changed from Awaiting Review to 5.0.1

#2 @pento
9 months ago

  • Milestone changed from 5.0.1 to 5.0.2

#3 @pento
9 months ago

  • Milestone changed from 5.0.2 to 5.1

This one is going to need some more thinking time. Moving it to 5.1, but we can move it back to a 5.0.x later if there's time.

#4 @peterwilsoncc
9 months ago

@pento Is there anything in particular you need me to take a look at to help move this forward?

#5 @desrosj
8 months ago

Related bug: #45373.

#6 @peterwilsoncc
8 months ago

  • Milestone changed from 5.1 to Future Release

There are a few things I see needed for this to go forward:

  • Hiding the appropriate UI element for users failing the create_post or edit_post meta caps
  • Removing the option to insert shared blocks for users blocked from reading them (in the dropdown, via a slash command and anywhere else I have forgotten)
  • Removing the menu should be handled by core already
  • Decisions about which core roles should be able to publish a shared post if that needs to be different to the rules for posts and pages
  • What happens for users who can create posts but not publish them when they attempt to create a post from within the authoring UI. IE, is the content duplicated, an unpublished post inserted into their current post or 🤷🏻‍♂️

It's the eleventh hour for the 5.1 release. As there's a fair amount to consider, I'm moving this to future release.

This ticket was mentioned in Slack in #core-editor by desrosj. View the logs.


8 months ago

#8 @peterwilsoncc
8 months ago

  • Keywords has-unit-tests added
  • Milestone changed from Future Release to 5.1
  • Owner set to pento
  • Status changed from new to assigned

In 45423.2.diff

  • replaces the primitive caps used by blocks with *_blocks
  • The read and create_posts post type caps use an atypical mapping, the caps are not needed for the roles
  • updates the block permissions tests to use edit_post, create_post and delete_post meta caps
  • adds the new caps to roles in an update routine
  • adds the new caps to the existing unit tests
  • the UI for authors and contributors remains visible on the add page/post screens, however this isn't a regression.

This fixes the white screen issues identified in #45373.

#9 @pento
8 months ago

Given that this approach has been working in the Gutenberg plugin, I'm inclined to run with it.

One important thing for the dev note, sites that delay running the upgrade routines (eg, multisites) must do it before upgrading, or the block editor will throw errors when you try to use or create reusable blocks.

#10 @flixos90
8 months ago

  • Keywords needs-patch needs-unit-tests added; has-patch has-unit-tests removed
  • Milestone changed from 5.1 to 5.2

I recommend against moving forward with this approach. We haven't introduced new primitive capabilities since WordPress 3.0, and that is for a reason. Migrating databases like that should not be required and can easily cause issues, specifically with larger multisites. There have been numerous capabilities introduced since 3.0, but these have always used either the map_meta_cap or user_has_cap filter, granting them dynamically.

I think we should introduce these capabilities as dynamic capabilities using the user_has_cap filter, making them what I have so far called "fake-primitive" capabilities (only for the lack of a better word). See #44468 for more information on that.

Since this ticket has been moved from 5.1 to "Future Release" before, it seems to not be super-critical for 5.1. Let's tackle #44468 and this one as an enhancement for 5.2, to have sufficient time for a proper implementation. I'll move the two tickets to that milestone now, and I'm happy to work on it. For the unit tests, this ticket is blocked by #44468.

If I was mistaken and this ticket is more critical, I suggest moving both of them to 5.1.x.

#11 @johnbillion
8 months ago

I concur with Felix. Introducing new primitive capabilities is impossible due to the use of custom roles that also potentially need to receive the new caps. Beyond the default roles in WordPress, a custom role could be given the edit_posts capability but would never receive the edit_blocks capability with this upgrade routine.

These caps should be granted dynamically via the map_meta_cap or user_has_cap filter.

#12 @pento
8 months ago

  • Owner pento deleted

@flixos90, @johnbillion: That's basically what Core is already doing, except it's happening slightly before the user_has_cap filter, in map_meta_cap().

The issue isn't in granting the capabilities, the issue appears to be in how custom post types interact with these "fake primitive" capabilities, particularly when trying to map them to other fake primitives: they don't seem to map correctly.

I'll commit the fix in #45373 for now, and we can see what feedback we get during beta, but we may need to revisit this ticket before 5.1. I don't really want to add caps to the database (hence why we didn't in 5.0), so I'd appreciate y'all making some time to dig into this further.

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


5 months ago

#14 @audrasjb
5 months ago

  • Milestone changed from 5.2 to 5.3

As per today's bug scrub, we are going to move this one to the next Release since beta 3 and RC are approaching.

Note: See TracTickets for help on using tickets.