#37011: The presence of a non-readonly non-editable field in ModelAdmin fails at
runtime and has no system check
---------------------------------+-----------------------------------------
Reporter: Andrew Northall | Type: Bug
Status: new | Component: contrib.admin
Version: 6.0 | Severity: Normal
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+-----------------------------------------
In `ModelAdmin`, several field configuration errors (such as adding an
non-existent field to a `ModelAdmin` `fields` or `fieldsets` attribute)
are
[
https://github.com/django/django/blob/edd899786851f6285abbc3c272f4f5ec0e48a74c/django/contrib/admin/checks.py#L323
covered by system checks] in `contrib/admin/checks.py`. We also have a
system check for
[
https://github.com/django/django/blob/edd899786851f6285abbc3c272f4f5ec0e48a74c/django/contrib/admin/checks.py#L1172
non-editable fields in the list_editable attribute (E125)]. However, a
common runtime failure is that a model field which has `editable=False`
set in the model is either:
- added to a `ModelAdmin` which does not specify `fields` or `fieldsets`
attributes and does not include it in `readonly_fields` or `excludes`, or
- added to a `ModelAdmin` which specifies `fields` or `fieldsets`
attributes with this non-editable field included, but the field is omitted
from `readonly_fields`.
In simpler terms, any time a field which is non-editable on the model, and
not marked as read only appears in change form, this will result in the
following error when accessing the create or update views for this
`ModelAdmin`:
{{{
FieldError at /admin/app/modelname/add/
'fieldname' cannot be specified for ModelName model form as it is a non-
editable field. Check fields/fieldsets/exclude attributes of class
ImageTestAdmin.
}}}
It would make sense to me that, at a minimum, we should add a system check
for this error to bring the detection in line with other `ModelAdmin`
field configuration errors and avoid silent failures at runtime - or
perhaps there could be a discussion as to whether the default behaviour
could or should be to simply mark these fields as read only by default?
--
Ticket URL: <
https://code.djangoproject.com/ticket/37011>
Django <
https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.