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

[cboos@…]

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

[cboos]

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.

[cboos]

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.

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

[rblank]

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.

[rblank]

Replying to dantudor:

Is this ticket in progress by anyone?

Not that I know of.

[cboos]

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.

[itamaro]

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

[shoffmann]

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.