Edgewall Software
Modify

Opened 14 years ago

Last modified 2 years ago

#2464 new enhancement

Conditional fields in tickets

Reported by: johan.regnell@… Owned by:
Priority: normal Milestone: next-major-releases
Component: ticket system Version: 0.9.2
Severity: major Keywords: tracobject tickettype conditional custom field
Cc: hw@…, erikand@…, sam@…, mark.dodgson@…, dartar@…, ryan@…, hans.westerveen@…, colin.white@…, mmitar@…, itamarost@…, admiralnemo@…, sam.halliday@…, martin.wagner@…, Ryan J Ollos, leho@… Branch:
Release Notes:
API Changes:

Description (last modified by martin.wagner@…)

Not necessarily all possible fields should be presented to the user. There could be preconditions attached to fields, for checking if they're applicable at all and for checking if the current user can actually set/modify them.

Then, as an advanced case, instead of being an all or nothing situation, the possible content of one field could be dependent on the ticket state: see #1299, #2752 and #comment:13.

Use cases

Ability to have different ticket fields for different ticket types

(original one) When using quite different types of tickets (bug-report, requirement, etc), there is a need for different fields depending on the ticket type. This might add just the flexibility required for complying with existing development processes. Great feature in particular when support for master and child tickets is planned, trac could be more of a requirements management system beyond the issue database approach. See also duplicates: #4028, #4643

Abilty to have different ticket fields for different ticket components

As for ticket types, but for components. See #2752

Hide the Keywords: field

See #3281

Hide some fields for new tickets

See #1580. This could be achieved quite simply by putting the ticket id in the condition.

Attachments (0)

Change History (56)

comment:1 by Christian Boos, 14 years ago

Keywords: tracobject tickettype added
Owner: changed from Jonas Borgström to Christian Boos

Yes, that was one of the early request concerning the TicketTypes feature. Having more flexibility for the ticket properties would be nice.

There's still the open question of the UI, though: As you have to select the type of a ticket, you don't know beforehand which type specific fields you'd need.

One solution to this would be to have only the "common" fields at ticket creation type, and the "type specific" ones when editing the ticket.

Same problem when changing the ticket type, how to handle the type specific fields? Maybe when the type changes, only take into account the type change itself, possibly some changes for the common fields, and ignore any type specific field change. The type specific fields of the new type will be available for a second round of edit, after the type change has occurred.

comment:2 by pkou at ua.fm, 14 years ago

First of all, I would propose to allow the "type specific" fields for custom fields only. The suggestion is to show/hide "type specific" fields using JavaScript:

  • By default, all fields are shown;
  • When the page has loaded, fields for non-default type are hidden;
  • When the ticket type is changed, fields for non-selected type are

hidden, fields for the selected type are shown. This would cause layout problems that can be resolved in one of the following ways:

  • Apply new layout to the "type specific" fields when they are shown or

hidden;

  • Consider "type specific" fields as groups of fields. Layout groups

separately. Show active groups and hide other groups when the ticket type is changed. The approach could work for browsers that do not support JavaScript. I do not think that changing a field that does not belong to currently selected type is an issue.

comment:3 by anonymous, 14 years ago

Cc: shishz@… added

comment:4 by Christian Boos, 13 years ago

Milestone: 1.0

#4028 marked as duplicate.

I'll soon attach here a patch going in that direction.

comment:5 by anonymous, 13 years ago

Cc: mr@… added

comment:6 by anonymous, 13 years ago

Cc: hw@… added; shishz@… mr@… removed

comment:7 by anonymous, 13 years ago

#4643 marked as duplicate.

comment:8 by anonymous, 13 years ago

Cc: erikand@… added

I want to listen in on this..

comment:9 by Christian Boos, 13 years ago

Keywords: conditional custom field added

I just closed #2752 as duplicate. That ticket was not about the type field, but about the component, but I think a generic solution could be worked out (see last comment on that ticket).

comment:10 by Christian Boos, 13 years ago

Description: modified (diff)
Summary: Ability to have different ticket fields for different ticket typesOptional fields in tickets

