Add support for ValidationWarning

[Adrian Holovaty]

We've talked in the past about how useful it would be to let certain validators throw ValidationWarning instead of ValidationError. A ValidationWarning, when thrown, would still redisplay the admin form but display an additional checkbox above the field. If that checkbox is checked when the form is submitted, the error is ignored.

The change would have to be made in django/core/formfields.py.

[Boffbowsh]

I'll be needing this soon, so I'll try and get something up together

[mir@…]

This would then be limited to admin forms, do I understand this correctly?

[Russell Keith-Magee]

Safe to assume that if Adrian proposed the idea, it has been accepted.

[Collin Anderson]

It seems to me that these ValidationWarnings could not be regular Python exceptions. Python exceptions will stop running the validation code after a ValidationWarning is thrown, so there could be a ValidationError that would be thrown later, but instead it would appear that the field only has a warning and no errors. Instead I propose that, if we still want this feature, we use a list of warnings instead.

Is it safe to assume this applies to newforms, and not the database validation?

I have a partial implementation of this in newforms.

[Collin Anderson]

Patch against [6992] that has a partial implemtation of keeping track of Warnings as a list

[mrts]

Marking as post-1.0 as this is not essential for 1.0.

[Alex Gaynor]

I've begun work on this, you can follow it here: ​http://github.com/alex/django/tree/local/validation-warning

[Alex Gaynor]

some initial work

[Alex Gaynor]

removed the nasty warning system, instead pass a callable to the clean functions

[(none)]

Milestone post-1.0 deleted

[Paul McMillan]

Reverting what appears to be spam.

[anonymous]

I was just day dreaming about this feature today, wondering if it existed. Just to voice another use case, I'm building a search system where a fair amount of input validation needs to be done, but when validation fails, I want to make a best effort to process the user's input and give them results (along with perhaps a message about their input: "Such and such field had an error and was ignored"). Currently, I don't think there's an easy way to do this. Would love to see built in support.

[Béres Botond]

This would certainly be a quite useful feature to have. I've worked with a custom implementation of this in a project and it was certainly very nice for some complex forms/workflows

[Nick Sandford]

updated patch to work on current code, all tests pass.

[Nick Sandford]

opened a pull request: ​https://github.com/django/django/pull/629

[Jef Geskens]

​https://github.com/django/django/pull/1123

Improved pull request from slurms. It will merge again. It still needs updated documentaton though... anyone wanting to help on that one?

[Sébastien Leblanc]

I do not think that such a feature is useful, as it can easily be implemented using standard Django machinery.

Here is an example, supposing that I am writing a user register form, where the date of birth is optional, but I want to warn the user that they would miss on some functionality on my site:

Full name
Date of birth

<hidden "Ignore warning" boolean field (default: False)>

Email
Password

Let us say the user fills all the form but the DOB field. In my form validation, I raise "ValidationError" if the DOB field is empty, and when the form is returned to the user, I display the hidden field, along with an explanation, so that the user may dismiss the warning. If the form is validated again, and the date of birth is still missing, but the checkbox is True, I then accept the form as submitted.

I think this construct can easily be wrapped in a form field mixin. The only use for a ValidationWarning exception (derived from ValidationError) is to make it easier on the form display to determine if the checkbox should be shown. However, I think that they should be handled as regular error.

i.e. (e.g) This form is only valid if field foo does not contain Unicode characters, or if foo does contains Unicode and that field foo_ignore_unicode_warning is True.

If it had to be implemented, I think that having <field>_<reason>_warning methods would work great.

[loic84]

I'm actually pretty worried about this ticket.

I've been making a lot of changes to the form error reporting (#20199, #16986, #20867, #17413) so that errors could be overridden and so they retain meaning (metadata like error code or error params) until the very last minute (rendering). All the patches in this ticket suffer from the same problem as the old error reporting, we just accumulate a blob of meaningless text (for the system) that we can only display, therefore I see them as another step in the wrong direction.

Then comes the question, why just warnings? What about informational messages or success messages for each field? Lot of modern websites that have forms operated by AJAX will give this kind of feedback. We have very good validation machinery; it wouldn't be difficult to integrate these.

We almost have form.errors.as_json() with all the metadata with #17413, I’d love to have a more generic form.validation.as_json().

[Aymeric Augustin]

This ticket has rotten here for eight years; it may be time to close it.

If someone wants to do something, starting from a clean slate and extracting just the relevant bits from this tickets is likely to give better results.

Any objections to closing it as wontfix?

[rtnpro]

@aaugustin Sounds like a plan. I am researching on this issue and I will create a new ticket based on the current code and the things discussed in this thread and start fresh.

[Marc Tamlyn]

I agree with Aymeric. Also the changes as discussed by Loic which are in progress will make it easier to do certain things. It is possible to achieve this kind of functionality already with a customised form. Once the other form validation related changes are there we will be able to come up with a much more concrete proposal for an easy way to do this.