How to Avoid Duplicates across Different Teams?

[Sam]

Hi All, 

I am involved in two projects: Project A and Project B. In Project A, there will be an epic that initiates the creation of stories in Project B. 

I can make it function, but I'm noticing duplicates are being generated.

I have seen where one can add the lookup action to check for duplicates upon creating a new story. I am not able to get that to work. Please help me resolve this with  the lookup action. 

Through lookup action: Checking to see if summary for the story exists. If it does exist then do not create the story. 

[Trudy Claspill]

Hello @Sam 

In exactly what way is the rule not working?

Is it creating a duplicate issue?

Is it not creating an issue when it should?

Please share with us the details of the Audit Log entry created when this rule executes.

[Sam]

@Trudy Claspill 

Hi there, I have answered your questions below:

In exactly what way is the rule not working? It keeps giving me the same story summary over and over. The field is 'Request Type' and its a multi-select. When user clicks on any values its supposed to generate a story and a specific summary for that story. 

instead what happens is: User checks off 'Funding' from the 'Request Type' field then checks off 'ALSD' from the 'Request Type' field, but will keep getting duplicates for the 'Funding' story over and over, regardless of what other options are selected. 

Is it creating a duplicate issue? Yes, as far as the story summary (which is what we don't want) , they are different issue key's though. 

Is it not creating an issue when it should? It creates an issue when it should, but just the same issue over and over (duplicate)

Please share with us the details of the Audit Log entry created when this rule executes.


This what my lookup issues JQL looks like for funding value:

issuetype = {{triggerissue.issue type}} AND summary !~ "Funding" {{triggerissue.summary}} {{triggerissue.Request Type}}\"s

and for ALSD:

issuetype = {{triggerissue.issue type}} AND summary !~ "ALSD" {{triggerissue.summary}} {{triggerissue.Request Type}}\"s

[Trudy Claspill]

Hello @Sam 

Your first problem is that your Lookup Issues action can't execute the JQL you provided, as evidenced by the message in the log.

So the Lookup Issues actions will never find issues, and the check that lookupIssues.size equals 0 will always be true, so another issue will be created.

What is the actual text that ends up in the summary field, with any punctuation that gets included in that text? Don't show any extraneous characters - just exactly what ends up in the summary field. Can you please share how you are setting that fields in the Create Issue action?

[Sam]

@Trudy Claspill 

Yes, sharing the create issue action:

I do get a story with that summary name, however, as mentioned its only one story which ever story is selected first - it will just keep duplicating the story summary each time it creates a story. 

[Trudy Claspill]

Looking at the Create Issue action image you provided the Summary field is set simply to Funding

But in the JQL you are using for your Lookup Issues action you use:

summary !~ "ALSD" {{triggerissue.summary}} {{triggerissue.Request Type}}\"s

First, that syntax is wrong. That is the basis of the error you see in the log.

Second, the summary you are putting into your new issues says simply Funding. That is never going to match to what you seem to be looking for in your JQL.

Tell me, what do you expect the Summary to be in your newly created issue?

And exactly what are you trying to compare to that with the above JQL? 

[Sam]

@Trudy Claspill 

I appreciate your help. I expecting to see only 'Funding' in the summary in my newly created issue. 

I am checking for duplicates before the story is being created. So, if a story with a summary of 'Funding' already exists do not created it. 

[Trudy Claspill]

I have re-read your post and need some points clarified.

The rule is triggered by a change to the Request Type field, which is a multiple selection field.

You have a check in the rule to ensure the change occurred in an Epic, otherwise you don't want to proceed.

Based on the change to Request Type, you want to create a new issue in Project B, but only if one with a matching summary does not already exist.

Point 1: The user might edit Request Type and select "Funding" once. That should create a new issue with the summary "Funding" if one does not already exist. Is that correct?

Point 2: What if the user selects multiple values in the Request Type field? Should a new issue be created for each selection?
Point 2a: If so, would the new issue for each selected value have a different Summary?
Point 2aa: If so, please provide a table that maps the possible values for Request Type to the Summary that would be placed in the corresponding new issue.

Point 3: A user might come back to the Epic and edit the Request Type again and select another value. Is it correct that if issues with appropriate Summary values existed already for the previously selected values in Request Type, you would expect only one new issue to be created for the newly selected value?

I want to make sure I have understood your use case before recommending changes to your rule.

[Sam]

@Trudy Claspill 

Thanks for still sticking with me, I am trying still to resolve this, so anything you can provide I will appreciate. 

Everything you have summarized before the numbered points is correct. To answer your questions:

Point 1: The user might edit Request Type and select "Funding" once. That should create a new issue with the summary "Funding" if one does not already exist. Is that correct? Yes, exactly 

Point 2: What if the user selects multiple values in the Request Type field? Should a new issue be created for each selection? Yes, exactly 


Point 2a: If so, would the new issue for each selected value have a different Summary? Only the summary from what was selected in the check box field for 'Request Type' 

Point 2aa: If so, please provide a table that maps the possible values for Request Type to the Summary that would be placed in the corresponding new issue. The mapping should be like a 1 to 1. User selects, 'Funding,' then summary for story should just say Funding and so on and so on. 

Here is a table of the mapping

Point 3: A user might come back to the Epic and edit the Request Type again and select another value. Is it correct that if issues with appropriate Summary values existed already for the previously selected values in Request Type, you would expect only one new issue to be created for the newly selected value? Yes, exactly. No duplicates, if it already exists (summary for that value) don't create, but if its a new value and summary does not exist for the selected value - then create. 

[Trudy Claspill]

Thanks for the additional details @Sam 

This is not a rule that I've had to develop before, so I'm going to take a little time to experiment and research to ensure I don't provide you with bad advice.

[Sam]

@Trudy Claspill I believe the challenge here is that this field is a checkbox field. I am going to look for a new field for 'Request Type ' and have that be a drop down field instead of check boxes. 

The issue is that even if I do a JQL using 'Related Issues Condition' to check for duplicates - if the checkboxes are checked ---> it will just keep creating duplicates ---convinced automation rules run different for checkbox fields vs drop downs. 

I tested this under one project instead of two projects and I concluded the above. 

[Trudy Claspill]

Hm, you previously said the field was a multi-select, not a checkbox.

I did find this old post about iterating through a checkbox list to create issues based on each box checked.

https://community.atlassian.com/t5/Jira-questions/Jira-Automation-Iterate-through-checkbox-list-items-and-perform/qaq-p/1477776

However that doesn't address the issue where you don't want to create duplicates.

I might be over-thinking this, as so far I'm coming up with only fairly complicated solutions. So, I'm going to use my "phone a friend lifeline" to call on @Bill Sheboy, who is a wizard with Jira Automations. This may be something he has already worked out before. Bill, the summary is:

1. Epic has a checkbox field called Request Type.
2. Create one child issue for each checkbox option that is selected, setting the Summary of the child issue to match the name of the checkbox option.
3. Checkbox field selected options may change at a future date requiring additional child issues to be created for newly selected options.
4. Don't create another child story for a given checkbox option if one already exists.

Side note: I just recently discovered that there is a forum dedicated to Automation questions! So that is another location to post and look for answers.
https://community.atlassian.com/t5/Atlassian-Automation/ct-p/automation

[Sam]

@Trudy Claspill Thank you for all of your help with this. It is awesome that there is a forum that can help answer questions just for automation, I was not aware of that. All this was very tricky as the solution for checkboxes is completely different than for dropdown fields.

I was able to figure it out via brute force somehow. This creates stories based on checkbox selections, it will not create duplicates, and it creates the stories over to the other project. Here is the solution: 

I just duplicated for other stories the same way: 


This was the game changer here to avoid duplicates and proceed with checkbox selections. Notice the toString then fromString