[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:  2.4
Component:  Component - XProfile  |     Version:
 Severity:  normal                |  Resolution:
 Keywords:  has-patch             |
----------------------------------+------------------

Comment (by boonebgorges):

 Again, thanks for the great feedback, everyone - very, very helpful.

 Changes in [attachment:5192.3.diff]:

 * Updated the appearance of labels on the Profile Fields page. When a
 field is available for all types (unrestricted), I've removed the label.
 See the screenshot above. I have mixed feelings about this: it does make
 for less clutter, but I wonder if it will make people wonder whether the
 field is invisible to all types. I also changed the format of the label
 shown when a field is available for *no* types - see the red message in
 the screenshot.
 * Added a dynamic notice to the metabox when all boxes are unchecked. See
 screenshot above. The message appears/disappears as you'd expect when
 checking/unchecking boxes. For all of these labels, I'd welcome
 suggestions for improved wording.
 * I added a thin layer of caching for `get_fields_for_member_type()`. It's
 not straightforward to cache entirely, due to complications in the way
 that member types are registered with BP at runtime (making cache
 invalidation complicated), and newly registered fields should be available
 for all member types at the time tha they're registered.
 * Don't show a Member Type message for field 1.
 * In `BP_XProfile_Group::get()`, skip processing 'member_type' param if no
 member types are registered.

 I agree that we should allow admins to restrict fields in the "Base"
 group. I see tanner's logic here, but I agree with the others that it's an
 undue restriction, and that there are good use cases for having restricted
 fields in group 1.

 Any thoughts are welcome!

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