What is the best way to reindex an issue modified in a script?

[Adam Barylak]

I don't know if this is the actual problem i am having with one of my scripts but i figured i'd start here since it is an indexing issue. I have a script listener which is modifying the DueDate of an issue based on another field changing. The script is running successfully and will update the DueDate, but it randomly fails to reindex with the new value in the field. So when i look at JQL search results, some of the issues have an empty Due Date, but when i click into the issue, it shows the field filled out correctly. My script does run a reindex based on a method that i found a while ago, but i want to check to see if there is a better way to do this that may be more reliable.

I am running JIRA 5.2.6 with the Groovy Runner plugin.

Here is the re-index section of my code:

private def reindexIssue(IssueManager issueManager, Long issueId, Category log, IssueIndexManager indexManager) {

        GenericValue issue = issueManager.getIssue(issueId)
        boolean wasIndexing = ImportUtils.isIndexIssues();
        ImportUtils.setIndexIssues(true);
        if ((BuildUtils.getCurrentBuildNumber() as Long) < 614) {
            ManagerFactory.getCacheManager().flush(com.atlassian.jira.issue.cache.CacheManager.ISSUE_CACHE, issue)
        }
        log.debug("Reindex issue ${issue.key}")
        indexManager.reIndex(issueManager.getIssueObject(issueId))
        //indexManager.reIndex(issue);
        ImportUtils.setIndexIssues(wasIndexing)
    }

Any help with this would be appreciated, thanks.

[JamieA · Accepted solution]

Are you sure it's random? Generally these things are deterministic.

There are problems modifying issues in listeners in 5.1 and 5.2 caused by https://jira.atlassian.com/browse/JRA-31775. Maybe you could upgrade a test instance to 6.0 EAP and see if you get the same problem. Modifying issues in post-functions should be OK.

[Adam Barylak]

Well, i guess the more i think about it, I noticed one issue with a script listener, and another with the fast-track of an issue. I just guess i assumed it was due to a problem with the code i had. So, are you saying that we may still experience this issue with the script listener though? We are on 5.2.6.

Is there a workaround which can be put in place to help this index correctly via a script listener?

[JamieA]

I think they are separate but related issues. No, I don't think there is any workaround, and I have spent some time looking for one.

[Joffrey_Hamman]

I have almost the same problematic. 
My goal was to reindex issues whose the scripted field value have changed, in order to sort them in the issues viewer.
If you run a groovy script inside the scripted field, it ends in a infinite loop.
Then, I run my groovy script in an escalation service which runs every minute.

I share with you my code which works well under Jira 7.1.0, maybe it can help you.

Escalation service :

1 2 3 4 5 6 7 8 9 10 11 12 13 14

import com.atlassian.jira.issue.index.IssueIndexingService import com.atlassian.jira.component.ComponentAccessor import com.atlassian.jira.issue.Issue import com.atlassian.jira.util.ImportUtils import org.apache.log4j.Category def issueManager = ComponentAccessor.getIssueManager() def issueIndexingService = ComponentAccessor.getComponent(IssueIndexingService) boolean wasIndexing = ImportUtils.isIndexIssues(); ImportUtils.setIndexIssues(true); log.warn("Reindex issue ${issue.key} ${issue.id}") issueIndexingService.reIndex(issueManager.getIssueObject(issue.id)); ImportUtils.setIndexIssues(wasIndexing);

To test under script Console, you have to define "issue" before :

1	Issue issue = issueManager.getIssueObject("your issue Key");

[Linus Lindroth]

This seems to be a serial to me. Now I realized that my listener plugin trow an error if I delete an issue. It isn't removed properly if deleted. If I disable my plugin it works again.

Can anyone figure out why? My re-index code looks like this:

private void reIndexIssue(Issue issue){
boolean wasIndexing = ImportUtils.isIndexIssues();
ImportUtils.setIndexIssues(true);
try {
ComponentAccessor.getIssueIndexManager().reIndex(issue);
} catch (IndexException e) {
System.out.println("Reindex error!!");
}finally{
ImportUtils.setIndexIssues(wasIndexing);
}
}

