[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             |
----------------------------------+------------------
Changes (by boonebgorges):

 * keywords:   => has-patch


Comment:

 Hi everyone,

 Thanks for your continued work on this.

 >  What I am proposing is that as we build it in a way so that plugin
 developers can extend it how they wish.

 As things stand, developers are welcome to introduce new metaboxes for
 additional types of restrictions. Then they can handle data validation,
 building UI, etc in a way that makes sense for their specific restriction.
 Let's go with the more limited UI for now, and if there's huge demand for
 a broader system after the initial release, let's talk about it then.

 [attachment:5192.diff] is a first attempt at converting this feature to a
 BP patch. It's based heavily on work done by tanner and especially
 Offereins. There are a few important places where I've diverged from the
 previous work. Here's a summary.

 * I've moved the CRUD actions to methods on `BP_XProfile_Field`, which
 seems logical to me.
 * I removed the ability to set this data for XProfile Groups. Offereins, I
 gather from your code that you were kinda thinking of making it more
 broadly available, but I think that's a mistake for the first pass - we're
 then faced with all sorts of problems with cascading, as we've previously
 discussed. This is another thing we can address with a v2, if there's
 demand (though tbh I don't think it'll affect the data model - field_group
 settings will be a UI feature only, which is stored in the DB at the field
 level).
 * I'm using kind of a wacky system for storing data. My primary goal was
 to build an interface and workflows that make sense. So let me explain
 those first, and then talk about how it works.
     a. By default, all fields (new and existing) are available to all
 member types, including the "null" type - users with no type. This means
 that the checkboxes are filled in for all new and existing fields.
     b. You can uncheck boxes, as you'd expect, to disable a field for
 given types.
     c. If you activate a new member type (via plugin), here's what
 happens. If an existing field is available for all types (all checkboxes
 are checked), then it continues to be available for all types, including
 the new type. If an existing field has limited availability (at least one
 checkbox is unchecked), then the new type will be *unchecked*. It seems to
 me that this is the behavior that most people would expect, since the
 default state of a field is to be available to everyone.
 I've spent some time playing with various scenarios: new fields, existing
 fields, activating member types, disabling member types, etc, and the
 workflows described above all feel pretty natural to me. I would really
 love to get feedback on this.

 The data model that makes it possible is, as noted, pretty weird. If all
 checkboxes are filled, then *nothing* is stored in the database. (This
 saves space: most fields will be available to everyone.) If *some*
 checkboxes are filled, then an xprofile fieldmeta entry will be saved for
 each. If *no* checkboxes are filled, then a *single* fieldmeta entry will
 be saved, with value `'_none'`. Yes, this is weird. But the
 `$field->get_member_types()` and `$field->set_member_types()` should make
 it completely unnecessary for anyone to access these values directly, and
 these methods behave in exactly the way you would expect.

 UI and code feedback welcome!

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