Modify ↓
#12857 closed defect (fixed)
Normalize default value of checkbox custom field
| Reported by: | Jun Omae | Owned by: | Ryan J Ollos |
|---|---|---|---|
| Priority: | normal | Milestone: | 1.2.3 |
| Component: | ticket system | Version: | 1.0.15 |
| Severity: | normal | Keywords: | |
| Cc: | Branch: | ||
| Release Notes: | |||
| API Changes: |
Normalized value of custom field checkbox to |
||
| Internal Changes: | |||
Description (last modified by )
Creating new ticket with checkbox field which has 42 for default value via web ui, the field would have 1 or 0.
[ticket-custom] check = checkbox check.value = 42
sqlite> SELECT t.id, t.summary, c.value FROM ticket AS t LEFT JOIN ticket_custom AS c ON c.ticket=t.id AND c.name='check'; 1|Checked|1 2|Unchecked|0
However, the default value would be stored for the checkbox field via application code instead of 1|0.
$ ~/venv/trac/1.0.15/bin/python
Python 2.5.6 (r256:88840, Oct 21 2014, 22:49:55)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from trac.env import Environment
>>> env = Environment('/dev/shm/tracenv')
>>> from trac.ticket.model import Ticket
>>> ticket = Ticket(env)
>>> ticket['summary'] = 'via plugin'
>>> ticket.insert()
3
>>> for name in sorted(ticket.values): name, ticket[name]
...
('changetime', datetime.datetime(2017, 7, 6, 12, 42, 59, 479729, tzinfo=<FixedOffset "UTC" 0:00:00>))
(u'check', u'42') # <== neither 1 nor 0
('owner', '')
('priority', u'major')
('summary', 'via plugin')
('time', datetime.datetime(2017, 7, 6, 12, 42, 59, 479729, tzinfo=<FixedOffset "UTC" 0:00:00>))
('type', u'defect')
I consider we should normalize default value for checkbox custom fields to have 1|0.
Attachments (0)
Note:
See TracTickets
for help on using tickets.



Any value other than
1results in the checkbox defaulting to0: tags/trac-1.2.2/trac/ticket/templates/ticket.html@:267#L244.I considered using
as_int, but maybe better to useas_bool:trac/ticket/api.py
intThat would allow
checkbox.value = trueto be accepted. We don't need to document that as allowed, but it might be better fallback behavior.