comment:11 by Christian Boos, 13 years ago

Summary: Optional fields in ticketsConditional fields in tickets

comment:12 by Christian Boos, 13 years ago

#1299 would be an other use case, slightly extended: instead of an all or nothing approach (the field is present or missing), its content could depend on other fields (in this case, the list of available components would depend on the selected milestone).

comment:13 by sam@…, 13 years ago

Cc: sam@… added

I'm keen to get this feature implemented, and I'm starting to learn enough about Trac and Python to get it implemented. I'm keen to get feedback on this to increase the chance of a patch being accepted into the trunk.

Some requirements:

  • The ability to filter out fields based on ticket data: component, milestone, ticket type, component.
  • The ability filter out fields based on user permissions.
  • The ability to filter out standard, as well as custom, fields. For some tickets you don't want a description field, just the 1-line summary.

Configuration file:

  • Add [ticket-standard] as a complement to [ticket-custom], for manipulating built-in ticket fields.
  • (field-name).conditions will set up conditional restrictions
    • (field-name).conditions.(conditional-field) can be a | separated list in one of two formats
    • A|B|C - means only show this field when conditional-field is set to A, B or C
    • !A|B|C - means only show this field when conditional-field is not set to A, B or C
  • (field-name).conditions.permission operates similarly on the permissions that the current user has.

Example configuration:

[ticket-standard]
description.conditions.type = !storycard
owner.condition.permission = TICKET_FULLACCESS

[ticket-custom]
installation = select
installation.label = Select the affected installation
installation.condition.component = Frontend|Webservice
installation.condition.milestone = !alpha1|alpha2

Suggested implementation:

  • Whenever the ticket-details form is displayed, use the current, default, and get/post data to determine which fields to show.
  • Work out which fields are going to be linked to conditions. In the case above, this will be type, component, and milestone.
  • Add an onchange javascript-refresh that reloads the page, with all current field values loaded into the querystring.
  • Using ajax would be an optional enhancement

comment:14 by Christian Boos, 13 years ago

Description: modified (diff)

comment:15 by anonymous, 13 years ago

Cc: grhm.smith@… added

comment:16 by Christian Boos, 12 years ago

Description: modified (diff)

Make it clearer that this ticket is also for conditional content of the fields.

comment:17 by anonymous, 12 years ago

Cc: mark.dodgson@… added

I have a real interest in this type of system being implemented. I am new to Trac so still a little unfamiliar with how the example shown would work. I just thought I would throw in how I would like this type of system to work with a real example.

Our company is a design house that builds the product from start to finish mouldings, electronics, hardware etc. Using the Trac system I brake down each of these items into components. The current missing part for Trac is that each of these components have differing version numbers.

This approach would fit our scenario perfectly.

I look forward to seeing this as a release some time

comment:18 by anonymous, 12 years ago

Cc: dilshod@… added

comment:19 by anonymous, 12 years ago

Cc: oan@… added

This would be extremely helpful! Has any work been done on it?

comment:20 by Noah Kantrowitz, 12 years ago

CondFields on trac-hacks implements this mostly.

comment:21 by anonymous, 12 years ago

Anyone knows how CondFields works/will work with 0.11?

in reply to:  20 comment:22 by anonymous, 12 years ago

Replying to nkantrowitz:

CondFields on trac-hacks implements this mostly.

http://trac-hacks.swapoff.org/wiki/CondFieldsPlugin

comment:23 by dartar, 12 years ago

Cc: dartar@… added

+1 for this feature, we'd need custom fields dependent on ticket type.

The CondFields plugin page is down at the moment.

comment:24 by anonymous, 12 years ago

Cc: dilshod@… removed

comment:25 by Christian Boos, 12 years ago

#6661 was closed as duplicate.

comment:26 by anonymous, 12 years ago

Cc: andrew@… added

comment:27 by marcus@…, 11 years ago

+1 for this, would be very useful! (or the simple version +1580)

comment:28 by Ryan Witt <ryan@…>, 11 years ago

Cc: ryan@… added

+1, but maybe I will take a crack at porting http://trac-hacks.swapoff.org/wiki/CondFieldsPlugin to 0.11 for the time being!

