Opened 17 years ago
Last modified 21 months ago
#9388 new New feature
Made month and year selectable in admin calender widget.
| Reported by: | Fidel Ramos | Owned by: | ahmadkhalili |
|---|---|---|---|
| Component: | contrib.admin | Version: | dev |
| Severity: | Normal | Keywords: | admin calendar year previous next widget ui |
| Cc: | versae@…, danny.adair@…, idan@… | Triage Stage: | Accepted |
| Has patch: | yes | Needs documentation: | yes |
| Needs tests: | yes | Patch needs improvement: | yes |
| Easy pickings: | no | UI/UX: | yes |
Description
My colleague Javier de la Rosa has enhanced the calendar shown in admin's date fields to allow navigation through years, and not only through months. This requires changing calendar.js and DateTimeShortcuts.js.
We have chosen not to maintain backwards compatibility because this should be a feature in Django 1.1, but it's easy to do if required.
Javier de la Rosa will attach his patch later.
Attachments (5)
Change History (26)
by , 17 years ago
| Attachment: | year_navigation_in_calendar_r9232.diff added |
|---|
comment:1 by , 17 years ago
| Cc: | added; removed |
|---|---|
| Component: | Contrib apps → django.contrib.admin |
| Has patch: | set |
| Owner: | changed from to |
| Status: | new → assigned |
Patch added.
If backwards compatibility is required, I can send a new patch with the proposal, it's done but I chose not to include it.
comment:3 by , 17 years ago
| Triage Stage: | Unreviewed → Design decision needed |
|---|
by , 16 years ago
| Attachment: | 9833-r12089.diff added |
|---|
patch updated to apply cleanly to trunk as of r12089.
comment:4 by , 16 years ago
| Keywords: | admin calendar year previous next widget added |
|---|
Patch has been updated to current trunk status. Modified to keep current element class names for month navigation unmodified and add brand new "-year"-suffixed names for elements involved in year navigation. This is what interpret is what the OP was talking about when he said 'backward compatibility'.
(Wrong ticket number in patch file name is a typo.)
comment:7 by , 16 years ago
ramiro: I closed the tickets you referenced as related; that way, we can focus out attention of this ticket.
comment:8 by , 16 years ago
| Cc: | added |
|---|
comment:9 by , 15 years ago
| Severity: | → Normal |
|---|---|
| Type: | → New feature |
comment:10 by , 15 years ago
| Cc: | added |
|---|---|
| Easy pickings: | unset |
comment:11 by , 14 years ago
| Keywords: | ui added |
|---|
comment:12 by , 14 years ago
| UI/UX: | set |
|---|
comment:13 by , 14 years ago
I tried this patch on the latest trunk (had to do it manually as the directory structure has changed.) Nothing happened, the widget is unchanged.
comment:14 by , 13 years ago
| Triage Stage: | Design decision needed → Accepted |
|---|
This sounds useful, I don't know which design decision was expected.
comment:16 by , 4 years ago
| Owner: | removed |
|---|---|
| Status: | assigned → new |
comment:17 by , 4 years ago
| Needs documentation: | set |
|---|---|
| Needs tests: | set |
| Owner: | set to |
| Status: | new → assigned |
| Summary: | Year navigation in admin's date widgets' calendar → Made month and year selectable in admin calender widget. |
by , 22 months ago
| Attachment: | Screenshot from 2024-01-30 16-45-19.png added |
|---|
comment:18 by , 22 months ago
I just looked at this and the PR seemed to have gotten pretty far. Patch still works with the current main branch.
Now two years have passed and I'm not sure what was/is blocking this.
- needs tests? The PR includes the following tests (are more needed?):
- test_show_hide_month_picker_widgets
- test_month_picker_selected_class_and_input
- test_month_picker_prev_next_links
- test_show_hide_year_picker_widgets
- test_year_picker_selected_class_and_input
- needs documentation? The PR changed
docs/releases/4.1.txtto contain:Now admin calendar caption is selectable and opens monthlist and yearlist. now it's easy adding older dates like birthday via admin calendar widget
- I briefly checked the following docs and the calendar description seemed to be still in in sync with what the PR would introduce
- intro/tutorial02.txt
- ref/contrib/sitemaps.txt
- ref/models/fields.txt
- ref/settings.txt
- topics/forms/index.txt
- topics/forms/media.txt
- topics/i18n/timezones.txt
- I briefly checked the following docs and the calendar description seemed to be still in in sync with what the PR would introduce
- patch needs improvement? As far as I can tell from the PR, every request or recommendation was integrated?
- decision to use native datepicker instead is still pending?
- decision to use some other datepicker package instead is still pending?
- something else?
by , 22 months ago
| Attachment: | Screenshot from 2024-01-30 17-23-25.png added |
|---|
follow-up: 21 comment:20 by , 21 months ago
Yes, I would say a big problem here is that this builds upon a date picker widget which we already know has many accessibility flaws and needs a replacement (see Refs #29822 -- Improved date, time and datetime HTML inputs #15806). Personally I wouldn’t recommend working on that widget, but if others think incremental improvements are the path forward that’s a valid call too.
Aside from that – there is also one code review comment on the PR which the author has yet to address.
comment:21 by , 21 months ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Replying to Thibaud Colas:
Yes, I would say a big problem here is that this builds upon a date picker widget which we already know has many accessibility flaws and needs a replacement
Ok, that wasn't apparent to me. Thanks for the clarification.
comment:22 by , 21 months ago
| Resolution: | fixed |
|---|---|
| Status: | closed → new |
Closing as "wontfix" might be appropriate but nothing has been fixed as far as I see.

Patch for django trunk r9232