#22105 closed Bug (invalid)
Model error messages overwritten by modelform django defaults
Reported by: | 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 , 11 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:2 by , 6 years ago
Thanks for reporting this bug. I have all my error_messages defined in my model, but the 'required' message got always overwritten.
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.