comment:29 by hans.westerveen@…, 11 years ago

Cc: hans.westerveen@… added

comment:30 by anonymous, 11 years ago

Cc: colin.white@… added

comment:31 by chris.bennell@…, 10 years ago

Cc: chris.bennell@… added

comment:32 by Christian Boos, 10 years ago

Milestone: 1.0unscheduled

Milestone 1.0 deleted

comment:33 by Remy Blank, 10 years ago

#9289 was closed as a duplicate.

comment:34 by Mitar, 10 years ago

Cc: mmitar@… added

There is another use case. We would like to add contact data for our users/customers which should be seen only for users with right permissions. All other things should be left public. So we would like to have a field which is only visible/editable to those users with a permission.

comment:35 by Mitar, 10 years ago

And of course it should be made secure. Not just hiding it with JavaScript but hiding it everywhere (ticket view, RSS, alternative views, ticket notifications, ticket queries, ticket search…).

comment:36 by Arthaey <arthaey@…>, 10 years ago

CondFieldsPlugin is available here instead of swapoff.org: http://trac-hacks.org/wiki/CondFieldsPlugin

comment:37 by Christian Boos, 9 years ago

Milestone: triagingnext-major-0.1X
Severity: normalmajor

#9475 was closed as duplicate.

comment:38 by Itamar Ostricher, 9 years ago

Cc: itamarost@… added

comment:39 by anonymous, 9 years ago

I can't believe this still isn't a feature.

comment:40 by admiralnemo@…, 8 years ago

Cc: admiralnemo@… added

comment:41 by chris.bennell@…, 8 years ago

Cc: chris.bennell@… removed

comment:42 by Christian Boos, 7 years ago

#10320 was closed as duplicate of this one. It requested a feature along the same lines as #Hidesomefieldsfornewtickets, with the possibility to "reveal" the hidden fields if one really wanted to set them. It also suggests the use of a plugin for achieving this.

comment:43 by Ryan J Ollos <ryano@…>, 7 years ago

Cc: ryano@… added

comment:44 by fbrettschneider@…, 7 years ago

#10320 also suggested grouping ticket fields in colapsable boxes, was closed as duplicate, and was implemented by wiki:GroupTicketFieldsPlugin in the meanwhile.

comment:45 by grhm.smith@…, 7 years ago

Cc: grhm.smith@… removed

comment:46 by sam.halliday@…, 7 years ago

Cc: sam.halliday@… added

+1

comment:47 by andrew@…, 7 years ago

Cc: andrew@… removed

comment:48 by oan@…, 7 years ago

Cc: oan@… removed

comment:49 by anonymous, 7 years ago

I have 5 ticket types differing only a little bit from the standard ticket form. But one ticket type would be a very huge one defining about 100 new custom fields for its own purpose.

Does it make sense to use TH:CondFieldsPlugin in this case? I understand it as if it just *hides* the fields for certain ticket types, but actually every ticket would contain all of the custom ticket fields. But, in our case, I don't want to bloat the whole ticket db only because of that single type.

in reply to:  49 comment:50 by Ryan J Ollos <ryan.j.ollos@…>, 7 years ago

Replying to anonymous:

Does it make sense to use TH:CondFieldsPlugin in this case?

You may want to look at th:CondFieldsGenshiPlugin. However, please ask any further questions on the MailingList.

comment:51 by martin.wagner@…, 6 years ago

Cc: martin.wagner@… added
Description: modified (diff)

comment:53 by Ryan J Ollos, 5 years ago

Cc: Ryan J Ollos added; ryano@… removed

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

Cc: leho@… added

comment:55 by Ryan J Ollos, 4 years ago

Owner: Christian Boos removed

comment:56 by ralph@…, 2 years ago

Any updates on this? I'm also looking to implement different custom fields for different ticket types like the OP.

comment:57 by figaro, 2 years ago

This is not scheduled to be part of Trac core. However, will either th:DynamicFieldsPlugin or th:CondFieldsGenshiPlugin help you?

Also, please ask any further questions on the MailingList.

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.