Opened 4 years ago

Closed 12 months ago

#15069 closed New feature (fixed)

ValidationError message isn't helpful in tracking down the field that fails validation

Reported by: Steve Steiner <ssteinerX@…> Owned by: anubhav9042
Component: Forms Version: master
Severity: Normal Keywords: ValidationError, exception, error message
Cc: anubhav9042@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

raise exceptions.ValidationError(self.error_messagesinvalid?)
[Wed Jan 12 21:59:58 2011] [error] [client 10.177.133.202] ValidationError: [u'Enter a valid date/time in YYYY-MM-DD HH:MM[:ss[.uuuuuu]] format.']

If the error message contained the invalid data, and, especially the name of the field that was being validated, that would be way more helpful.

I'm going to go look for this in the source, but someone more familiar with this piece of code could probably make this change in pretty short order.

Change History (13)

comment:1 Changed 4 years ago by Steve Steiner <ssteinerX@…>

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

Sorry, the error is in:

File "/xxxxxxxxxxxxxxxxxxx/django/db/models/fields/init.py", line 710, in to_python

comment:2 Changed 4 years ago by russellm

  • Component changed from Core framework to Forms
  • milestone 1.3 deleted
  • Triage Stage changed from Unreviewed to Accepted

A reasonable suggestion; not for 1.3, however, because we have hit feature freeze, and this would be a new feature.

Out of interest, the BaseValidator (on which the min/max value validators is based) already does this; but the min/max validation strings don't exploit the capability.

comment:3 Changed 4 years ago by anonymous

  • Severity set to Normal
  • Type set to New feature

comment:4 Changed 3 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:5 Changed 3 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:6 Changed 14 months ago by anubhav9042

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

comment:7 Changed 13 months ago by anubhav9042

Any design decision for this??

comment:8 Changed 12 months ago by anubhav9042

  • Cc anubhav9042@… added
  • Version changed from 1.2 to master

I have looked into this and there are some changes from when the ticket was filed.

In DateTimeField in db/models/fields/__init__.py

default_error_messages = {
        'invalid': _("'%(value)s' value has an invalid format. It must be in "
                     "YYYY-MM-DD HH:MM[:ss[.uuuuuu]][TZ] format."),
        'invalid_date': _("'%(value)s' value has the correct format "
                          "(YYYY-MM-DD) but it is an invalid date."),
        'invalid_datetime': _("'%(value)s' value has the correct format "
                              "(YYYY-MM-DD HH:MM[:ss[.uuuuuu]][TZ]) "
                              "but it is an invalid date/time."),
    }

But in DateTimeField in django/forms/fields.py

default_error_messages = {
        'invalid': _('Enter a valid date/time.'),
    }

There have been a lot of changes in the source code from the time it was filed. So it seems that this is changed in db/models/fields/__init__.py which is the place where Steve mentions he found the problem.
But the component in the the ticket says Forms, in which the problem still exists as the errors from the forms still are not at all good if they just say Enter a valid date/time. I am not sure that how the forms got there errors earlier, probably from models itself, but atleast now it is not.

  • In many of the form fields, the error messages are much better and self-explanatory but the above and in many places like DateField, TimeField, DateTimeField, URLField and maybe some more, I think we can make those better just like in the db/models/fields/__init__.py.
  • I think we should make default_error_messages in forms and models similar. In models, every error message contains the faulty value but in forms, it does not.

So what I think that atleast we should improve errors in the form fields that I listed out above and other similar ones and also we can decide on the second point, i.e. whether we should pass the value onto the errors in the all form errors as is done in few so as to make it similar to that in models.

Version 0, edited 12 months ago by anubhav9042 (next)

comment:9 Changed 12 months ago by claudep

As for forms, I don't think we should change the error messages, as the field values and names are often obvious when the form is redisplayed with errors.

It would be nice if we could narrow the use cases targeted by this ticket (which is not forms IMHO).

comment:10 Changed 12 months ago by anubhav9042

The error messages in forms.fields in Date and Time related field do not even mention what is the correct format.
Probably the errors earlier were gathered from models.fields, but now if date is wrong, we get only 'Enter a valid date/time.'

I think we should atleast update those messages to the previous state where they tell what is the correct format, i.e. specifying YYYY-MM-DD HH:MM[:ss[.uuuuuu]] for DateTimeField and other related or similar ones or else if someone enters wrong in forms, we only get: Enter valid date/time.

comment:11 Changed 12 months ago by claudep

Maybe, but then please open a new ticket to not mix issues.

comment:12 Changed 12 months ago by anubhav9042

IMO, I think what was asked by Steve, i.e. to include name is no more required as default_error_messages in db/models/field/__init__.py have changed and they are good.

Though the new form errors now are even less better than previous ones mostly in date/time or url fields. So I think we should close this ticket and open a new one for the improvements in those messages with what I suggested.
If we agree to this, then I would request one of the admins to close this so I'll open a new one with the suggested.
Thanks.

comment:13 Changed 12 months ago by timo

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

I agree the original issue appears to be fixed.

Regarding forms, I think it's better if the developer includes help_text or a custom error message if they wants to include the accepted formats. Field.input_formats is something like [u'%Y-%m-%d', u'%m/%d/%Y', u'%m/%d/%y'] which most end users won't know how to interpret.

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