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

 > Could you elaborate on the foreseen issues with applying this to both
 fields and fieldgroups? Because I can see great value in it being
 implemented for both, and my implementation with groups didn't see
 much/any trouble.

 I'm concerned about UX when field and fieldgroup settings overlap. If you
 have group A with fields 1, 2, and 3; and if you set group A so that it's
 applicable only to member type 'foo', but set field 2 so that it's
 applicable only to member type 'bar', who actually sees field 2? In other
 words: how do settings cascade downward, and how do we show that in the
 UI? It's not impossible to do this, of course - we can dynamically change
 settings, and give warnings to users, etc etc - but it's much more
 complicated than simply having a single layer of settings.

 A related idea: member-type-applicability applies only at the field level
 (not group), but we have a bulk-editing interface that allows admins to
 apply changes to entire groups at once. I think this might be easier than
 dealing with the cascading logic described above, and it accomplishes much
 the same thing.

 > My personal preference goes to option 1, since I imagine fields are more
 often specific to one member type than to all-but-one

 This sounds sensible, and I think it makes sense to go with something
 simpler for the first version of the feature - we can build it out to be
 more robust later on if there is demand.

 For registration, something like your option (3) is probably the best for
 the first version of the feature.

 Offereins, if you are interested in taking the first swing at a patch for
 this - especially given your experience building a sorta-similar plugin -
 please let me know, and I will give you room to work before diving in
 myself :-D

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