Opened 6 years ago
Last modified 4 years 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 (14)
comment:1 Changed 6 years ago by
| Keywords: | blocker added |
|---|
comment:2 Changed 6 years ago by
| Keywords: | blocker removed |
|---|---|
| Triage Stage: | Unreviewed → Accepted |
comment:3 Changed 6 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 6 years ago by
| Attachment: | django-ticket-15611.diff added |
|---|
comment:4 Changed 6 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 6 years ago by
| Type: | → Bug |
|---|
comment:6 Changed 6 years ago by
| Severity: | → Normal |
|---|
comment:7 Changed 6 years ago by
| UI/UX: | set |
|---|
comment:8 Changed 6 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 5 years ago by
| Cc: | Jannis Leidel removed |
|---|---|
| Owner: | Jannis Leidel deleted |
comment:11 Changed 4 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 4 years ago by
| Has patch: | set |
|---|
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.