@EventListener
public void onIssueEvent(IssueEvent issueEvent) {
Issue issue = issueEvent.getIssue();
Issue parent = issue.getParentObject();
// if an event is triggered, re-index
reIndexIssue(issue);
if (parent != null) {
reIndexIssue(parent);
}
}

[Linus Lindroth]

Yes that was what I was looking for, thanks.

[MattS]

Oh I see, that's the direction.

[JamieA]

Can't you just also include:

if (issue.isSubTask()) {
    ...reindex(issue.parentObject)
}

[MattS]

I'd have a custom listener that checks if the currently changed issue is a subtask and then reindex the issue and also its parents. It can get messy though

[Linus Lindroth]

I was finally able to create a listener after going through Atlassians tutorials, it was quite tricky. I also found out how to re-index an issue. Here is the code i used:

private void reIndexIssue(Issue issue){
boolean wasIndexing = ImportUtils.isIndexIssues();
ImportUtils.setIndexIssues(true);
try {
ComponentAccessor.getIssueIndexManager().reIndex(issue);
} catch (IndexException e) {
System.out.println("Reindex error!!");
}finally{
ImportUtils.setIndexIssues(wasIndexing);
}
}

This works fine and now instantly re-index the issue I have updated. Unfortunately it doesn't update an issue if it has sub-tasks and the actual change is in one of the sub-tasks. In this case I sum up the estimated hours from all sub-tasks to the parent issue.

Does anyone know how to alter the code to re-index even the parent issue?

[Linus Lindroth]

Basically I want to set the value of either "Business Value" or "Story Point" equal to the value of the calculated scripted field. I have successfully done that in the scripted field directly, but the index isn't updated so there is a missmatch between the Estimate value seen in the backlog and the same value seen in the detailed view.

If the listener could re-index an issue if it has been updated I guess that would solve my case. Should be quite simple I guess, no other criteria needed, no transition anywhere. Perhaps the condition if a certain field has been updated, then re-index but I don't think that is necessary?

[JamieA]

Reindexing in a scripted field will cause a finite loop, ending in a stack overflow exception. The reason is because indexing reads all the field values from the issue... and the script you are writing is responsible for providing a field value. What do you actually want to do in your listener?

[Linus Lindroth]

I'm using Script Runner to, but a Custom Scripted Field. That was fairly easy since I could try out my code directly in there. I have been trying to figure out out to write a listener but that seems more complicated. I have also read a lot of the documentation but perhaps not enough.

I was recommended to use the built in listener called "fast track issue" since you can include some additional code there but I don't get the hang of it since I don't want to transition the issue anywhere.

I tried Heidi's code at the end of my Scripted Field but that causes an infinit loop it seems.

I'll have to read some more about how to write my own listener I suppose.

[Adam Barylak]

Like i mentioned in my original post, i am using the Script Runner plugin and using that to create the listener. If you have already created the listener that is updating the issue, you should be able to figure out how to use either the above re-index code or the re-index code in Heidi Hunter's post. You should probably also look at coding examples and the information located at Jamie's wiki for Script Runner: https://jamieechlin.atlassian.net/wiki/display/GRV/Script%20Runner. Also, another good reference is the JIRA API documentation: https://docs.atlassian.com/software/jira/docs/api/latest/

They are both doing the same exact thing, my code was copied and modified from somewhere else and includes the BuildUtils section which i believe will perform an additional step if the JIRA build number is lower than 614. That section you should just be able to remove as long as you make sure you are on a more recent version of JIRA.

My code is just a re-usable function so that you can call it many times without having to copy and paste it all over your code.

[Linus Lindroth]

Just some additional question here:

1) How did you use this code in practise? What imports did you use, how did you call for the function and with what arguments? Where did you put the code?

2) I'm very interested in how your listener was setup and how it works, can you share that?

I'm trying to figure out how to reindex an updated issue using a listener but I'm not very good at coding out of the blue, I need examples.

[Heidi Hunter]

How are you updating the issue? Using IssueService *should* re-index the issue for you.

We have some cases where we need to re-index manually, and are doing the following (also in JIRA 5.2 via Groovy Runner):

boolean wasIndexing = ImportUtils.isIndexIssues()
ImportUtils.setIndexIssues(true)
ComponentAccessor.getIssueIndexManager().reIndex(issue)
ImportUtils.setIndexIssues(wasIndexing)