Opened 10 years ago
Last modified 7 weeks ago
#15611 new Bug
Readonly fields not hidden during create
Reported by: | coderanger | Owned by: | |
---|---|---|---|
Component: | contrib.admin | Version: | 1.2 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | yes |
Description
A field marked as readonly should be hidden when creating a new object from the admin.
Attachments (1)
Change History (15)
comment:1 Changed 10 years ago by
Keywords: | blocker added |
---|
comment:2 Changed 10 years ago by
Keywords: | blocker removed |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:3 Changed 10 years ago by
The flag was set on the request of Jannis ;-) The fix is done, going to make some tests tomorrow when I get down to the sprints.
Changed 10 years ago by
Attachment: | django-ticket-15611.diff added |
---|
comment:4 Changed 10 years ago by
Owner: | changed from coderanger to Jannis Leidel |
---|
Also available in git form at https://github.com/coderanger/django/commits/ticket-15611
comment:5 Changed 10 years ago by
Type: | → Bug |
---|
comment:6 Changed 10 years ago by
Severity: | → Normal |
---|
comment:7 Changed 10 years ago by
UI/UX: | set |
---|
comment:8 Changed 10 years ago by
Easy pickings: | unset |
---|---|
Triage Stage: | Accepted → Design decision needed |
I'm not convinced that read-only fields should systematically and implicitly be hidden (or omitted) from the add form as, for example, one may want to display read-only default values. Instead I would prefer to let the admin offer more flexibility so that one could explicitly control what fields are displayed in the add/change forms on a per-request basis. For this reason I'm marking this ticket as DDN.
comment:10 Changed 9 years ago by
Cc: | Jannis Leidel removed |
---|---|
Owner: | Jannis Leidel deleted |
comment:11 Changed 8 years ago by
Triage Stage: | Design decision needed → Accepted |
---|
The option to offer "more flexibility" didn't apper, and it doesn't look like it will be implemented any time soon. Can we proceed with the bugfix?
comment:12 Changed 8 years ago by
Has patch: | set |
---|
comment:14 Changed 7 weeks ago by
I think this can be closed now. We have get_readonly_fields
, and get_fields
both of which accept an obj
argument which will be None
in the case of an add_view
. This allows you to completely customise what fields you want to be readonly (or even present) for both add_view
and change_view
.
FYI: blocker doesn't mean "this is annoying and I want someone to fix it". It means "this is a problem so serious that we need to hold back the release".
This *certainly* isn't a blocker. It doesn't cause data loss. It doesn't cause crashes. It isn't a regression in behavior since the last release, and it isn't a bug in a new feature. It is, at best, an mild annoyance.