Opened 10 years ago

Closed 10 years ago

Last modified 5 years ago

#22105 closed Bug (invalid)

Model error messages overwritten by modelform django defaults

Reported by: daniel@… Owned by: Dr_White
Component: Forms Version: dev
Severity: Normal Keywords: error_messages, model, error, form, _update_errors
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Imagine a model with custom error messages added to some of it's fields.

from django.db import models


class MyModel(models.Model):
    name = models.CharField(
        max_length=255,
        error_messages={
            'required': 'my required msg..',
        }
    )

When a modelform is created from this model

from django.forms import ModelForm
from .models import MyModel


class MyModelForm(ModelForm):

    class Meta:
        model = MyModel
        fields = ['name']

I would expect to see the custom error message.
Instead the function _update_errors from BaseModelForm simply doesn't care, I quote:

Override any validation error messages defined at the model level with those defined at the form level.

I believe any custom error message defined in the model should take precedence over the default form messages.
Whenever error messages also defined in the modelform meta like so:

class MyModelForm(ModelForm):

    class Meta:
        model = MyModel
        fields = ['name']
        error_messages = {
            'name': {
                'required': "This is a custom error message from modelform meta",
            },
        }

Then the error message from the modelform should be used.

Change History (2)

comment:1 by MikeA, 10 years ago

Resolution: invalid
Status: newclosed

This behaviour is deliberate.

MyModelForm's error messages are more specific than MyModel's, i.e. form error messages overriding behaviour gives us the way to customize a model's error messages.

This might make more sense when we note that multiple forms can be used with one Model subclass, but not really the other way around.

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