Changes between Version 26 and Version 27 of DynamicFieldsPlugin

Timestamp:

Nov 14, 2011, 2:00:02 AM (13 years ago)

Author:

Rob Guttman

Comment:

added Set Rule

DynamicFieldsPlugin

@@ -1 +1 @@
 [[PageOutline(2-5,Contents,pullout)]]
 
-= Dynamically hide, default, copy, clear, validate, etc. ticket fields =
+= Dynamically hide, default, copy, clear, validate, set ticket fields =
 
 '' '''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''' ''
@@ -14 +14 @@
  * Copy one field's value to another field
  * Validate a field's value
+ * Set a field's value based on another field's value
 
 
@@ -114 +115 @@
 
 
-==== Default value rule ====
+==== Default 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}}}: 
 {{{
@@ -130 +131 @@
 Using {{{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.
 
-The above example introduces the plugin's user preference facility described next.
+The above example introduces the plugin's user preference facility described below.
 
 
@@ -141 +142 @@
 }}}
 
-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.
+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.
+
+
+==== Set rule ====
+When a developer starts working on a ticket, you may want to make sure she sets the milestone accordingly:
+{{{
+[ticket-custom]
+milestone.set_when_phase = implementation|verifying|releasing
+milestone.set_to = milestone3
+milestone.overwrite = false
+}}}
+
+When 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:
+{{{
+milestone.set_to = !
+}}}
+
+If 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:
+{{{
+milestone.set_when_phase = implementation|verifying|releasing (pref)
+milestone.overwrite = false
+}}}
+
+Learn 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''.