[buddypress-trac] [BuddyPress Trac] #5192: User roles with differents profile fields
noreply at wordpress.org
Fri Jul 10 20:27:17 UTC 2015
#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
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
* 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
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/>
More information about the buddypress-trac