Add option to inherit capabilities

[rmccue]

While register_post_type (and by extension Extended CPTs) allow specifying a custom capability type, often custom capabilities are avoided because they're a pain to actually use. It would be great if Extended CPTs could enable better use of custom cap types to encourage this best practise.

There's two primary ways these are implemented:

1. Automatically adding to specific roles - A lot of custom code will add the caps to specific roles (on activation or via checking on each request). Depending on how this is implemented, this may make it harder to manage roles, and this requires specific work for custom roles (which may or may not be desirable).
2. "Inheriting" from other capabilities - Less used, but used in core for some of the newer features, is granting a capability based on another capability. This works automatically with custom roles while allowing the capabilities to be granted or specifically excluded from roles as desired. This behaviour may in some cases be surprising with custom roles if one expects them to only have an explicit set of caps. It's also a bit tricky to implement correctly (and imo core does it wrong).

(Note that the latter is not mapping the caps to a primitive cap, but rather filtering a user's primitive caps.)

I'm in favour of the latter option, as I think it's a bit nicer for custom roles, while still allowing explicit denial of the caps if desired.

For example, say I have a new "Doc Pages" CPT. I have some users I want to give permissions to for only these CPTs, so they should be a proper capability type, but I also want everyone who can edit pages to be able to edit these.

I'd like to do something like:

register_extended_post_type( 'doc_pages', [
    'capability_type' => 'doc_page',
    'inherit_caps_from' => 'page',
] );

[johnbillion]

I think I like this idea and I can see uses for it. Could you share the code sample that we chatted about in Slack the other day?

[johnbillion]

@rmccue Do you have that code sample somewhere?