Edgewall Software
Modify

Opened 14 years ago

Last modified 13 days 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@…
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@… 14 years ago.
patch that does the proposed feature

Download all attachments as: .zip

Change History (31)

Changed 14 years ago by cboos@…

Attachment: multi.1048.patch added

patch that does the proposed feature

comment:1 Changed 13 years ago by Christian Boos

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 Changed 13 years ago by vittorio

Severity: normalenhancement

comment:3 Changed 13 years ago by Gunnar Wagenknecht <gunnar@…>

Cc: gunnar@… added

comment:6 Changed 12 years ago by anonymous

Cc: gunnar@… removed

comment:7 Changed 12 years ago by Alec Thomas

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

comment:8 Changed 11 years ago by Christian Boos

Milestone: 1.0

comment:9 Changed 11 years ago by Christian Boos

Keywords: tracobject added
Severity: enhancementnormal

comment:10 Changed 11 years ago by squiles

This enhancment will be very usefull.

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

comment:11 Changed 11 years ago by Alec Thomas

Owner: changed from Alec Thomas to Eli Carter

comment:12 Changed 10 years ago by Peter

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 in reply to:  description Changed 10 years ago by Christian Boos

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 Changed 10 years ago by jevans <jevans591@…>

Cc: jevans591@… added

comment:15 Changed 9 years ago by 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.

comment:16 Changed 9 years ago by anonymous

Owner: changed from Eli Carter to aaaa

comment:17 Changed 9 years ago by Remy Blank

Owner: changed from aaaa to Eli Carter

Please stop that.

comment:18 in reply to:  15 Changed 9 years ago by 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.

comment:19 Changed 8 years ago by 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.

comment:20 in reply to:  19 Changed 8 years ago by Remy Blank

Replying to dantudor:

Is this ticket in progress by anyone?

Not that I know of.

comment:21 Changed 8 years ago by 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.

comment:22 Changed 8 years ago by Itamar Ostricher

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

comment:23 Changed 8 years ago by Itamar Ostricher

Milestone: 0.12.2next-major-0.1X

didn't mean to change the milestone…

comment:24 Changed 7 years ago by julrich

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

comment:25 Changed 6 years ago by 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.

comment:26 Changed 6 years ago by Christian Boos

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

comment:27 Changed 4 years ago by lkraav <leho@…>

Cc: leho@… added

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

comment:28 Changed 3 years ago by Ryan J Ollos

Owner: Eli Carter deleted

comment:29 Changed 3 years ago by Ryan J Ollos

Reporter: changed from cboos@… to Christian Boos

comment:30 Changed 2 years ago by figaro

Keywords: patch added

comment:31 Changed 2 weeks ago by figaro

Priority: highnormal

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

comment:32 in reply to:  26 Changed 13 days ago by anonymous

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.
as The resolution will be set.
The owner will be changed from (none) to anonymous.

Add Comment


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