|Version 9 (modified by 7 years ago) (diff),|
Dynamically hide, default, copy, clear, etc. ticket fields
- 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
- Install the plugin (after downloading and unzipping):
cd dynamicfieldsplugin/0.11 sudo python setup.py bdist_egg sudo cp dist/TracDynamicFields*.egg /your/trac/location/plugins/
See TracPlugins for more installation details and options. You'll likely need to restart Trac's web server after installation.
- Enable the plugin:
[components] dynfields.* = enabled
You can alternatively use the Trac Web Admin GUI to enable any or all rules.
See the examples section below for how to specify rules.
If you have any issues, create a new ticket.
Download the zipped source from [download:dynamicfieldsplugin here].
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.
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 effort is specified for either enhancement or defect ticket types, then use pipe-delimited syntax to list both of them:
[ticket-custom] effort.show_when_type = enhancement|defect
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
clear_on_hide option above specifies that the field's value should not be cleared when hidden (clearing is the default behavior).
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_of = milestone
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
[ticket-custom] type.default_value = (pref)
The above example introduces the plugin's user preference facility described next.
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 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
- 16479 by rjollos on 2017-04-10 19:00:12
TracDynamicFields 2.2.1dev: Support copy and set rule for owner field
The changes are needed for Trac 1.2.
- 16414 by rjollos on 2017-03-27 03:28:19
2.2.1dev: Add "not matches" pattern to set rule
Also fix preference not working for set rule.
- 16413 by rjollos on 2017-03-26 22:40:49
2.2.1dev: Account for all option names converted to lowercase