[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:                        |
----------------------------------+------------------

Comment (by boonebgorges):

 Very cool, Offereins!

 I just pushed a mod to my fork of your repo that changes the wording of
 the description and the "null" option to read like in
 [attachment:Screenshot_2015-07-02_14-41-09.png]. The shorter description
 seems clearer to me; I like putting the "null" option at the end of the
 list; and I think that "users with no member type" is less ambiguous (to
 me, "none" could mean "no users").

 I'm still concerned about my point 3 above. A few thoughts:

 a. In BP 2.3, all fields are shown to all member types. When upgrading to
 2.4, the default behavior should be the same. Otherwise, existing fields
 will disappear until the admin takes action. So either (i) we'll need a
 migration routine during 2.4 upgrade, or (ii) when
 `get_xprofile_member_types()` returns an empty array, we'll need to
 interpret it as "all" rather than "none", or (iii) we'll need to change
 the way the data is stored so that a field that has never had the "member
 types" value set (ie, legacy fields) will be distinguishable from those
 that have had the "member types" value set to "no types". Each of these
 options is unpleasant in its own way, but I think we have to do one of
 them.
 b. I think it's correct behavior that all boxes would be checked when
 creating new fields. It's likely that, for most sites, most new fields
 will be intended for all member types. That is: limited-access fields will
 be the exception, rather than the rule.
 c. It might be nice to have JS-powered "Select All"/"Select None" links,
 or maybe a checkbox column header for a similar purpose.

 I'm particularly concerned about item (a) here. Offereins, do you have
 thoughts about which of these techniques is the least unpleasant? Or maybe
 you have a better idea :)

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