Fixing permissions, reset and validation errors on protected fields

I'm updating the testcase to cover the fact that protected field must be shown using 'view xxx field' and 'view own xxx field', and edited according to 'edit xxx field' and 'edit own xxx field'.

Boombatower, please, review the testcase to confirm that this is what we need to solve, and also drop a word about what doing with empty category groups (hidden fields can be moved out of the fieldset to allow unset() of the fieldset in the worst case), and also about what we do when user has view permission but NOT edit permission and can 'administer users', should be able to see the field disabled? or just a markup, or nothing at all?.

Hi boombatower, thanks for the review. For me there are two things not safe at all:
- using '#disabled' property, as you said, double effort.
- moving fields out of the fieldset (not just because we are altering #tree, but because the purpose of this move is to unset the container, but there is no guaranty at all that this container may be form_altered later.

My prefered solution will be using 'hidden' and 'hidden and markup' to hide/show the field (markups don't even reach validate). I agree with the permission change in the "show but can't edit" case, so this is something we can start working on from now.

About removing the container fieldset, not only I don't see this easy, it is far from being safe, because the first thing to do is move all contained fields out, and unless we setup the module's weight to 99, and form_alter ourselfs from the module, there is no way to know if other modules have included new fields before unsetting the fieldset. That is the only solution I can found 'safer' enough to consider.

Ok, taking the patch and start working on the 'hidden' and 'markup' stuff first.

Oh, I forgot to mention in the previous comment, that I first planed to use '#access' in the form elements that have the permission, but that would make the entry not visible when user has no editing permisisons. This is the missing rationale behind 'hidden and markup' proposal.

Just to make sure I don't forget anything, I've been reviewing how user.module does the 'account' fieldset management (it shows the container only under certain circunstances).

user.module:2468

Verify that no other groups are there and then removes the 'account' fieldset. We can user something like that to handle the container (even not setting the module's weight to 99) by making a form_alter call to all modules and verify the new fields attached to the form. The other way I just think about is to start doing some themeing processing, and remove the category from the profile when it is being shown if there is no content.

I'm working on a patch these days, hopefully I'll get it finished by Friday.

just to mention, it is a problem with timings, nothing to do with the module. The patch is really simple, but had to focus on other issues. Anyway I'll eventually come to this in a few days, according to my working plan I do have to get this one fixed by monday or tuesday (even if not committed or fixed yet)..

Ok, first attempt!!

I've included a bugfix to prevent the variable 'profile_permission_fields' to grow up everytime a profiel field is edited. A big change in the approach is that now the protected field is not hidden, neither shown: it is set as 'value' type to prevent from being sent back to the browser (hidden fields are sent) but still proccessed by FAPI in the form submission. As the field does not exist in the browser, a new field is created with a new name ($name . '_view') that is set to dissabled if user does not have permissions to edit, and removed again if user has does not have permissions to see the field.

A minor fix has been included in the profile view, as the tree element parsing must have been included in an 'else' clause.

Todo: With this patch we prevent field values from being overwritten and also, when protecting the edition, fields will still be shown but will not accept changes. From here, I'd suggest to also commit the #772570: One Page Profile module incompatibility, and try to find a way (I think it is not easy) to remove the fieldsets when there are no more visible/editable fields.

A more aggressive error warning in PHP raised a notice.

After some tests ir a real site looks like it is working fine for me. This will not prevent hook_form_alter failing for the 'hidden' fields, but I'm not aware of any use case like this.

If this is your use case or still think this is not safe, I could try another approach, but it may fail in other way:
- get each protected fields and make a copie of a 'value' element in the form.
- set disabled, unset, whatever during form load.
- on form_submission, replace protected field values with the copies.
This approach may leave the fields with their name to be altered by hook_form_alter calls, but will fail for modules overriding the validations and submit form functions.

Thoughts?