Changes between Version 35 and Version 36 of DynamicFieldsPlugin


Ignore:
Timestamp:
Aug 1, 2012, 3:20:16 AM (12 years ago)
Author:
Ryan J Ollos
Comment:

Syntax highlighting.

Legend:

Unmodified
Added
Removed
Modified

  • DynamicFieldsPlugin

    v35 v36  
    2020 1. Install the plugin (after downloading and unzipping):
    2121    {{{
     22    #!sh
    2223    cd dynamicfieldsplugin/0.11
    2324    sudo python setup.py bdist_egg
    … …  
    2930 2. Enable the plugin:
    3031    {{{
     32    #!ini
    3133    [components]
    3234    dynfields.* = enabled
    … …  
    6163Let'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'':
    6264{{{
     65#!ini
    6366[ticket-custom]
    6467effort.show_when_type = enhancement
    … …  
    6770If effort is specified for either enhancement or defect ticket types, then use pipe-delimited syntax to list both of them:
    6871{{{
     72#!ini
    6973[ticket-custom]
    7074effort.show_when_type = enhancement|defect
    … …  
    7377If your version field is based upon the milestone, then this rule hides the {{{version}}} field when the {{{milestone}}} field's value is empty:
    7478{{{
     79#!ini
    7580[ticket-custom]
    7681version.hide_when_milestone =
    … …  
    7984You may also hide fields based on group membership.  For example, if only members of the production team should see a custom {{{duedate}}} field:
    8085{{{
     86#!ini
    8187[ticket-custom]
    8288duedate.show_if_group = production
    … …  
    8591Some of your fields may be auto-generated or used by very few people.  To always hide a field:
    8692{{{
     93#!ini
    8794[ticket-custom]
    8895alwayshidden.hide_always = true
    … …  
    9299Fields that are always hidden will also be hidden on the custom query ({{{/query}}}) page.  The {{{clear_on_hide}}} option above specifies that the field's value should not be cleared when hidden (clearing is the default behavior).  Sometimes you want to allow users to get access to hidden fields.  You can enable specific fields to be shown in ticket views when a user clicks a "Show hidden fields" link:
    93100{{{
     101#!ini
    94102[ticket-custom]
    95103mostlyhidden.show_when_type = enhancement
    … …  
    103111In the version/milestone example above, if the {{{milestone}}} changes then we want the {{{version}}} field to be cleared:
    104112{{{
     113#!ini
    105114[ticket-custom]
    106115version.clear_on_change_of = milestone
    … …  
    113122Let'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:
    114123{{{
     124#!ini
    115125[ticket-custom]
    116126captain.copy_from = owner
    … …  
    119129The default copy behavior is to not overwrite a value if one already exists.  To always copy the value, add {{{(overwrite)}}} as follows:
    120130{{{
     131#!ini
    121132[ticket-custom]
    122133captain.copy_from = owner (overwrite)
    … …  
    127138Let'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}}}:
    128139{{{
     140#!ini
    129141[ticket-custom]
    130142type.default_value = (pref)
    … …  
    133145For text fields, if the field's value is not empty, the default value will not be applied unless you set an {{{append}}} option to ''true'':
    134146{{{
     147#!ini
    135148[ticket-custom]
    136149cc.default_value = (pref)
    … …  
    146159Some fields may be required (i.e., can't be empty) or must not contain some specific values.  For example:
    147160{{{
     161#!ini
    148162[ticket-custom]
    149163owner.invalid_if =
    … …  
    155169You can also specify a condition under which the validation should be applied:
    156170{{{
     171#!ini
    157172[ticket-custom]
    158173phase.invalid_if.1 = verifying
    … …  
    167182When a developer starts working on a ticket, you may want to make sure she sets the milestone accordingly:
    168183{{{
     184#!ini
    169185[ticket-custom]
    170186milestone.set_to_milestone3_when_phase = implementation|verifying|releasing
    … …  
    173189When the {{{phase}}} field changes to either ''implementation'', ''verifying'', or ''releasing'', then the {{{milestone}}} will get set to ''milestone3''.  To avoid needing to update the current milestone's value in the rule, you can alternatively use the special ''"!"'' value which specifies to set the field to the first non-empty value:
    174190{{{
     191#!ini
    175192milestone.set_to_!_when_phase = implementation|verifying|releasing
    176193}}}
    … …  
    178195If you want to enable each user to set the value as a preference, you set to a question mark {{{?}}} as follows:
    179196{{{
     197#!ini
    180198milestone.set_to_?_when_phase = implementation|verifying|releasing (pref)
    181199}}}
    … …  
    183201Learn more about user preferences below.  The default set behavior is to not overwrite a value if one already exists.  To always set the value, add {{{(overwrite)}}} as follows:
    184202{{{
     203#!ini
    185204[ticket-custom]
    186205milestone.set_to_!_when_phase = implementation|verifying|releasing (overwrite) (pref)
    … …  
    193212Any 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:
    194213{{{
     214#!ini
    195215[ticket-custom]
    196216alwayshidden.show_when_type = invalid_value (pref)
    … …  
    199219The ''(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.  If you wish to disable a rule as the default preference, append ''(pref:disable)'' to the end of the rule like so:
    200220{{{
     221#!ini
    201222[ticket-custom]
    202223alwayshidden.show_when_type = invalid_value (pref:disable)
    … …  
    229250Preparing 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:
    230251{{{
     252#!ini
    231253cd dynamicfieldsplugin
    232254python ./setup.py bdist_egg
    … …  
    236258Only if you encounter message catalogs with translations marked 'fuzzy', including them would require special treatment, since automatic compilation trashes them by default. Walk through:
    237259{{{
     260#!sh
    238261cd dynamicfieldsplugin
    239262python ./setup.py compile_catalog -f