[buddypress-trac] [BuddyPress Trac] #5192: User roles with differents profile fields

[buddypress-trac]

#5192: User roles with differents profile fields
----------------------------------+-----------------------------
 Reporter:  _DorsVenabili         |       Owner:
     Type:  enhancement           |      Status:  new
 Priority:  normal                |   Milestone:  Future Release
Component:  Component - XProfile  |     Version:
 Severity:  normal                |  Resolution:
 Keywords:                        |
----------------------------------+-----------------------------

Comment (by boonebgorges):

 I agree that storing an array is a bad idea.

 I'm thinking something like this. Use `bp_xprofile_add_meta()` to add a
 member type to a given field. This allows you to have multiple member
 types for a given field:

 {{{
 bp_xprofile_add_meta( $field_id, 'field', 'show_to_member_type', 'student'
 );
 bp_xprofile_add_meta( $field_id, 'field', 'show_to_member_type', 'teacher'
 );
 }}}

 This means that when you query for a single field's member types, you need
 to be sure to fetch the whole array (`$single = false`):

 {{{
 $member_types_for_this_field = bp_xprofile_get_meta( $field_id, 'field',
 'show_to_member_type', false );
 // array( 0 => 'student', 1 => 'teacher' )
 }}}

 In the loop, you will have access to a meta_query. (Not yet fully
 implemented; see [9722] and #6347.) So if you want to fetch all fields
 that need to be shown to the current user, it'll look something like:

 {{{
 $current_user_member_type = bp_get_member_type( bp_loggedin_user_id(),
 false ); // single=false
 bp_has_profile( array(
     // ...
     'meta_query' => array(
         array(
             'object' => 'field',
             'key' => 'show_to_member_type',
             'value' => $current_user_member_type,
             'compare' => 'IN',
         ),
     ),
     // ...
 ) );
 }}}

 The API might look a little different here - you might, eg, pass a
 'member_type' param to `bp_has_profile()`, and then prepare the
 'meta_query' clause internally, but this gives you the idea.

 > When multiple member types can be selected per field: how does this
 translate to field types (optional/required), when different member types
 should have different field types?

 At a glance, I'd think that assigning a field to multiple member types
 would mean that a user with at least one of the member type would then see
 the field. So, in the above situation, a user with member type 'student'
 would see the field in question. We'll have to make this as clear as
 possible in the UI, and we'll have to come up with a trick to make sure
 that fields with *no* member type associations are shown to *all* users.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5192#comment:12>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac