Opened 11 years ago

Closed 3 years ago

#23 closed New feature (wontfix)

Add support for ValidationWarning

Reported by: Adrian Holovaty Owned by: Jef Geskens
Component: Forms Version:
Severity: Normal Keywords:
Cc: paul.bowsher@…, mir@…, miloslav.pojman@…, dirleyrls, sebastian.goll@…, hv@…, botondus@…, adehnert, loic@…, rtnpro Triage Stage: Accepted
Has patch: yes Needs documentation: yes
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: yes

Description

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.

Attachments (4)

warnings_as_list_partial.patch (2.5 KB) - added by Collin Anderson 9 years ago.
Patch against [6992] that has a partial implemtation of keeping track of Warnings as a list
form-warnings.diff (13.1 KB) - added by Alex Gaynor 8 years ago.
some initial work
form-warnings.2.diff (12.2 KB) - added by Alex Gaynor 8 years ago.
removed the nasty warning system, instead pass a callable to the clean functions
form-warnings.3.diff (14.6 KB) - added by Jef Geskens 3 years ago.

Download all attachments as: .zip

Change History (40)

comment:1 Changed 11 years ago by Adrian Holovaty

Component: Core frameworkValidators

comment:2 Changed 11 years ago by Boffbowsh

Cc: paul.bowsher@… added

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

comment:3 Changed 10 years ago by mir@…

Cc: paul.bowsher@… mir@… added; paul.bowsher@… removed

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

comment:4 Changed 10 years ago by Simon G. <dev@…>

Triage Stage: UnreviewedDesign decision needed

comment:5 Changed 9 years ago by Russell Keith-Magee

Triage Stage: Design decision neededAccepted

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

comment:6 Changed 9 years ago by anonymous

Owner: changed from nobody to anonymous
Status: newassigned

comment:7 Changed 9 years ago by jimmyj_in

Owner: changed from anonymous to jimmyj_in
Status: assignednew

comment:8 Changed 9 years ago by jimmyj_in

Owner: changed from jimmyj_in to nobody

comment:9 Changed 9 years ago by Collin Anderson

Cc: cmawebsite@… added
Component: Validatorsdjango.newforms
Has patch: set
Patch needs improvement: set

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.

Changed 9 years ago by Collin Anderson

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

comment:10 Changed 8 years ago by mrts

milestone: post-1.0

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

comment:11 Changed 8 years ago by anonymous

Component: FormsAuthentication
Needs documentation: set
Needs tests: set
Version: 1.0-alpha-2

comment:12 Changed 8 years ago by Alex Gaynor

Component: AuthenticationForms

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

Changed 8 years ago by Alex Gaynor

Attachment: form-warnings.diff added

some initial work

Changed 8 years ago by Alex Gaynor

Attachment: form-warnings.2.diff added

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

comment:13 Changed 8 years ago by (none)

milestone: post-1.0

Milestone post-1.0 deleted

comment:14 Changed 7 years ago by anonymous

Version: 1.0-alpha-2soc2009/admin-ui

comment:15 Changed 7 years ago by Paul McMillan

Version: soc2009/admin-ui

Reverting what appears to be spam.

comment:16 Changed 6 years ago by Miloslav Pojman

Cc: miloslav.pojman@… added

comment:17 Changed 6 years ago by dirleyrls

Cc: dirleyrls added

comment:18 Changed 5 years ago by Łukasz Rekucki

Severity: normalNormal
Type: enhancementNew feature

comment:19 Changed 5 years ago by Sebastian Goll

Cc: sebastian.goll@… added
Easy pickings: unset
UI/UX: unset

comment:20 Changed 5 years ago by 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.

comment:21 Changed 5 years ago by Thomas Güttler

Cc: hv@… added

comment:22 Changed 5 years ago by Béres Botond

Cc: botondus@… added

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

comment:23 Changed 4 years ago by adehnert

Cc: adehnert added

comment:24 Changed 4 years ago by Nick Sandford

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset

comment:25 Changed 4 years ago by Nick Sandford

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

comment:26 Changed 4 years ago by Nick Sandford

comment:27 Changed 4 years ago by AnkitBagaria

Owner: changed from nobody to AnkitBagaria
Status: newassigned

comment:28 Changed 4 years ago by Collin Anderson

Cc: cmawebsite@… removed

comment:29 Changed 4 years ago by AnkitBagaria

Owner: AnkitBagaria deleted
Status: assignednew

Changed 3 years ago by Jef Geskens

Attachment: form-warnings.3.diff added

comment:30 Changed 3 years ago by 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?

comment:31 Changed 3 years ago by Jef Geskens

Needs documentation: set
Owner: set to Jef Geskens
Patch needs improvement: set
Status: newassigned
UI/UX: set

comment:32 Changed 3 years ago by 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.

comment:33 Changed 3 years ago by loic84

Cc: loic@… added

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().

comment:34 Changed 3 years ago by 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?

comment:35 Changed 3 years ago by rtnpro

Cc: rtnpro added

@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.

comment:36 Changed 3 years ago by Marc Tamlyn

Resolution: wontfix
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.
Back to Top