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

Auto Close Jira issues

Issue #880 resolved
Nikhil created an issue

Hi Fidel,

Could you please suggest me a best work around to auto close any incoming Jira alerts that has "Out of Memory Fired" in Summary field. Is it possible to auto update Resolution and Category of the issue before Closing automatically?

Nikhil

Comments (48)

  1. Fidel Castro Armario repo owner

    Hi @nikhil_dsv,

    Are these field created manually, by email, or by any other means?

  2. Nikhil reporter

    Resolution field is created by default when Incident is created via email and Ticket Category will be assigned manually during assigning the ticket to some one. Hope I answered your question?

  4. Fidel Castro Armario repo owner

    Hi @nikhil_dsv,

    You can use "Copy a parsed text to a field" post-functions 3 times in your "Create Issue" transition with the following configuration:

    1) Auto Transitioning to Closed Status:

    • Target field: Issue Status
    • Parsing mode: basic
    • Text to be parsed: Closed
    • Conditional execution: %{00000} ~ "Out of Memory Fired"

    Note that I'm assuming that your closed status is called Closed. Write in parameter "Text to be parsed..." the correct name of the status.

    2) Setting Resolution:

    • Target field: Resolution
    • Parsing mode: basic
    • Text to be parsed: Rejected
    • Conditional execution: %{00000} ~ "Out of Memory Fired"

    Note that I'm assuming that your desired resolution is called Rejected. Write in parameter "Text to be parsed..." the correct name of the resolution.

    3) Setting 'Ticket Category':

    • Target field: Ticket Category
    • Parsing mode: basic
    • Text to be parsed: Resource Shortage
    • Conditional execution: %{00000} ~ "Out of Memory Fired"

    Note that I'm assuming that your desired value for Ticket Category is called Resource Shortage. Write in parameter "Text to be parsed..." the correct value for Ticket Category.

  5. Nikhil reporter

    Hi @fcarmario The first one,Auto transition didn't work. The issue is getting created with In Queue status and not with Resolved (The issue must be Resolved not Closed automatically)

    Here is the post-function:

    The following text parsed in basic mode will be copied to Issue status: Resolved Post-function will only be executed if the following boolean expression is satisfied: %{Summary} ~ "Out of Memory Fired" This feature will be run as user in field Current user.

    From where does the text will be parsed for "Text to be parsed: Closed" as you mentioned above?

    Nikhil

  6. Fidel Castro Armario repo owner

    Hi @nikhil_dsv,

    If you want to auto-transition issue to "Resolved" status, you should write Resolved into parameter "Text to be parsed...".

    Possibly the reason why it's not working is that there must be a direct transition from initial status (i.e., "In Queue") to "Resolved". status.

    If your workflow doesn't have a direct transition from "In Queue" to "Resolved" statuses, you can create one, and then hide it to JIRA users by adding condition "Transition is triggered by JIRA Workflow Toolbox post-function" to it.

  7. Maggie Gu

    Hi @fcarmario,

    It works for me, thanks very much! BTW, is there a way to hide the transition triggered by JWT in 'View Workflow'?

    Thanks -Maggie Triggered_by_JWT.png

  9. Nikhil reporter

    hi @fcarmario ,

    Yes, I have replaced Closed with Resolved and yes, we do have a direct transition from In Queue to Resolved state. So, if we have a direct transition how should I configure in order to make this thing work?

    Nikhil

  10. Fidel Castro Armario repo owner

    Hi @nikhil_dsv,

    When you write the name of a status into virtual field "Issue status" the issue will be transitioned from current status to that status. It's required that there is a direct transition from current status to target status and that all conditions and validations are satisfied.

    In your case you also ensure that the boolean expression at Conditional execution is being satisfied. For debugging purposes you can temporarily clean parameter Conditional execution in order to make the post-function to be executed unconditionally.

  11. Nikhil reporter

    Hi @fcarmario,

    Nope, it did not work even by removing the Condition. Tickets are being created with In Queue status.

    Nikhil

  14. Fidel Castro Armario repo owner

    Post-function "Creates the issue originally" should be executed at first position in execution order. Please, do the change and let me know whether it solves the problem.

  16. Fidel Castro Armario repo owner

    Hi @nikhil_dsv,

    Try the following 2 changes:

    • Target field: Issue status (delayed writing)
    • Text to be parsed...: Resolved : {delay=2000}
  18. Fidel Castro Armario repo owner

    Hi @nikhil_dsv, I don't know whether @xuegu is a workmate of you. In affirmative case, can you, please, check with here your configuration? It seems that she has achieved to make it work.

  19. Maggie Gu

    @fcarmario , I used "Copy a parsed text to a field" in a sub-task to close its parent issue when its own status change to Done.

    I tried Nikhil's steps, but it did not work when I try to close a newly created bug after creating it. Hope this helps test.png

  20. Nikhil reporter

    @fcarmario ,

    Nope, we don't know each other.

    Maggie, Yes, it (I tried Nikhil's steps, but it did not work when I try to close a newly created bug after creating it) is not working for me either.

    My post-function:

    The following text parsed in basic mode will be copied to Issue status (delayed writing): RESOLVED : {delay=2000} Post-function will only be executed if the following boolean expression is satisfied: %{Summary} ~ "Out of Memory Fired" This feature will be run as user in field Current user.

  21. Fidel Castro Armario repo owner

    Hi @xuegu,

    You should keep "Fire a Issue Created event..." at last position in execution order, since the event is used for JWT to trigger delayed transition executions.

  24. Fidel Castro Armario repo owner

    Hi @nikhil_dsv,

    The problem is caused by a validator in transition "Resolve Ticket" which is requiring a field to be entered, and as I told you in a previous post, in order to transition an issue the conditions and validators should be satisfied.

    You can solve the problem by replacing the validator (which is provided by JIRA Suite Utilities add-on) with "Boolean validator with math, date-time or text-string terms" with a boolean expression like this:

    %{nnnnn} != null

    replacing nnnnn with the field code of the field you want to require to be set.

    You should also check option "Transition is triggered by a JIRA Workflow Toolbox post-function." at parameter "Skip validation when:", like shown in the screenshot:

    Captura de pantalla 2017-11-10 a las 17.39.57.png

  25. Nikhil reporter

    @fcarmario

    I have removed the Validator that we had for require fields in Resolve Issue step and replaced with:

    Only if the following boolean expression is true: %{Comments} != null AND %{Resolution} != null Validation will be skipped when: Transition is being triggered by a JIRA Workflow Toolbox post-function.

    and the Post-function remains same that was suggested above:

    Auto Transitioning to Closed Status: Target field: Issue Status Parsing mode: basic Text to be parsed: RESOLVED Conditional execution: %{00000} ~ "Out of Memory Fired"

    Message to show when validation fails: "".

    Still the issues are getting created with In Queue. Please help.

    Nikhil

  27. Nikhil reporter

    Hi @fcarmario ,

    This part is not working when issue is created manually or automatically. Below are the post-functions:

    Setting Resolution: Target field: Resolution Parsing mode: basic Text to be parsed: Rejected Conditional execution: %{00000} ~ "Out of Memory Fired" Note that I'm assuming that your desired resolution is called Rejected. Write in parameter "Text to be parsed..." the correct name of the resolution. 3) Setting 'Ticket Category': Target field: Ticket Category Parsing mode: basic Text to be parsed: Resource Shortage Conditional execution: %{00000} ~ "Out of Memory Fired"

    Nikhil

  28. Fidel Castro Armario repo owner

    Hi @nikhil_dsv,

    Please, attach a screenshots of the actual post-functions configurations you are using. What you have written in your post is a copy+paste of my instructions.

  30. Fidel Castro Armario repo owner

    Hi @nikhil_dsv,

    I don't find any reason why it's not working. It's a very simple use case, and the boolean expression you are using at Conditional execution parameter is OK since it works correctly at post-function 2.

    At least Resolution setting should work. What type is field Ticket Category?

  31. Nikhil reporter

    Hello @fcarmario ,

    We are in a tricky situation and would require your help in this.

    Currently, we have only 1 Incident workflow assigned to all the Clients. We have 2 requirements that should be satisfied for multiple clients. 1) Auto closure of tickets with Summary "Out of Memory Fired" and auto update Resolution and Ticket Category fields 2) Copy and Parse a line from "Description" field and make it Summary of the ticket.

    When these 2 logics are applied for the same workflow, it would affect other clients for whom they don't need this feature. So, can we have exceptions for these post-functions?

    Is it possible with some scripting?

    Nikhil

  32. Nikhil reporter

    Same here. Seriously wondering why it is not working.

    Ticket Category is of Select List (single choice) type.

  33. Fidel Castro Armario repo owner

    Hi @nikhil_dsv,

    You can use Conditional execution to execute any of those 3 post-functions only when a boolean expression is satisfied.

    I don't know how you can know which client is executing a workflow each time. Without that information I can't tell you which boolean expression you should use.

    Are Resolution and Ticket Category being auto-set in some cases, or never?

  34. Nikhil reporter

    Both the requirements are for different clients currently. Can we have conditional execution using boolean expressions with client names in it? Those fields must be auto set when we have events triggered from monitoring tools with auto resolve as well. This can be for 1 or many clients, only on such occasions. We want to have a universal standard workflow for all the clients rather having multiple workflows for different clients so only these many litigations. We need to have a lot of automations for all clients on single incident workflow executing with exceptions.

    Nikhil

  35. Fidel Castro Armario repo owner

    Hi @nikhil_dsv,

    JWT allows to make workflow very reusable, thus we usually can unify many workflows in only one. The problem is that your description is too vague for me to understand. You need to be very concrete in the description of your requirements.

    Please, answer the following question: Where in the issue is the name of the client? Is it in a certain custom field?

    In relation with automations through events, JWT doesn't provide those functionalities, so you should contact the providers of the plugins you are using to do it. I only can help you with solutions based on conditions, validators and post-functions provided by JWT.

  36. Nikhil reporter

    Hi @fcarmario,

    Sorry if I am not able to clearly explain you the requirements.

    We have added 2 post-functions which auto-resolves the issues the moment it gets created ( Client X's requirement) and also a post-function that parses, copies and make it as Summary for the issue created (Client Y's requirement).

    We have only 1 Incident issue type workflow where both these requirements needs to be deployed.

    When I did this in Stage Jira, The Client's requirement is getting fulfilled by auto-resolving the issues but unfortunately, the Client Y's requirement is also triggering, where the existing Summary is getting replaced with the new one ( with one in the Description field's "Description: " content, which is due to the 2nd post-function. So, I don't want this to happen. See below image with fusion of both requirements.

    Capture.JPG

    Both the post-functions should work independently with some conditions.

    Please feel free to ask if there are any confusions.

    Nikhil

  37. Fidel Castro Armario repo owner

    Hi @nikhil_dsv,

    How do you differentiate issues from a client from those of another one?

    For example:

    • They use different projects.
    • The reporters belong to a certain group.
    • There is a custom field where you select the client.
  38. Nikhil reporter

    I think the project key for now which would be easiest way to differentiate. Client names are stored in any Custom fields, reporters are the DL's and we have 2 or 3 per client and Clients are nothing but projects in Jira. Each client has their own Jira project.

    Yes, I think it will work if we add %{00018} or %{00019} in the conditional expression, like this

    %{00018} = MTSTHRDTL AND %{00000} ~ "Out of Memory Fired"???

    Will this be a client specific now?

    Above syntax is just an example.

    Nikhil

  39. Fidel Castro Armario repo owner

    For using the project key for conditionally execute a post-function you should use a boolean expression like this one in parameter Conditional execution:

    %{00018} in ["CRM", "APK", "MTR"]

    where %{00018} is field code for Project key, and CRM, APK and MTR are the keys of those projects where you want the post-function to be executed.

  40. Nikhil reporter

    This seems to be working now but one more help needed. How can we combine these both expressions. Please also tell me other operators to combine different expressions:

    1) %{00000} ~ "Out of Memory Fired" 2) %{00018} in [MTSTHRDTL]

    I want the first one to run only in project MTSTHRDTL and not for other projects.

    Nikhil

  41. Fidel Castro Armario repo owner

    You should use the AND logical connective:

    %{00000} ~ "Out of Memory Fired" AND %{00018} in ["MTSTHRDTL"]
  42. Nikhil reporter

    Damn!! The Check syntax gave failed when I tried earlier with AND, don't know where mistake was. Thank you.

    I am sending this for testing and will see if my Manager approves to replicate in Production.

    Nikhil

  43. Fidel Castro Armario repo owner

    The problem was that you were writing [MTSTHRDTL] instead of ["MTSTHRDTL"].

  45. Nikhil reporter

    This feature is working well in Stage Jira for now and same must be replicated in the production soon. In addition to the current config, can we copy the value of the Reporter to Assignee when the issue is Resolved as the assignee remains "Unassigned" currently, and this should be for the current project only, as this is shared workflow?

    Nikhil

  46. Nikhil reporter

    I have used below logic and it worked. The following text parsed in basic mode will be copied to Assignee: %{Reporter} This feature will be run as user in field Current user.

  48. Nikhil reporter

    Yes, I was about to do same.

    Thank you for your support Fidel. Will re-open if any further changes comes up.

    Nikhil

  49. Log in to comment
Assignee
Type
task
Priority
major
Status
resolved
Version
2.2.40
Votes
0
Watchers
2
Jira: the preferred issue tracker for Bitbucket. Join the team!