Right. I think I didn't run into that issue because the original values in the updated record already satisfied the validation criteria.
Note, there was another problem with the solution allowing a malicious user to pass back altered values for the readonly fields, so I updated the code to an an onvalidation function that removes the readonly field from form.vars to prevent them from being written to the database. Anthony On Sunday, April 23, 2017 at 7:49:43 PM UTC-4, Joe Barnhart wrote: > > Hi Anthony -- > > After some digging, I think I understand the flow and why this is required. > > When the form is built, one of the byproducts is to create a widget for > each field and preset that widget with the information it needs to do > validation (i.e. the 'requires' of the field is copied to the widget). By > the time the "form = SQLFORM(...)" is executed, the widgets are built and > they contain the requirements of the fields. > > The selector fields using the IS_IN_SET() validator will fail if the field > doesn't contain a valid selection -- irrespective of whether that field is > "read only" or not. This check is done at the XML level and does not care > about any of the settings of the Field objects at the time the check is > done. So nothing done to the fields with respect to making them writable > of not can have any effect at this level. > > By putting the "requires=[]" or even "requires=None" in the custom widgets > AFTER they are built by SQLFORM, we turn off this unwanted behavior and > ensure that readonly fields cannot cause a validation failure. I've > stepped through it both with and without this change, and the change is > definitely essential for SELECT objects. Now, it could be limited to only > SELECT objects, but there is no harm in broadening it to all widgets. > > Warm regards, > > Joe > > > On Saturday, April 1, 2017 at 12:51:55 PM UTC-7, Anthony wrote: >> >> On Friday, March 31, 2017 at 5:41:49 PM UTC-4, Joe Barnhart wrote: >>> >>> Anthony -- >>> >>> One more tiny but not insignificant detail... >>> >>> I found I had to add "requires=[]" to the custom.widget: >>> >>> [form.custom.widget[f.name].update(_readonly=True, requires=[]) for >>> f in readonly_fields] >>> >>> Otherwise, the field keeps the 'requires' of the original Field and the >>> check fails. The above solution is working very well! >>> >> >> Hmm, I didn't have that problem. Do you have an example model that >> exhibited that behavior? >> >> Anthony >> > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
