Opened 10 years ago

Closed 17 months ago

#23 closed New feature (wontfix)

Add support for ValidationWarning

Reported by: adrian Owned by: jgeskens
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 CollinAnderson 7 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 6 years ago.
some initial work
form-warnings.2.diff (12.2 KB) - added by Alex 6 years ago.
removed the nasty warning system, instead pass a callable to the clean functions
form-warnings.3.diff (14.6 KB) - added by jgeskens 22 months ago.

Download all attachments as: .zip

Change History (40)

comment:1 Changed 10 years ago by adrian

  • Component changed from Core framework to Validators

comment:2 Changed 9 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 9 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 8 years ago by Simon G. <dev@…>

  • Triage Stage changed from Unreviewed to Design decision needed

comment:5 Changed 7 years ago by russellm

  • Triage Stage changed from Design decision needed to Accepted

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

comment:6 Changed 7 years ago by anonymous

  • Owner changed from nobody to anonymous
  • Status changed from new to assigned

comment:7 Changed 7 years ago by jimmyj_in

  • Owner changed from anonymous to jimmyj_in
  • Status changed from assigned to new

comment:8 Changed 7 years ago by jimmyj_in

  • Owner changed from jimmyj_in to nobody

comment:9 Changed 7 years ago by CollinAnderson

  • Cc cmawebsite@… added
  • Component changed from Validators to django.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 7 years ago by CollinAnderson

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

comment:10 Changed 7 years ago by mrts

  • milestone set to post-1.0

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

comment:11 Changed 6 years ago by anonymous

  • Component changed from Forms to Authentication
  • Needs documentation set
  • Needs tests set
  • Version set to 1.0-alpha-2

comment:12 Changed 6 years ago by Alex

  • Component changed from Authentication to Forms

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

Changed 6 years ago by Alex

some initial work

Changed 6 years ago by Alex

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

comment:13 Changed 6 years ago by anonymous

  • milestone post-1.0 deleted

Milestone post-1.0 deleted

comment:14 Changed 5 years ago by anonymous

  • Version changed from 1.0-alpha-2 to soc2009/admin-ui

comment:15 Changed 5 years ago by PaulM

  • Version soc2009/admin-ui deleted

Reverting what appears to be spam.

comment:16 Changed 4 years ago by mila

  • Cc miloslav.pojman@… added

comment:17 Changed 4 years ago by dirleyrls

  • Cc dirleyrls added

comment:18 Changed 4 years ago by lrekucki

  • Severity changed from normal to Normal
  • Type changed from enhancement to New feature

comment:19 Changed 3 years ago by sebastian

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

comment:20 Changed 3 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 3 years ago by guettli

  • Cc hv@… added

comment:22 Changed 3 years ago by bberes

  • 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 2 years ago by adehnert

  • Cc adehnert added

comment:24 Changed 2 years ago by slurms

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:25 Changed 2 years ago by slurms

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

comment:26 Changed 2 years ago by slurms

comment:27 Changed 2 years ago by AnkitBagaria

  • Owner changed from nobody to AnkitBagaria
  • Status changed from new to assigned

comment:28 Changed 2 years ago by CollinAnderson

  • Cc cmawebsite@… removed

comment:29 Changed 2 years ago by AnkitBagaria

  • Owner AnkitBagaria deleted
  • Status changed from assigned to new

Changed 22 months ago by jgeskens

comment:30 Changed 22 months ago by jgeskens

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 22 months ago by jgeskens

  • Needs documentation set
  • Owner set to jgeskens
  • Patch needs improvement set
  • Status changed from new to assigned
  • UI/UX set

comment:32 Changed 19 months ago by sebleblanc

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 19 months 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 19 months ago by aaugustin

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 17 months 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 17 months ago by mjtamlyn

  • Resolution set to wontfix
  • Status changed from assigned to closed

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