Opened 19 years ago

Closed 11 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 17 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 16 years ago.
some initial work
form-warnings.2.diff (12.2 KB ) - added by Alex Gaynor 16 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 11 years ago.

Download all attachments as: .zip

Change History (40)

comment:1 by Adrian Holovaty, 19 years ago

Component: Core frameworkValidators

comment:2 by Boffbowsh, 19 years ago

Cc: paul.bowsher@… added

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

comment:3 by mir@…, 18 years ago

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

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

comment:4 by Simon G. <dev@…>, 18 years ago

Triage Stage: UnreviewedDesign decision needed

comment:5 by Russell Keith-Magee, 17 years ago

Triage Stage: Design decision neededAccepted

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

comment:6 by anonymous, 17 years ago

Owner: changed from nobody to anonymous
Status: newassigned

comment:7 by jimmyj_in, 17 years ago

Owner: changed from anonymous to jimmyj_in
Status: assignednew

comment:8 by jimmyj_in, 17 years ago

Owner: changed from jimmyj_in to nobody

comment:9 by Collin Anderson, 17 years ago

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.

by Collin Anderson, 17 years ago

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

comment:10 by mrts, 16 years ago

milestone: post-1.0

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

comment:11 by anonymous, 16 years ago

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

comment:12 by Alex Gaynor, 16 years ago

Component: AuthenticationForms

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

by Alex Gaynor, 16 years ago

Attachment: form-warnings.diff added

some initial work

by Alex Gaynor, 16 years ago

Attachment: form-warnings.2.diff added

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

comment:13 by (none), 16 years ago

milestone: post-1.0

Milestone post-1.0 deleted

comment:14 by anonymous, 15 years ago

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

comment:15 by Paul McMillan, 15 years ago

Version: soc2009/admin-ui

Reverting what appears to be spam.

comment:16 by Miloslav Pojman, 14 years ago

Cc: miloslav.pojman@… added

comment:17 by dirleyrls, 14 years ago

Cc: dirleyrls added

comment:18 by Łukasz Rekucki, 14 years ago

Severity: normalNormal
Type: enhancementNew feature

comment:19 by Sebastian Goll, 13 years ago

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

comment:20 by anonymous, 13 years ago

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 by Thomas Güttler, 13 years ago

Cc: hv@… added

comment:22 by Béres Botond, 13 years ago

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 by adehnert, 12 years ago

Cc: adehnert added

comment:24 by Nick Sandford, 12 years ago

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

comment:25 by Nick Sandford, 12 years ago

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

comment:26 by Nick Sandford, 12 years ago

comment:27 by AnkitBagaria, 12 years ago

Owner: changed from nobody to AnkitBagaria
Status: newassigned

comment:28 by Collin Anderson, 12 years ago

Cc: cmawebsite@… removed

comment:29 by AnkitBagaria, 12 years ago

Owner: AnkitBagaria removed
Status: assignednew

by Jef Geskens, 11 years ago

Attachment: form-warnings.3.diff added

comment:30 by Jef Geskens, 11 years ago

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 by Jef Geskens, 11 years ago

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

comment:32 by Sébastien Leblanc, 11 years ago

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 by loic84, 11 years ago

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 by Aymeric Augustin, 11 years ago

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 by rtnpro, 11 years ago

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 by Marc Tamlyn, 11 years ago

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