Opened 20 years ago
Last modified 7 years ago
#918 new enhancement
[patch] Custom Ticket Fields should support the multiple selection type
Reported by: | Christian Boos | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | next-major-releases |
Component: | ticket system | Version: | devel |
Severity: | normal | Keywords: | patch ticket custom multi tracobject multiple_select multiple select css chosen |
Cc: | jevans591@…, itamarost@…, leho@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
I propose an addition to the TracTicketsCustomFields.
Currently, there is support for the simple selection field:
<field>.type = select
I would like to have the multi
type as well, for multiple selection fields.
The usage in trac.ini
for multi
would be the same as it is for select
.
I implemented it in a crude way (see the accompanying patch).
I'm not entirely pleased with the patch:
- the support for query is partial (i.e. it won't work)
- the display of the fields is not as neat as I would like
A better solution would involve a change in the database:
drop the unicity constraint on the (id,name)
pair for
the ticket_custom
table.
With that, the query support would be easier to add.
Attachments (1)
Change History (31)
by , 20 years ago
Attachment: | multi.1048.patch added |
---|
comment:1 by , 20 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
While the above patch and idea could be revived, I actually plan to support multiple selection in another way, in the context of the TracLightWeightObjectModel (in short: if a Wiki page is created from a Wiki template, it will have that template as a type associated to it, by the way of a is-a relationship)
Let's take the example of an Operating System field, because that's pretty common.
There would have to be a OperatingSystemTemplate wiki page template, and one would create as many wiki pages as one has operating systems to deal with…
The custom field operating_system would be defined as a relation field, of kind multi:
- the possible values will come from a relation
- the actually selected values will be stored in
another relation
[ticket-custom] operating_system = relation operating_system.label = Operating System(s) operating_system.kind = multiple operating_system.from = is-a OperatingSystemTemplate
For editing the field in ticket page, the multiple selection field will be filled with the name of all the existing pages which have been created with the OperatingSystemTemplate
The current values will be retrieved from the
has-operating-system
relation (the source being
the current ticket).
comment:2 by , 19 years ago
Severity: | normal → enhancement |
---|
comment:3 by , 19 years ago
Cc: | added |
---|
comment:6 by , 18 years ago
Cc: | removed |
---|
comment:7 by , 18 years ago
Owner: | changed from | to
---|---|
Status: | assigned → new |
comment:8 by , 18 years ago
Milestone: | → 1.0 |
---|
comment:9 by , 18 years ago
Keywords: | tracobject added |
---|---|
Severity: | enhancement → normal |
comment:10 by , 17 years ago
This enhancment will be very usefull.
The patch is very old, and cannot be applied to the 0.10.3 version
comment:11 by , 17 years ago
Owner: | changed from | to
---|
comment:12 by , 17 years ago
Keywords: | multiple_select multiple select added |
---|
Having multiple-select ticket fields would be very useful - when developing web apps it would be great if people can "Select all browsers having this problem" from the list.
comment:13 by , 17 years ago
Milestone: | 1.0 → 0.12 |
---|---|
Priority: | normal → high |
A better solution would involve a change in the database: drop the unicity constraint on the
(id,name)
pair for theticket_custom
table. With that, the query support would be easier to add.
… or add an occurrence number:
Table('ticket_custom', key=('ticket', 'name', 'occ'))[ Column('ticket', type='int'), Column('name'), Column('value'), Column('occ')]
For most fields, this would just be NULL, but for the multi
type, there would be a different number for each value.
comment:14 by , 16 years ago
Cc: | added |
---|
follow-up: 18 comment:15 by , 16 years ago
#8026 requested essentially the same thing, though suggesting a different user interface. I agree that for implementing the UI for multiple selection, it would be nicer to use multiple checkboxes instead of a multiple select field.
comment:16 by , 16 years ago
Owner: | changed from | to
---|
comment:18 by , 15 years ago
Replying to cboos:
#8026 requested essentially the same thing, though suggesting a different user interface. I agree that for implementing the UI for multiple selection, it would be nicer to use multiple checkboxes instead of a multiple select field.
We tried multiple check boxes for affected platforms but found they grew out of control over time. We'd like to be able to have a scrollable multi-select list box. Summaries and reports could show a delimited list of the selected items.
follow-up: 20 comment:19 by , 15 years ago
Is this ticket in progress by anyone? A multi-option select box would be great functionality for a custom field. I am happy to contribute to creating a patch that is applicable to the latest version of trac if anyone is available to document the necessary steps.
comment:20 by , 15 years ago
comment:21 by , 14 years ago
See related discussion in #9466, real multivalued support would make the is query behave unambiguously, as opposed to a contains query on a single field containing multiple space or comma separated values.
comment:22 by , 14 years ago
Cc: | added |
---|---|
Milestone: | next-major-0.1X → 0.12.2 |
comment:23 by , 14 years ago
Milestone: | 0.12.2 → next-major-0.1X |
---|
didn't mean to change the milestone…
comment:24 by , 13 years ago
As a hint: there also exists a patch on track-hacks.org that implements this: http://trac-hacks.org/wiki/MultiSelectCustomFieldsPatch
comment:25 by , 13 years ago
There is no normalization of multiple-values input for ticket keywords. This has been raised as a complaint in th#9692 against th:TagsPlugin, because it causes trouble for the use of keywords as tags. So this should be about multiple values in general, where it makes sense, not only for custom fields.
comment:27 by , 10 years ago
Cc: | added |
---|
And then there was still this one select box improvement ticket I didn't know about ;) thanks @rjollos
comment:28 by , 10 years ago
Owner: | removed |
---|
comment:29 by , 9 years ago
Reporter: | changed from | to
---|
comment:30 by , 9 years ago
Keywords: | patch added |
---|
comment:31 by , 7 years ago
Priority: | high → normal |
---|
The patch mentioned in comment:24 does not exist anymore and is superseded by th:MultiSelectFieldPlugin. Another alternative is th:TracMultiSelectBoxPlugin.
comment:32 by , 7 years ago
Keywords: | css chosen added |
---|
Replying to Christian Boos:
Think about using Chosen's multi-select for the UI.
#13019 uses chosen for single-select fields.
patch that does the proposed feature