The clear_on_hide option above specifies that the field's value should not be cleared when hidden (clearing 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_of = 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
captain.overwrite = false

The default copy behavior is to not overwrite a value if one already exists or the target field is hidden. To always copy the value, set the overwrite option to true.

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:

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 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.

About i18n/l10n support

The 0.12 branch of this plugin is prepared for localization.
But English message texts are still the (POSIX) default. If this isn't your preferred language, you can

Preparing the plugin from source now requires the additional step of compiling message catalog files. As long as you stick to the message catalogs served with this plugin directly, there is still nothing special to be done. Just package your plugin from source the standard way:

cd dynamicfieldsplugin
python ./setup.py bdist_egg

and the proper helper function calls to a suitable Babel install will be issued automatically for you.

Only if you encounter message catalogs with translations marked 'fuzzy', including them would require special treatment, since automatic compilation trashes them by default. Walk through: