Easier ways to set properties/variables for use within a rule, e.g. save JQL as smart value to support notifying of multiple issues, more ways to work with variable types, ability to edit a created variable with an action, increment a variable

As an automation rule writer
I want an action to edit a variable's value
So I do not clear it every time by using Create Variable

Acceptance criteria:

• There are separate actions for Create Variable and Edit Variable
• The action Edit Variable supports accessing any built-in or custom fields, and variables. Thus, Edit Variable can refer to itself, such as with concatenation.
• The scope of the variable is clear and unambiguous, based upon the nesting level at which it Create Variable was called

Business Value:
It is unclear how variables work or their scope; specifically, there is no defined way to edit a variable's value. There is an article indicating that defining a variable earlier in a rule makes it available withing structures such as conditions or branches. However, the only available action is Create Variable, which appears to shadow and then replace the value for each usage.

***

Improvements

• As an admin I would like to be able to create different types variables that can store values other than string such as list. Currently, the variable stores strings even if the smartvalue source is an array list (reference) Consequently, smartvalue.split(",") when stored in a variable will contain a string instead of a list, which limits the usage of other functions (such as variable.distinct). The variable cannot be converted as ObjectArray(Value) to be included in multi select list custom fields as well.
• Ability to set multiple variables in a single Create Variable action
• It would be good to be able to dynamically store a value for future reference in the scope of the rule. These could be stored against an issue/project/user or just the rule.
• Save an output of a JQL as smart value - This will enable the main use cases for bulk processing in Cloud of sending out notifications on a set of issues. Don’t use “issues”, Limits need to be set for the query (100? 200?)
• Add the ability to find issues using JQL in a smart value
  For example:

  {{issues.find("summary ~ "{{My field}}").key}}

• Collect multiple groups of issues in separate smart values - We can currently collect the results of a single JQL into the issues smart value, but there are reasonable use-cases (say, sending an email digest) where it's useful to get two or three JQLs at once and send them to the user separately (i.e., under different headings in the email).

***

At the moment, using the "Create Variable" action with a smart value expression will create a variable as the rendered String representation of the expression.

This means that, for example, you can't branch over a list of items added to a variable such as `{{lookupIssues.assignee.distinct}}`.

There are other places where this would be useful e.g. creating variables to hold objects or lists of objects and then performing other smart value operations on those in later parts of a rule.

• (BUG) Create var is not updated with latest value inside smart branch with more then 1 execution https://codebarrel.atlassian.net/browse/AUT-2403
• Consider variable scoping such that a branch can update a variable and see that reflected on the main line- This is 100% dependent on AUT-253. If we have the ability to wait on a branch then we can do the following suggestion from a customer:

Working with variable types

• Provide a Smart Value Function to convert a string to hexadecimal value
• Ability to access smart value variables as their underlying type -
  Currently, smart value variables created using Create Variable are stored as strings. This limits a lot of the functionality of the component. We should allow the variables to store and access the actual object types instead of just a string/text.
  In this community thread is some customer feedback and thoughts on usability, and some UX concerns around how exactly the component will work and the rule behaviour when dealing with complex/nested object types:
  https://community.atlassian.com/t5/Jira-articles/Automation-for-Jira-Create-variable-New-component/ba-p/1448118/page/2?utm_source=atlcomm&utm_medium=email&utm_campaign=kudos_comment&utm_content=post
• Custom smart value variable should retain original type instead of converting everything to text -
  Customers should be able to drop and replace a smart value with a smart value variable, but this is not currently the case since that variable may be turned into text rather then a number or date.
  There are also problems using defaultParams functions with variables such as number(myCustomVariable), which there isn’t really a workaround other than only using stringWrapper functions instead.
• Date functions should understand number strings - If you are pulling a string value from another field that is technically a number, the date function should still work. At the moment it just ignores it.
  e.g: now.plusDays(issue.Select CF.value)
  Workaround: Use the old syntax

  {{#now}}func=plusDays({{issue.Select CF.value}}){{/}}

• Field change trigger should provide better smart values avoiding string representations -
  Field change should have something like .fieldName which is typed, instead of accessing toString/fromString and having to use convenience functions such as toDate.
  Some ideas of how this could work...

  {{fieldChange.Due Date.diff}} //returns diff in days
  {{fieldChange.Due Date.from}} //returns old due date (as date object)
  {{fieldChange.Multi select.to}} //returns new value
  {{fieldChange.Multi select.added}} //returns only added values