Which Java API Jira provides to re-index some Agile Boards directly from a plugin?

[Deleted user]

What is wrong?

For some reason, I have to update the "Last updated date" field of an issue. To update the field directly in a code of the developed plugin, I usually do something like that:

com.atlassian.jira.issue.IssueManager issueMgr = /* injecting */; 
com.atlassian.jira.issue.index.IssueIndexManager issueIdxMgr = /* injecting */;

MutableIssue issue = issueMgr.getIssueObject(/* existing issue key */);
issue.setUpdated(/* timestamp in the past */);
issue.store();
issueMgr.updateIssue(currentUserOrAdmin, issue, 
   EventDispatchOption.ISSUE_UPDATED, /* sendMail */ false);
issueIdxMgr.reIndexIssueObjects(Collections.singletonList(issue));

This code allows issue updating and works perfectly. An adventure begins when we use a scrum board that contains the modifiable issue. The issue just disappears on the scrum board right after its Last updated field is updated by the code above. The issue is not visible on the Active sprints page as well as on the Backlog page (in sprint sections)  - it's a problem.

Workarounds I found to fix the situation (make the issue visible again) are:
   1) Manually update the issue status. I'm guessing that it may be a trigger for some internal indexing in Jira;
   2) Reindex the project from the Project setting page;
   3) Some others approaches that I wouldn't discuss here.

I'm guessing that to fix it I need to reindex (update somehow) agile boards containing the issue.

For now, I see only one option from above that can be implemented in the code: use Java API to reindex the project:

com.atlassian.jira.bc.project.index.ProjectReindexService projectIdxSrv = /* injecting */;

projectIdxSrv.reindex(issue.getProjectObject());

after that, all related Agile Boards have the correct set of issues, but I'm afraid that such an approach is not good enough - at least, it's maybe too slow.

Question

Does anybody know any approach to update/reindex the exact scrum board from a plugin code? For this aim which service/manager classes are available for injecting in a plugin? Which dependency do I need to add to the plugin project to have those classes?

[Nic Brough -Adaptavist- · Accepted solution]

I think we probably need to step back to an earlier part of the problem.  It's not about re-indexing a board or project, it's about why you need to re-index in the first place.

The point here is that if you change any indexable data on an issue (which is pretty much all of it), you should re-index, and there's nothing wrong with your code for that.

But.  The last updated date is not a simple field.  It is a simple date/time stamp in the database, but there's a load of code around it because people don't get to enter it, it is derived from other data.

I think the root problem here is actually that the indexing that you rightly trigger is failing because the last updated date in the database does not match the calculated value.

This makes me think that you should simply not do this.  Let Jira handle the updated date itself.

Which, of course, leads to the question of why you're doing this?  (Not just so we can recommend that you do not, but also as a way to explore a different route to getting the results you want)

[Deleted user]

Many thanks for your response

why you need to re-index

To be honest, to get such behavior (when an issue disappears), I need to update an issue via the plugin, then move it from one sprint to another sprint via the 'Complete sprint' dialog, and then update the issue one more time. After that the Issue disappears on the board of active sprint. At the same time, I see a correct updated date on the Issue page. That is why I thought I need to reindex boards.

The last updated date is not a simple field. <..> I think the root problem here is actually that the indexing <..> is failing because the last updated date in the database does not match the calculated value.

Maybe it is true, I don't know how it works internally. 

why you're doing this?

A bit more details about the plugin: it creates an additional relationship between an issue and some objects (the source for those objects is out of Jira). The idea is to keep the 'Updated' field of an issue up-to-date too when the related object is updated (for example, like Jira does it when a new comment is added). When the plugin obtains new objects, it tries to update related issues. It may be useful, for example, to highlight that someone works on the issue and so on. The time instant to assign to Updated field is defined by the related object which has the newest date. That timestamp may be a few seconds in the past as well as several days in the past. But, before updating the Updated field, a new value for assigning is compared with the previous value that the issue already has like that:

Timestamp newTime = /* obtaining the latest timestamp from related objects */;
if (newTime.after(issue.getUpdated())) {
   issue.setUpdated(newTime);
   /* save, update and so on */ 
}

The last updated date is not a simple field. 

Does it mean that the 'Updated' field should not be set up as I did at all? Maybe there are exists some others ways to say Jira that the Issue is touched and its Updated should be updated? 

[Nic Brough -Adaptavist-]

Ok, so there's a few things here.

Strictly speaking, your change to the issues "updated" field is not the right thing to do.  The issue has not been updated, something else that has a relationship with it has.  If you really wanted to do it purely, then any issue update in a project should change the updated date on all the other issues in the project.  Let alone changes in external build systems, shared docs and and and.

That is of course, very purist, and it would be easy to get into a discussion about how wide you should go if you are going to start considering changes to things that are not part of the issue as changes to the issue.

Jira doesn't consider anything outside the issue as an update, and in fact, ignores a couple of things that are (there's no updates to an issue if you re-order its sub-tasks for example, even though they are part of the issue!)

You could extend it to include any external change you wanted, but to do it, you'd need to write code into the core system, primarily in the index.  It's not something you can do with an app.

So, the way I would do it is a little different, but very simple.  Forget the "updated" field in Jira, and leave it doing what it is for - "show last update to this issue".  Create a new field for "remote object(s) last updated" and populate that with the objects last updated date.

There's two obvious ways to do this:

• There's a temptation to do it as a customised field - you could create a new field type for it, one that would behave as a date/time, be read only, and could display the external objects last updated, pretty much the same as the standard custom field, but you could also do more, like display or link to the exact object that was last updated, or be clever about what to display, like "display the value of the Jira updated date, unless there's a later date on an external object, then display that".  And so-on.
• But, if it were a standard Jira custom field, the simple act of your app updating it would make the Jira updated field update as well, because the custom field is part of the issue.  You could even leave it off all the screens, so it doesn't confuse the users (but it would remain in the history and be displayable and searchable)

The second one of those two options is probably the easiest  way of getting what you're trying to do - make a simple update to the issue and let Jira do the rest of the work for you!