Changes between Version 26 and Version 27 of DynamicFieldsPlugin


Ignore:
Timestamp:
Nov 14, 2011, 3:00:02 AM (3 years ago)
Author:
robguttman
Comment:

added Set Rule

Legend:

Unmodified
Added
Removed
Modified
  • DynamicFieldsPlugin

    v26 v27  
    11[[PageOutline(2-5,Contents,pullout)]]
    22
    3 = Dynamically hide, default, copy, clear, validate, etc. ticket fields =
     3= Dynamically hide, default, copy, clear, validate, set ticket fields =
    44
    55'' '''NOTE: I suggest you use the 0.11 branch only even for Trac 0.12 installations.  The Trac 0.12 branch has some issues.  The plan is to merge the two branches to support both Trac 0.11 and 0.12 on one branch.  Thanks. - robguttman''' ''
     
    1414 * Copy one field's value to another field
    1515 * Validate a field's value
     16 * Set a field's value based on another field's value
    1617
    1718
     
    114115
    115116
    116 ==== Default value rule ====
     117==== Default rule ====
    117118Let'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}}}:
    118119{{{
     
    130131Using {{{append}}} presumes the field is a comma-delimited list and will append any missing values from the default preference value (which can also be a comma-delimited list) to that field's list.
    131132
    132 The above example introduces the plugin's user preference facility described next.
     133The above example introduces the plugin's user preference facility described below.
    133134
    134135
     
    141142}}}
    142143
    143 The above will prevent the ticket from being submitted if either the owner field is empty or the severity field's value equals "pick one".  The value for the {{{invalid_if}}} rule can be empty or any regular expression.  Hidden fields do not get validated.
     144The above will prevent the ticket from being submitted if either the {{{owner}}} field is empty or the {{{severity}}} field's value equals ''pick one''.  The value for the {{{invalid_if}}} rule can be empty or any regular expression.  Hidden fields do not get validated.
     145
     146
     147==== Set rule ====
     148When a developer starts working on a ticket, you may want to make sure she sets the milestone accordingly:
     149{{{
     150[ticket-custom]
     151milestone.set_when_phase = implementation|verifying|releasing
     152milestone.set_to = milestone3
     153milestone.overwrite = false
     154}}}
     155
     156When 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, you can alternatively use the special ''"!"'' value which specifies to set the field to the first non-empty value:
     157{{{
     158milestone.set_to = !
     159}}}
     160
     161If you want to enable each user to set the value as a preference, you should omit the {{{set_to}}} option entirely and instead specify the rule as follows:
     162{{{
     163milestone.set_when_phase = implementation|verifying|releasing (pref)
     164milestone.overwrite = false
     165}}}
     166
     167Learn more about user preferences below.  The default set behavior is to not overwrite a value if one already exists.  To always set the value, set the {{{overwrite}}} option to ''true''.
    144168
    145169