[buddypress-trac] [BuddyPress] #4296: Base xprofile field Name(primary) and visibility when logged in as superadmin

[buddypress-trac at lists.automattic.com]

#4296: Base xprofile field Name(primary) and visibility when logged in as
superadmin
--------------------------------------------------+-----------------------
 Reporter:  imath                                 |       Owner:
     Type:  defect (bug)                          |      Status:  new
 Priority:  normal                                |   Milestone:  1.6
Component:  Core                                  |     Version:  1.6-beta
 Severity:  critical                              |  Resolution:
 Keywords:  has-patch needs-testing dev-feedback  |
--------------------------------------------------+-----------------------

Comment (by boonebgorges):

 > I don't quite understand why the is_super_admin check does not work in
 this case

 WP's core system has the following logic: On multisite, if you are super
 admin, you automatically get all caps, *except when a cap is mapped onto
 'do_not_allow'*. That way, it's possible to make `current_user_can( 'foo'
 )` to return false for a given foo, even for super admins. In our case, we
 want `current_user_can( 'bp_xprofile_change_field_visibility' )` to return
 false for all users, even super admins, for the fullname field. The WP way
 to do this is to map 'bp_xprofile_change_field_visibility' onto
 'do_not_allow'. But the `if ( is_super_admin() ) return true;` check at
 the beginning of our `bp_current_user_can()` was wrecking this, by making
 every cap return true for SAs. The original intention of this super admin
 check was, I assume, to ensure that super admins have the catch-all
 `'bp_moderate'` cap; my patch does this, without disrupting the ability to
 have other instances of `bp_current_user_can()` return false for SAs.

 (It's complicated ;) )

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4296#comment:5>
BuddyPress <http://buddypress.org/>
BuddyPress