Version 3 (modified by 14 years ago) (diff) | ,
---|
Contents
Dynamically hide, default, copy, clear, etc. ticket fields
Description
This plugin dynamically changes fields in ticket views based on simple rules using JavaScript / jQuery (required for this plugin). Example dynamic behavior:
- Hide a field based on another field's value
- Default a field's value per user preference
- Clear a field's value when another field's value changes
- Copy one field's value to another field
Configuration
To enable the plugin:
[components] dynfields.* = enabled
See the examples section below for how to specify rules.
Bugs/Feature Requests
Existing bugs and feature requests for DynamicFieldsPlugin are here.
If you have any issues, create a new ticket.
Download
Download the zipped source from [download:dynamicfieldsplugin here].
Source
You can check out DynamicFieldsPlugin from here using Subversion, or browse the source with Trac.
Examples
This plugin currently includes four rules. Each rule is specified by modifying the [ticket-custom]
section of trac.ini
. Below are several examples to motivate using each rule.
Hide rule
Let's say that your team only specifies effort for enhancements, but not for defects or other ticket types. This rule shows a custom effort
field only when the type
field's value is enhancement:
[ticket-custom] effort.show_when_type = enhancement
If your version field is based upon the milestone, then this rule hides the version
field when the milestone
field's value is empty:
[ticket-custom] version.hide_when_milestone =
Some of your fields may be auto-generated or used by very few people. To always hide a field:
[ticket-custom] alwayshidden.show_when_type = invalid_value alwayshidden.clear_on_hide = false
The clear_on_hide
option above specifies that the field's value should not be cleared when hidden (which is the default behavior).
Clear rule
In the version/milestone example above, if the milestone
changes then we want the version
field to be cleared:
[ticket-custom] version.clear_on_change = milestone
Copy rule
Let's say your workflow includes reassigning a ticket's owner
to someone else for review or verification but maintain the person responsible for the work in a custom captain
field. Initially the captain
should be set to the owner
, so to reduce data entry in making this so:
[ticket-custom] captain.copy_from = owner
Default value rule
Let's say your QA team usually creates defect tickets and your product managers usually create enhancement tickets. Here's how to allow each user to set the default value for the ticket type
:
[ticket-custom] type.default_value = (pref)
The above example introduces the plugin's user preference facility described next.
User preferences
Any rule expressed above can be configured to allow users to set preferences for them by appending (pref) to the end of the rule. For example, here's one of the hide rules from above:
[ticket-custom] alwayshidden.show_when_type = invalid_value (pref)
The (pref) will cause this rule to be added to a new Dynamic Fields preference panel where the user can disable the rule by unchecking the rule's checkbox. Some rules require user input such as the default value rule above. In that example, the user can both enable/disable the rule as well as set the field's default value that the rule should use for him/her.
Extensibility (implementation details)
Rules are implemented as Trac extension points to allow for new rules to be added fairly easily. Four rules come packaged to provide the dynamic behaviors described above. Each rule is split between two parts:
- rule specification (Python in
rules.py
) - rule implementation (JavaScript in
rules.js
)
The two parts are linked by instantiating the JavaScript part with the class name of the python part. See the code for details. JavaScript was chosen over Genshi transforms to dynamically have fields change without requiring a form submission - hence the plugin's name, Dynamic Fields.
Recent Changes
Author/Contributors
Author: robguttman
Maintainer: robguttman
Contributors: