1. Fidel Castro Armario Avatar Fidel Castro Armario
  2. Untitled project
  3. JIRA Workflow Toolbox
  4. Issues

Limit subtask creation based on parent status

Issue #53 resolved
Matthew Rotenbury created an issue

Hi Fidel -

I'm trying to modify the "Create Issue" transition of my sub-task workflow to limit the types of sub-tasks that can be created based on the state of the parent ticket.

As an example, if the parent is in state 1, there are 6 types of subtasks that can be created, but if the parent were to be in state 4, there are only 3 types of sub-tasks available that may or may not be a subset of the previously mentioned 6.

I was looking at the "validation based on regular expression" but that looks like an all or nothing option and the "Validation on subtasks" doesn't quite do it since that doesn't look like it would work as part of the subtask workflow.

Maybe a new validator such as "valdation on parent"? An inverse of the current subtask validator? Or is there another option to do what I'm attempting that I'm missing?

Thanks, -Matt

Comments (39)

  1. Fidel Castro Armario repo owner

    Hi Matthew,

    It's very easy to implement it using "Boolean validator with math, date-time or text-string terms". Let's see an example:

    We want to restrict subtask type creation depending on parent issue status:

    1. If parent status is "Open" we only allow subtasks types "Subtask_type_1", "Subtask_type_2", and "Subtask_type_3".
    2. If parent status is "Resolved" we only allow subtasks types "Subtask_type_1", and "Subtask_type_4".
    3. If parent status is different from "Resolved" and "Open" subtask creation is not allowed.

    We would use the following configuration of "Boolean validator with math, date-time or text-string terms":

    Captura de pantalla 2014-06-04 a la(s) 19.23.42.png

    For readability I copy+paste the boolean expression:

    (%{00042} = “Open” AND (%{00014} = “Subtasks_type_1” OR %{00014} = “Subtasks_type_2” OR %{00014} = “Subtasks_type_3”)) OR (%{00042} = “Resolved” AND (%{00014} = “Subtasks_type_1” OR %{00014} = “Subtasks_type_4”))

    Notice that:

    • %{00042} is field code for Parent's issue status
    • %{00014} is field code for Issue type

    Once configured, transition will look like this:

    Captura de pantalla 2014-06-04 a la(s) 19.38.54.png

    Now, let's suppose we replace restriction 3 with:

    "If parent status is different from "Resolved" and "Open" any subtask type is allowed."

    In that case, the following configuration will do the task:

    Captura de pantalla 2014-06-04 a la(s) 19.27.15.png

    For readability I copy+paste the boolean expression:

    (%{00042} = “Open” AND (%{00014} = “Subtasks_type_1” OR %{00014} = “Subtasks_type_2” OR %{00014} = “Subtasks_type_3”)) OR (%{00042} = “Resolved” AND (%{00014} = “Subtasks_type_1” OR %{00014} = “Subtasks_type_4”)) OR (%{00042} != “Open” AND %{00042} != “Resolved”)

    Notice that:

    • %{00042} is field code for Parent's issue status
    • %{00014} is field code for Issue type

    Once configured, transition will look like this:

    Captura de pantalla 2014-06-04 a la(s) 19.38.20.png

    Regards,

    Fidel

  5. BryanM

    Wish to use validation to prevent issue creation based on parent's custom field value

    I am looking to implement a system of Toll Gates (i.e., TG 0, TG 1, and so on through TG 5). I need to prevent the creation of a child issue (not sub-task) unless the parent's Toll Gate (custom field) is set to a certain value. I've looked at and tried the Workflow Toolbox's solution of:

    %{00014} = "Feature" IMPLIES %{00040} = "Epic" And %{53500} = "0"

    Features are releasable units of functionality into a production environment. So until TG 0 has been satisfied I need to prevent the creation of Feature issues. The TGs are a custom field in the Epic and Feature. The difference is that TG 0 is an approved Scope document that is an imperative required prior to creating and features (i.e., starting any development work.) This validation should work but doesn't it just errors like it should if the Epic's Toll Gate CF is not set to zero. I used the Text Field (read only) custom field type and am beginning to think that this might be the root cause for the validation not functioning as intended.

    What exactly am I doing incorrectly?

    Thanks a ton in advance!

  6. Fidel Castro Armario repo owner

    Hi Bryan,

    The problem is that %{00040} is field code for "Parent's issue type", i.e., the issue type of the parent issue of a subtask, and in your case the relation is not parent issue - subtask, but something like epic - story.

    Relation between Epic and Story/Task issue is implemented by means of issue links "is Epic of" and "has Epic".

    Please, try using "Boolean validator with math, date-time or text-string terms" with the following boolean expression:

    %{00014} = "Feature" IMPLIES count(filterByPredicate(linkedIssues("has Epic"), ^%{53500} != "0")) = 0

    This validations requires that ALL the epics of current issue have custom field %{53500} = 0. In case you want to require that AT LEAST an epic has custom field %{53500} = 0, then use the following boolean expression:

    %{00014} = "Feature" IMPLIES count(filterByPredicate(linkedIssues("has Epic"), ^%{53500} = "0")) > 0

    Regards

  7. BryanM

    Fidel,

    Thanks much for the help. Unfortunately, nether validator function as desired. The test needs to be that the Feature has >= 1 Epic and the Toll Gate = "0" (this is a string). The results I get is that even with an Epic parent and this Epic with Toll Gate (e.g., ^%{53500}) set to "0" the Boolean test fails. I am current trying to decompose the formula into seperate parts to get the test to function if I can break it into smaller parts.

    Again, thank you in advance for helping.

  9. Fidel Castro Armario repo owner

    You can't implement that validation using version 2.1.18 of JIRA Workflow toolbox. Can you update to the most recent version?

    You can obtain a trial license at JIRA Workflow Toolbox, clicking on "Try it free".

  11. Fidel Castro Armario repo owner

    Bryan,

    Use the following boolean expression instead:

    %{00014} = "Feature" IMPLIES (count(linkedIssues("has Epic")) > 0 AND count(filterByPredicate(linkedIssues("has Epic"), ^%{53500} != "0")) = 0)
  12. BryanM

    Fidel,

    I have been using v2.2 of the Workflow Toolbox in JIRA 6.3.13. It doesn’t show as incompatible. Is there any issues with this combination v2.2 with Jira Agile v6.3.13?

    Regards,

    Bryan

  13. Fidel Castro Armario repo owner

    Version 2.2 is compatible with that version of JIRA and implements all the functionality necessary for your validation. I thought you had version 2.1.18 because you selected it in field version when you created the issue. I'm editing the issue to select the correct version.

  15. BryanM

    Fidel,

    I didn't have to select any versions when I initiated this. Just added a comment. Sorry for the incorrect info as it surely wasn't intentional. I will definitely try your expression.

    Thanks again,

    Bryan

  16. BryanM

    Fidel,

    We've purchase this add on but still the boolean expression you provided doesn't return a true condition. I even broke it up into 2 pieces trying just:

    %{Issue type} = "Feature" IMPLIES count(linkedIssues("has Epic")) > 0

    With no success.

    Bryan

  17. BryanM

    Fidel,

    Incidentally, I am wanting to put this validation on the "Create Transition" of the Feature Issue to enforce the requirement that a Feature must have at least 1 Epic parent and that the Toll Gate is set to 0 (again, a text field vice numeric). The Toolbox Plug-In seems to have troubles validating any conditions on this transition. Is this a known limitation?

    Regards,

    Bryan

  18. Fidel Castro Armario repo owner

    Hi Bryan,

    It should work, since there isn't any special limitation on "Create Issue" transition.

    Let's do some debugging: Can you, please, remove the validation, and add post-function "Copy a parsed text to a field" in post-function "Create Issue", just after post-function "Creates the issue originally" using the following configuration:

    • Target field: "New comment"
    • Parsing mode: "Advanced"
    • Text to be parsed:
    "Issue type: " + %{00014} + "\nEpic isssues: " + toString(linkedIssues("has Epic")) + "\n Toll Gates: " + toString(fieldValue(%{53500}, linkedIssues("has Epic")))

    This post-function will automatically add comment to just created issue with the values used in the boolean expression. Please, let me know the content of the comment created.

  19. BryanM

    Fidel,

    I did the test as requested and here is the output:

    Issue type: Feature Epic isssues: WEB-31 Toll Gates:

    WEB-31 has the Toll Gate set to "0" (e.g., Toll Gate is a Text Field (read only) Custom Field type in my Jira). So, the problem is that while the Toll Gate Custom Field is set to "0" what the Plug-In sees is nothing (i.e., Null perhaps). My original intent was to us "TG 0", "TG 1", "TG 2", through "TG 5". I altered it to just the last characters of zero through five. Ok, well at this point to effectively use your Plug-In we purchased to implement my needed Toll Gates would it be better to use a calculated number or text field? I didn't use a number field just because it is decimal vice an integer. Given a preference and my user base it would be preferable to use the "TG 0" type format but I can live with either. I just need this to work.

    Thanks again for your help on this!

    Bryan

  20. BryanM

    Fidel,

    The output didn't get formatted correctly so here it is again:

    Issue type: Feature Epic isssues: WEB-31 Toll Gates:

  21. Fidel Castro Armario repo owner

    Bryan,

    Please, check whether %{53500} is field code for "Toll Gate", or for "Parent's Toll Gate" (i.e., the field "Toll Gate" in parent issue). I think this is the cause of the problem.

    Inject in the expression field code for "Toll Gate" instead of "Parent's Toll Gate".

  22. BryanM

    Fidel,

    It is indeed Parent's Toll Gate, which is the validation I was trying to check. The Parent is an Epic and the Custom Field "Toll Gate" is in the Epic Issue to ensure that the Epic passes TG 0 (i.e., the Scope Document has been reviewed and approved). The Toll Gate is set in the Epic by the completion (post-function) of a Scope Sub-Task. So, if I need to check the Epic's Toll Gate I assumed the %{53500} was the appropriate field code to validate. Just so that I am clear TG 0 is recorded on the Epic and TG 1 through TG 5 are recorded on the Feature. What is not readily apparent is that I can see the correct value of the Epic's Toll Gate (TG 0) set to a character "0" but the plug-in is not picking up or able to read this value. It is seeing a null or blank value and so that Boolean expression will always return a false. So, if I understand you correctly I should be just looking for the Feature's Toll Gate field and that will pick up the Epic's Toll Gate value?

    Regards,

    Bryan

  23. Fidel Castro Armario repo owner

    In JIRA Workflow Toolbox's terminology, "Parent's " refers to parent issue of a subtask. Epic is not a parent issue in this sense, but a linked issue which uses a special kind of issue link (is epic of / has epic).

    If you want to read the value of "Toll Gate" custom field in Epic issues, you should use expression fieldValue(%{nnnnn}, linkedIssues("has Epic")), where nnnnn is field code for "Toll Gate", not "Parent's Toll Gate". Otherwise you are reading "Toll Gate" in Epic's parent issue, provided Epic is a subtask, which is not the case.

  24. BryanM

    Fidel,

    Thanks so much for the clarification. I will try what you've recommended and let you know.

    Regards,

    Bryan

  25. BryanM

    Fidel,

    I have been trying this and some variations to it:

    %{00014} = "Feature" IMPLIES (count(linkedIssues("has Epic")) > 0 AND count(filterByPredicate(linkedIssues("has Epic"), (fieldValue(%{13500}, linkedIssues("has Epic")) != "0")) = 0)

    Still not successful. The "true" never gets satisfied. Perhaps some simplification is in order. Since my workflow for Features is unique to the Feature, we can assume that to create a Feature is already implied just to get to the create transition of the workflow. I have also tried just looking for the parent being an Epic and still no success. It seems as though I am getting in trouble with my version of expressions.

    Regards,

    Bryan

  26. Fidel Castro Armario repo owner

    Bryan, try the following expression:

    %{00014} = "Feature" IMPLIES (count(linkedIssues("has Epic")) > 0 AND count(filterByPredicate(linkedIssues("has Epic"), ^%{13500} != "0")) = 0)

    This is the same expression I posted formerly, replacing field code. I'm sure it will work.

    Your expression is not correct, because second argument of function "filterByPredicate(issue_list, boolean_expression)" should be a boolean expression where fields in issues to be filtered are preceded by prefix ^.

  27. BryanM

    Fidel,

    Thanks for your help with this expression. I tested it and it works on any other transition except the "Create" transition. When placed on the Create Transitions as a validation it fails every time returning a False no matter what. So the question is what is so specifically special about the create transition that would prevent this from working? I can re-engineer my implementation to work around this problem but I would prefer to solve it, if possible. The values are set correctly on the "Copy a parsed text to a field" in post-function but that done after the issue is created initially. So, is it possible that the "has Epic" link and Issue Type are not set to a value until after actual creation?

    This is sure a most interesting problem/behavior.

    Regards,

    Bryan

  28. Fidel Castro Armario repo owner

    Yes, I think that the problem is that "is epic of / has epic" issue links are not available until issue has been created. I will study the problem, and let you now if I can fix it, as soon as possible.

  31. BryanM

    Fidel,

    I will test this at the first available opportunity. I am moving my current SDLC process model defined in my Jira Dev environment up to my QA environment. Once completed I will circle back and test this for sure and let you know.

    Thanks so very much for your assistance,

    Bryan

  33. Fidel Castro Armario repo owner

    The bug has been fixed in just released version 2.2.1. I close the issue, please, reopen it if you find that it doesn't work as your expect.

  34. BryanM

    Fidel,

    Again, many, many thanks. I will certainly reopen if it does not work. I expect to actually test it early next week (e.g., Mon, Tue, or Wed) and will let you know the results regardless.

    Regards,

    Bryan

  35. BryanM

    Fidel,

    I thought I had replied back on this letting you know that it does work as intended. Sorry for the long time to get back with you. My only question now is what version of this plug in would have this fix included?

    Thanks again!

    Bryan

  36. Fidel Castro Armario repo owner

    Hi Bryan,

    The bug was fixed in version 2.2.1. Any version higher that this, will also have the fix included.

  38. Pierre-Jean Constant

    Fidel,

    Are boolean conditions language-based ? Is it related to the language of the user doing the transition ? I've a validation condition not working : %{00042} = "Resolved" because %{00042} display "Résolue" (french translation for "Resolved")

  39. Fidel Castro Armario repo owner

    The values returned by fields Resolution, Status, Issue type, etc. are always the translation of the default language of the JIRA instance.

    It doesn't depend on the language configured current user's profile.

    In a future version it will be a configurable parameter in the plugin. You can follow and vote for issue #511.

  40. Log in to comment
Assignee
Type
enhancement
Priority
major
Status
resolved
Version
2.2
Votes
0
Watchers
3
Jira: the preferred issue tracker for Bitbucket. Join the team!