It turns out that the issue wasn't even related to IS_NOT_EMPTY()... Since the field wasn't include it couldn't block the form to submit... Though I may have the issue in other form where it is included..
What was the root cause of my issue was in fact (as far as I can understand) that the id field of the record wasn't include in custom form which prevent form.process() to process correctly the form... Could it be cause of _enable_record_versioning() that I active over auth_user table somewhat recently... Issue run out without me noticing it... I am glad that I finally resolve this one... Richard On Wed, Mar 9, 2016 at 1:58 PM, Richard Vézina <ml.richard.vez...@gmail.com> wrote: > Damn it, there is surely something else wrong also... Even with the > removal I seems to have difficulty with other fields not included in the > custom form which are removed with readable and writable False... > > I start to be clue less about the root cause of this issue... This form > has worked properly for year now and it seems now completly broken... > > Richard > > On Wed, Mar 9, 2016 at 12:19 PM, Richard Vézina < > ml.richard.vez...@gmail.com> wrote: > >> Hello Anthony, >> >> Last suggestion seems the way to go... I do understand and I realise by >> trying to hack IS_NOT_EMPTY() that it makes no sens to refactoring it in >> anyway to make it support bool null since it never going to allow null >> value to be input in the DB. Though it certainly shouldn't prevent a form >> to submit properly when used with a bool type field. I may have use it by >> mistake with bool field... But I think, base on this post which is not mine >> in the first place, that I am not alone thinking that it usage in >> conjonction of a bool type field will prevent the form to allow null bool >> type field input (which is wrong thought since html checkbox can't return >> null value)... >> >> So, you idea if apply, is a really good way to fix the situation... >> >> >> *How I come here:* >> I have hunted so much the reason for a bug that I had with a custom form >> which only appears recently which I am still not sure why... Stange enough >> even if the form wasn't submit and the system was throwing ticket, computed >> _thumbnail_ files from compute upload fields related to an main upload >> field of user profile picture were deleted. The form was returning error, >> but the field wasn't include in the form so error can't be seen on form >> submission. I guess what was really happen was that the insert process was >> falling kind of too late and the _before_update callback was already >> triggered... False positive ticket related to the actual issue : >> https://github.com/web2py/pydal/issues/330 >> >> So thumbnails get delete and then the insert fails... >> >> For now I think that as a workaround I can just remove the IS_NOT_EMPTY() >> from field definition that was causing the issue. >> >> Thanks for your help Anthony >> >> Richard >> >> On Tue, Mar 8, 2016 at 4:41 PM, Anthony <abasta...@gmail.com> wrote: >> >>> On Tuesday, March 8, 2016 at 3:01:48 PM UTC-5, Richard wrote: >>>> >>>> For instance how someone can acheive the same than NullBooleanField of >>>> Django : >>>> >>>> >>>> https://docs.djangoproject.com/en/1.9/ref/models/fields/#django.db.models.NullBooleanField >>>> <https://www.google.com/url?q=https%3A%2F%2Fdocs.djangoproject.com%2Fen%2F1.9%2Fref%2Fmodels%2Ffields%2F%23django.db.models.NullBooleanField&sa=D&sntz=1&usg=AFQjCNFC6L_ivJ7kGqBBMOORpIo7UZJIcQ> >>>> >>> >>> In web2py, a regular boolean field allows NULLs, so I don't think we >>> need a special field type. In Django, the NullBooleanField is intended to >>> be used with the NullBooleanSelect widget, which actually includes three >>> options (with "uknown" being equivalent to a NULL). I suppose in web2py, >>> you could achieve this with a standard select widget (with a None option), >>> and then use an IS_IN_SET or IS_NOT_EMPTY validator. >>> >>> >>>> One part of the problem with IS_NOT_EMPTY() is that it seems to be >>>> intent to work only with string field type, from the book : >>>> >>> >>> It does work with other types of values, but there isn't much point to >>> it when working with boolean form fields, as they cannot be empty by >>> definition (though I suppose the distinction could be made when using the >>> .validate_and_insert method). >>> >>> >>>> Or we can just fix IS_NOT_EMPTY() so it works with boolean type field >>>> so that it returns false when the checkbox is leave blank as it should... >>>> >>> >>> There's nothing to fix with IS_NOT_EMPTY() -- it doesn't know what type >>> of field produces the value it is passed, so it cannot behave differently >>> depending on the type of field. We could instead change the behavior of >>> SQLFORM so it automatically converts empty checkboxes to False values, >>> which would then pass validation with IS_NOT_EMPTY. >>> >>> 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 web2py+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- 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 web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
