[buddypress-trac] [BuddyPress] #5237: BuddyPress arbitrarily changes user field type

[buddypress-trac]

#5237: BuddyPress arbitrarily changes user field type
--------------------------+------------------
 Reporter:  sgr33n        |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  highest       |   Milestone:  1.9
Component:  XProfile      |     Version:
 Severity:  blocker       |  Resolution:
 Keywords:                |
--------------------------+------------------
Changes (by boonebgorges):

 * priority:  normal => highest
 * component:  Core => XProfile
 * severity:  normal => blocker
 * milestone:  Awaiting Review => 1.9


Comment:

 Confirmed.

 There are two parallel bugs, which have been uncovered by [7419]. See
 #4947.

 Previously, `can_delete` was never being set, because of an oversight in
 the way profile fields were saved. Since [7419], this problem is fixed.
 But now new fields have `can_delete` set to 0 (which is what the null
 value becomes when run through `$wpdb->prepare( '%s' )`) instead of null.
 As a result, newly created fields are being set to `can_delete = 0`. This
 is incorrect: the only purpose of `can_delete`, from the point of view of
 BP core, is to prevent users from deleting field #1, the fullname field.
 We don't even have UI for changing that setting. The solution to this
 problem is to ensure that `BP_XProfile_Field` objects have a default
 `can_delete` value of 1; the fullname field will still be created with
 `can_delete = 0` by `bp_core_install_extended_profiles()`.

 The separate bug, which is more directly related to this ticket (though is
 secondary to the first bug in a way), is that the secondary fields on the
 profile field edit panel are currently hidden when `'0' ==
 $this->can_delete`. Again, the intent of this is to ensure that you can't
 change the visibility, etc of the Fullname field, but it's implemented in
 an overbroad way, since fields other than 1 might have `can_delete = 0`,
 but there's no reason why you shouldn't be able to edit visibility, field
 type, etc. The solution to this problem is to hide the additional fields
 when the field_id = 1, rather than when can_delete = 0 - a more targeted
 check.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5237#comment:1>
BuddyPress <http://buddypress.org/>
BuddyPress