[patch] Custom Ticket Fields should support the multiple selection type

[Christian Boos]

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.

[cboos@…]

patch that does the proposed feature

[Christian Boos]

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).

[squiles]

This enhancment will be very usefull.

The patch is very old, and cannot be applied to the 0.10.3 version

[Peter]

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.

[Christian Boos]

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.

… 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.

[Christian Boos]

#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.

[Remy Blank]

Please stop that.

[jevans]

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.

[dantudor]

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.

[Remy Blank]

Replying to dantudor:

Is this ticket in progress by anyone?

Not that I know of.

[Christian Boos]

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.

[Itamar Ostricher]

didn't mean to change the milestone…

[julrich]

As a hint: there also exists a patch on track-hacks.org that implements this: ​http://trac-hacks.org/wiki/MultiSelectCustomFieldsPatch

[Steffen Hoffmann]

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.

[Christian Boos]

Think about using ​Chosen's multi-select for the UI.

[lkraav <leho@…>]

And then there was still this one select box improvement ticket I didn't know about ;) thanks @rjollos

[figaro]

The patch mentioned in comment:24 does not exist anymore and is superseded by ​th:MultiSelectFieldPlugin. Another alternative is ​th:TracMultiSelectBoxPlugin.

[anonymous]

Replying to Christian Boos:

Think about using ​Chosen's multi-select for the UI.

#13019 uses chosen for single-select fields.