#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.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/0107019d3effbac0-8a959ddd-2e32-4cb0-bd17-9e03a956b0be-000000%40eu-central-1.amazonses.com.
