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