Add Types and Status of subtasks

[Matthew Rotenbury]

I'm trying to configure a validator between a field on the main ticket and the existence of a subtask (or lack thereof).

An example being, if the "testing required" check box is ticked on the main ticket, then a testing subtask should exist. Likewise, if it isn't checked then the subtask should not exist. I think also being able to execute logic against the status of the subtasks would also be beneficial which could ensure in the above scenario that the ticket exists and isn't canceled.

It appears this would able to be completed by only adding a Types of subtasks field and Status of subtasks to the available list of fields.

[Fidel Castro Armario]

I will give support to this requirement in the next version of the plugin. The way to do it will be by enriching the boolean expressions parser used by "Boolean validator with math, date-time or text-string terms" and many other features of the plugin.

I will add functions that will allow to ask for linked issues and subtasks, and its issue types and statuses.

I will release a beta version as soon as it will be available.

[Fidel Castro Armario]

I have just made available version 2.1.20_beta_4 with an enriched parser that supports writing boolean expressions with dependence on linked issues, subtasks, and remote issue links. I have added support for a new data type called list of issues, and have added the following functions to operate with it:

• list of issues subtasks()
• list of issues linkedIssues()
• list of issues linkedIssues(string issue_link_types)
• list of issues filterByIssueType(list of issues issues, string issue_types)
• list of issues filterByStatus(list of issues issues, string statuses)
• list of issues filterByProject(list of issues issues, string projects)
• list of issues filterByResolution(list of issues issues, string resolutions)
• number count(list of issues issues)
• number remoteIssueLinks(string issue_link_types)
• list of issues union(list of issues l, list of issues m)
• list of issues except(list of issues l, list of issues m)
• list of issues intersect(list of issues l, list of issues m)
• list of issues distinct(list of issues l)

Now, let's see an example on how to use this new features in the parser to implement your requirements:

Let's suppose we have a Check Box type custom field called Issue Options, and that one of its options is "Testing required". We want to add a validator that will force the existence of at least one subtask of type "QA Subtask" in status "Resolved" of "Closed" whenever option "Testing required" is checked.

To implement that example we have to use validator Boolean validator with math, date-time or text-string terms with the following configuration:

For readability I copy and paste here the expression entered:

!matches(%{13500}, ".*Testing required.*") OR count(filterByStatus(filterByIssueType(subtasks(), "QA Subtask"), "Resolved, Closed")) > 0

Notice that code of field "Issue Options" is %{13500}. Function matches must be used to evaluate the value of Issue Options since that field may have more than one option selected, and the returned value is a comma separated list with selected options. We use regular expression ".*Testing required.*", since that regular expression matches any combination where option "Testing required" is selected.

[Matthew Rotenbury]

Fidel - just following up, this addition does work as expected based on my test case, thanks!

[Fidel Castro Armario]

This issue has been resolved with just released version 2.1.20.