BuddyPress arbitrarily changes user field type

[sgr33n]

To reproduce:
Create a new user field datebox.
Then modify this field, changing default visibility. The field will become textbox, without the chance to change it back, except acting directly on the database.

[boonebgorges]

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.

[boonebgorges]

In 7563:

Ensure that xprofile fields have a default can_delete value of 1.

[7419] fixed a long-standing bug that prevented the can_delete value from being
saved when creating/editing an xprofile field. However, it uncovered a new bug,
which is that new xprofile fields were being created without specifying that
the default value of can_delete should be 1. As a result, all new fields
were being created as non-deletable (and, in fact, non-editable; see #5237 for
more details).

See #5237

[boonebgorges]

In 7564:

Prevent admin fiddling with Fullname field with properly narrow conditions.

BP prevents admins from editing the visibility and field type settings of the
Fullname field, because BP needs it to be public and a textarea. However, BP
was enforcing this edit block by checking the can_delete flag of the
BP_XProfile_Field object. In practice, it's usually the case that only field 1
will have the value of can_delete = 0. However - especially due to changes in
[7419] - other fields can have can_delete = 0 as well. The edit block should
therefore be more specific, based on the ID of the field rather than on the
value of can_delete.

Fixes #5237