Custom fields per component

[Markus Tacker <m@…>]

It would be great to have specific custom fields only displayed if a certain component is selected.

[ticket-custom]
installation = select
installation.label = Select the affected installation
installation.options = customerA|customerB|customerC
installation.components = Frontend|Webservice

This would mean that only if the component Frontend or Webservice is selected in the new ticket or update ticket view, the field installation would be visible.

Of course, this would require a reload of the ticket form if the value of the component field is changed.

[Alec Thomas]

This is possible using a custom !ITicketManipulator in the WorkFlow sandbox. filter_fields() would hide the appropriate field based on the available components.

The dynamic updating is not yet possible but I hope to have custom field types available soon, which would allow this. I'm not quite sure how to achieve this though, as ideally the ticket edit/view HTML would be a ClearSilver template. Because the template needs to be injected in arbitrary locations, the only real way I can think of accomplishing this is to set an element in the HDF to the rendered template output.

[anonymous]

It would be great if this was possible to do with the Version number as well. We currently use trac to manage several products and each has its own version numbers, so you should not be able to register a ticket on product A with version number B1.

[anonymous]

Component changed by mistake

[Christian Boos]

Like for the example given in the description above, there could be situations where data could be conditionally associated to tickets.

Non-applicable fields would simply not be stored (see #4447), and to reduce the clutter in the ticket interface, the conditional fields could be hidden/shown using Javascript.

When the fields cease to be applicable (e.g. in the example, Component changes from Frontend to Backend), the value should be cleared as well.

We'd need a more generic way to specify the constraints, though, so that this could apply to other fields (like type). Actually, I'll close this as duplicate of #2464, and I'll broaden the scope of the latter.