[wp-trac] [WordPress Trac] #44176: Un-map Privacy Capabilities
WordPress Trac
noreply at wordpress.org
Thu Dec 26 19:32:17 UTC 2019
#44176: Un-map Privacy Capabilities
-------------------------------------------------+-------------------------
Reporter: desrosj | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: 5.4
Component: Privacy | Version: 4.9.6
Severity: normal | Resolution:
Keywords: 2nd-opinion has-patch dev-feedback | Focuses:
has-screenshots |
-------------------------------------------------+-------------------------
Comment (by pbiron):
[https://core.trac.wordpress.org/raw-attachment/ticket/44176/44176.3.diff
44176.3.diff] is the same as [https://core.trac.wordpress.org/raw-
attachment/ticket/44176/44176.2.diff 44176.2.diff] with the following
additions:
1. the calls to `map_meta_cap( 'manage_privacy_options', $user_id )` in
`map_meta_cap()` are replaced as decribed in
[https://core.trac.wordpress.org/ticket/44176#comment:26 comment 26]
2. an `upgrade_540()` function is added so that existing sites get the
caps added to the administrator role
I'm not sure how things have been handled in the past with patches that
depend on a specific `$db_version` (i.e., commit number that hasn't
happend yet), but for the purposes of this patch I just made the check
(for whether `upgrade_540()` is called) use the `$db_version` in 5.3.2 +
1. Note: with that, you won't have to do the "trick" described in
[https://wordpress.slack.com/archives/C9695RJBW/p1576780136083900?thread_ts=1576779804.082600&cid=C9695RJBW
this slack thread] in order to test that the primitive caps have been
added...but it means that `upgrade_540()` gets called on every admin page
load (it's inexpensive, so you'll probably never notice).
--
Ticket URL: <https://core.trac.wordpress.org/ticket/44176#comment:27>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list