nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Inconsistent sub-task creation on transition post-function

Evan H

I have a transition that automatically creates a subtask for each checked box of a multi-check field. However, I have encountered a couple of anomalies that I don't know how to resolve:

(1) the subtasks are created sometimes, but they are not linked to the parent issue

(2) the subtasks did not exist until a couple of days later; however, their creation date was correct

Using JIRA 6.0.2 with Script Runner 2.1.15.

Accepted answers

Evan H

The problem was the result of a couple of things:

(1) Indexing. As noted in this Groovy Runner documentation, I had to place the subtask creation post-function immediately after the function "Re-index an issue to keep indexes in sync with the database." This note applies even if you have seven calls for subtask creation.

(2) I had an error in my "additional task" line of code that was preventing issues from being created successfully. To remedy this situation, I just deleted the code and, instead, explicitly named each subtask, which actually works better and cleaner than what I had been trying to achieve.

Making these two changes resolved all of my issues.

Thanks for the direction, Nic and Justin.

All comments

Nic Brough -Adaptavist-

(1) What do you mean by "not linked"? Sub-tasks need a parent issue to belong to, they should always show on the parent issue, and they should always include the parent in their own display - is that what you're talking about? Those displays don't appear?

(2) Interesting error. Very interesting.

I've got a strong suspicion that the indexing is broken. Issues that suddenly appear a few days after creation is a strong indicator - if they are not indexed correctly on creation, then they won't appear in some places, but when they're touched by an update (edit, comment etc), then they get indexed correctly.

So, a simple experiment. Create a new broken issue, then a new normal issue. Check the "recently created in this project" filter. If it's the indexing, then I'd expect the filter to have a "hole" in it where the broken subtask is. If you find such a hole, then visit it direct (e.g. if you see ABC-123, 124, 126, then the subtask should be http://yourjira/browse/ABC-125 ) What does that do?

Justin Leader6

I can't really answer this, but it would probably help if you posted your code that is generating this behavior.

Evan H

Nic,

Thank you for the quick response and suggestions. My comments:

(1) By "not linked" I mean exactly what you said. The automatic transition and subtask creation has created some subtasks with the appropriate inheritance of Summary, CCB Notes, Analysis Notes, Documents Affected, and Description, but the subtask and parent task are not linked to each other.

When I manually create a subtask, the link shows up as it should, with the parent having the Sub-Tasks section and list of subtasks, and the child having the parent ID in its description.

(2) After trying your little test, there are in fact gaps in the indexing. I manually created a subtask -- id was SAND-69. I then went through my transition -- no subtask appeared to have been created. I then manually created another subtask -- id was SAND-72. So a couple of numbers were skipped in there.

And yes, I can visit those missing issues directly, but subtasks SAND-70 through SAND-72 do not appear in the project issue list.

Sidenote: I had created 62 issues before I realized any were being created at all. In that list of issues that DID show up, there are gaps in the numbering that I cannot reach by direct URL. I get the error: "Issue Does Not Exist."

Evan H

This code snippet may or may not be useful...

For the transition, I have a post function that runs the built-in script "Create a sub-task" with the condition:

cfValues['Needed Change']*.getValue().contains("HW Fix")

And additional issue actions (I am not positive if the following code is correct):

def cf = customFieldManager.getCustomFieldObjects(issue).find {it.name == 'Change Type'}
issue.setCustomFieldValue(cf, 'HW Fix')

The above condition and additional action have been met with limited success. The additional issue actions piece has changed over the past week, but has apparently not hindered the creation of various subtasks, although none of the subtasks have the field values that the code was supposed to produce.

Nic Brough -Adaptavist-

Ok, so I think you've got two problems. Your index is definitely breaking. I'd concentrate on that first - get into a place where SAND-70 to 72 do get created and indexed correctly.

One other test - is it possible to schedule a full re-index? Might be a pain if you have a large Jira, as it locks it out while running. If you can do this, then do it and go back and see if the search results improve - i.e. stop dropping things out (and, of course, revisit the issue-does-not-exist issues)

I've only seen snippets of code, but can you have another look at your script and check that it actually tries to index the new issues it is creating? If in doubt, post the section that creates and tries to index them?

Evan H

Thanks for the tips.

I will notify our JIRA admin of the indexing issue and see what he says. If that doesn't solve my problems, then I will be back with more information.

Evan H

The problem was the result of a couple of things:

Making these two changes resolved all of my issues.

Thanks for the direction, Nic and Justin.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

scriptrunner

sub-task

auto-transition