Page MenuHomePhabricator

An autoedit of a form of a field that is restricted to a group results in bad behavior
Open, Needs TriagePublic


If you have a form that has a field that is uses the restricted option, and a user triggers an autoedit of the page (either on the page via a button or using the API), if that user is not a member of the group that the restriction is for the edit will still be allowed, but the defaults of other restricted fields will change the fields back to their defaults.

You can see the result of such an autoedit here:

the form has been modified to move the restricted flags for now, but you can see the form as it was during that edit here

Ideally the initial edit should not be allowed, since the user is not a member of that restricted group. And the other restricted fields should not be reverting to their defaults.

Here is the same behavior of fields reverting to defaults and the edit being allowed when it should not have, but this time resulting from a robot using the autoedit API.

Version: master
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 1:13 AM
bzimport set Reference to bz45644.
thingles created this task.Mar 2 2013, 7:41 PM

The autoedit should now only act on the specified field. Restricting to user group needs to be done in SFFormPrinter::formHTML. Re-assigning to Yaron.

f.trott - can you clarify how SFFormPrinter::formHTML() needs to change?

formHTML generates the target page text from the form data and the form definition. In the process it needs to check if a field is restricted and if it is leave it unchanged.

Aklapper removed Yaron_Koren as the assignee of this task.Sep 2 2015, 3:54 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 2 2015, 3:54 PM
Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptNov 19 2015, 2:26 AM