Easier ways to set properties/variables for use within a rule, e.g. save JQL as smart value to support emailing/notifying of multiple issues, more ways to work with variable types in smart values

Improvements

• 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).
• (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

• 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