Opened 14 years ago
Closed 11 months ago
#15611 closed New feature (fixed)
Readonly fields not hidden during create
Reported by: | Noah Kantrowitz | Owned by: | |
---|---|---|---|
Component: | contrib.admin | Version: | 1.2 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
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 (16)
comment:1 by , 14 years ago
Keywords: | blocker added |
---|
comment:2 by , 14 years ago
Keywords: | blocker removed |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:3 by , 14 years ago
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.
by , 14 years ago
Attachment: | django-ticket-15611.diff added |
---|
comment:4 by , 14 years ago
Owner: | changed from | to
---|
Also available in git form at https://github.com/coderanger/django/commits/ticket-15611
comment:5 by , 14 years ago
Type: | → Bug |
---|
comment:6 by , 14 years ago
Severity: | → Normal |
---|
comment:7 by , 13 years ago
UI/UX: | set |
---|
comment:8 by , 13 years ago
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 by , 13 years ago
Cc: | removed |
---|---|
Owner: | removed |
comment:11 by , 12 years ago
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 by , 11 years ago
Has patch: | set |
---|
comment:14 by , 4 years ago
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
.
comment:15 by , 11 months ago
Has patch: | unset |
---|---|
Patch needs improvement: | unset |
Resolution: | → fixed |
Status: | new → closed |
Type: | Bug → New feature |
Customization options are now available, and they are better than hiding readonly fields all the time. Closing as "fixed".
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.