WordPress.org

Make WordPress Core

Opened 5 months ago

Last modified 2 months ago

#43210 new enhancement

Introduce singular capabilities for managing individual options

Reported by: flixos90 Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Role/Capability Keywords: 2nd-opinion granular-capabilities has-patch
Focuses: rest-api Cc:

Description

We've always had manage_options, but it's currently impossible whether a user can manage a specific option. As part of related tickets dealing with more granular capabilities (see https://core.trac.wordpress.org/query?status=accepted&status=assigned&status=new&status=reopened&status=reviewing&keywords=~granular-capabilities&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=milestone&col=component&order=priority), I suggest adding a meta capability manage_option.

It should accept (or basically require) the option name as argument. By default it should fallback to the regular manage_options, but an auth_callback could be passed to register_setting() to tweak the permissions there (such an auth_callback is already known from register_meta()).

This would also be useful for the REST API so that it can use the more granular permissions.

Attachments (1)

43210.diff (3.1 KB) - added by flixos90 5 months ago.

Download all attachments as: .zip

Change History (4)

@flixos90
5 months ago

#1 @flixos90
5 months ago

  • Keywords has-patch added; needs-patch removed

43210.diff provides an example implementation for the suggested approach.

#2 @flixos90
5 months ago

Somewhat related: #38734 could also make use of that for determining whether to display the individual fields and update their options.

#3 @dlh
2 months ago

A singular capability for managing individual options seems to me like a great enhancement. However, I'm not sure I understand the behavior of the filter in 43210.diff, if I'm following it correctly.

It's described as filtering "whether the user is allowed to manage an option." But if the value of $allowed is filtered to true, the user isn't necessarily allowed to manage the option, as they still need manage_options. If the value of $allowed is false, the user isn't necessarily blocked from managing the option, at least in the way they would be with do_not_allow. Instead, they just need another capability.

Note: See TracTickets for help on using tickets.