Opened 14 years ago
Closed 12 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 , 14 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 , 12 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 , 12 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.