Opened 14 years ago
Closed 7 years ago
#17210 closed Cleanup/optimization (fixed)
Make NullBooleanSelect for NullBooleanField pass true/false as a GET parameter
| Reported by: | Owned by: | Basil Dubyk | |
|---|---|---|---|
| Component: | Forms | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | yes |
Description
Currently, NullBooleanSelect uses form with the following parameters:
choices = ((u'1', ugettext('Unknown')), (u'2', ugettext('Yes')), (u'3', ugettext('No')))
which generates URLs like ?param=3 for Param: No selection and ?param=1 for Param: Unknown. This makes URLs pretty counter-intuitive for search forms. For example, imaging search for issues. If you need to find all closed issues, the URL will be ?closed=3, not ?closed=1 as you may assume for boolean field.
It will be more user-friendly to generate param=, param=true and param=false for boolean field URLs.
Change History (6)
comment:1 by , 14 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|---|
| Type: | Bug → Cleanup/optimization |
| Version: | 1.2 → SVN |
comment:2 by , 7 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:4 by , 7 years ago
| Patch needs improvement: | set |
|---|
comment:5 by , 7 years ago
| Patch needs improvement: | unset |
|---|
PR updated. Tim Graham many thanks for comments.
I'm accepting the idea on principle, but I'd like to see a thorough analysis of how much backwards-incompatibility this change introduces.