fieldChange.from does not work inside compound statements

[steve.humpston]

I have a Field Value Changed trigger set to look at the due date of my issues. I am then trying to compute the amount of change.

The trigger has some useful instruction on it: 

"

How do I access the changed value in my rule?

The changed field value will be available anywhere smart values are supported using the {{fieldChange}} substitution. Use {{fieldChange.fromString}} and {{fieldChange.toString}} to access display values and {{fieldChange.from}} and {{fieldChange.to}} to access raw values (for a select field for example).

{{fieldChange}} will only contain the first changed value. If multiple values are changed (e.g. when setting multiple Fix Versions) then you can iterate over these using the {{#changelog.fixVersion}}{{toString}}{{/changelog.fixVersion}} expression.

"

Testing this out {{fieldChange.from}} and {{fieldChange.to}} return correct date variables.

However when I try and compute the difference using {{fieldChange.to.diff(fieldChange.from).days}} I get NULL in return.

I did confirm the diff syntax is correct by using two other date fields. This returned the difference in days successfully (in this case customfield_10039 == start date) {{triggerissue.dueDate.diff(issue.customfield_10039).days}}

Do {{fieldChange.to}} and {{fieldChange.from}} not work inside the .diff().days function? 

[Bill Sheboy · Accepted solution]

Hi @steve.humpston 

I wonder if it is a typing issue with fieldChange.  Perhaps try adding .toDate after the "from" or "to" value.

Some other ideas: 

• You could also compare/contrast by using the same value from changelog: {{issue.changelog.Due date.from}}
• I have found multiple variations of capitalization and spacing of the "Due Date" field to work/not work as smart values.  Trying logging the value without changes to confirm you have a good smart value.
• I have found writes to the audit log do not necessarily appear in the same order as within the rule.  Please consider adding some text to qualify your logging, such as "My log message 1: ..."

Kind regards,
Bill

[steve.humpston]

Thanks for the ideas.

• The changelog does not seem to work either for me, I tried all the variations of {{issue.changelog.duedate.from}} that seemed sensible. Let me know if you can think of one not in LOG3.
• The {{issue.duedate}} works robustly on my system and as you can see in LOG1 both my dates and the diff() function are working. The issue is defiantly with the {{fieldChange.from}} which appears to work unless you use it with the diff() function, LOG2
• Useful, thank you, added. Seems it did work out this time.

[steve.humpston]

I realised I missed your first suggestion @Bill Sheboy and that did the trick. The following smart value is now working, it calculates the change in duedate of a parent issue and adds the same difference to the due date of a child issue.

{{issue.dueDate.plusdays(fieldChange.from.toDate.diff(triggerissue.duedate).days)}}

When used in the structure found in the screenshot below I can now use changes in the due date of a blocking issue to update both the start and due date of any blocked issue.

 

My log rules break down how this works a little more and use .longDate to make things more readable:

LOG1-DUE DATE TRIGGER: {{triggerissue.key}} blocks {{issue.key}} and {{triggerissue.key}} due date was updated by {{fieldChange.from.toDate.diff(triggerissue.duedate).days}} days, updated from {{fieldChange.from.toDate.longDate}} to {{triggerissue.duedate.longDate}}

LOG2-DUE DATE CHANGE: Blocked issue {{issue.key}} due date added {{fieldChange.from.toDate.diff(triggerissue.duedate).days}} days, updated from {{issue.dueDate.longDate}} to {{issue.dueDate.plusdays(fieldChange.from.toDate.diff(triggerissue.duedate).days).longdate}}

[Bill Sheboy]

Awesome; I am glad you got it to work!  Sorry I didn't format that suggestion better, as that might have saved you some time  ;^)

I hope you have a great weekend!