Edgewall Software
Modify

Opened 15 years ago

Last modified 16 months 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:

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)

multi.1048.patch (5.5 KB ) - added by cboos@… 15 years ago.
patch that does the proposed feature

Download all attachments as: .zip

Change History (31)

by cboos@…, 15 years ago

Attachment: multi.1048.patch added

patch that does the proposed feature

comment:1 by Christian Boos, 14 years ago

Owner: changed from Jonas Borgström to Christian Boos
Status: newassigned

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 vittorio, 14 years ago

Severity: normalenhancement

comment:3 by Gunnar Wagenknecht <gunnar@…>, 14 years ago

Cc: gunnar@… added

comment:6 by anonymous, 13 years ago

Cc: gunnar@… removed

comment:7 by Alec Thomas, 13 years ago

Owner: changed from Christian Boos to Alec Thomas
Status: assignednew

comment:8 by Christian Boos, 13 years ago

Milestone: 1.0

comment:9 by Christian Boos, 13 years ago

Keywords: tracobject added
Severity: enhancementnormal

comment:10 by squiles, 12 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 Alec Thomas, 12 years ago

Owner: changed from Alec Thomas to Eli Carter

comment:12 by Peter, 11 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.

in reply to:  description comment:13 by Christian Boos, 11 years ago

Milestone: 1.00.12
Priority: normalhigh

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.

comment:14 by jevans <jevans591@…>, 11 years ago

Cc: jevans591@… added

comment:15 by Christian Boos, 11 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 anonymous, 10 years ago

Owner: changed from Eli Carter to aaaa

comment:17 by Remy Blank, 10 years ago

Owner: changed from aaaa to Eli Carter

Please stop that.

in reply to:  15 comment:18 by jevans, 10 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.

comment:19 by dantudor, 10 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.

in reply to:  19 comment:20 by Remy Blank, 10 years ago

Replying to dantudor:

Is this ticket in progress by anyone?

Not that I know of.

comment:21 by Christian Boos, 9 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 Itamar Ostricher, 9 years ago

Cc: itamarost@… added
Milestone: next-major-0.1X0.12.2

comment:23 by Itamar Ostricher, 9 years ago

Milestone: 0.12.2next-major-0.1X

didn't mean to change the milestone…

comment:24 by julrich, 8 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 Steffen Hoffmann, 8 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:26 by Christian Boos, 7 years ago

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

comment:27 by lkraav <leho@…>, 5 years ago

Cc: leho@… added

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

comment:28 by Ryan J Ollos, 4 years ago

Owner: Eli Carter removed

comment:29 by Ryan J Ollos, 4 years ago

Reporter: changed from cboos@… to Christian Boos

comment:30 by figaro, 4 years ago

Keywords: patch added

comment:31 by figaro, 16 months ago

Priority: highnormal

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

in reply to:  26 comment:32 by anonymous, 16 months 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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned. Next status will be 'new'.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.