Problem with Issue Manager - update issue behaves strange

[Pavla Kurkova]

Hi,

I am trying to write my own listener, which change automatically assignee of an issue. It listen to more events - issue created, issue updated etc. The same code works fine for some of these events, but for some it behaves strange:

Event Issue created - action history is OK ("user xz assigned issue ABC to user xy"), but issue itself does not change (left unassigned)

Event Comment added - action history is OK, issue detail also, but I can not see the issue in "Issues assigned to me"

Event Issue Update - works fine.

The plugin works competelly fine with JIRA 5.0, but it doesnt work with 5.2. It goes without errors.

My code:

MutableIssue mIssue = issueMgr.getIssueObject(is.getId());
        	
mIssue.setAssignee( assignedUser );
Issue newIs = issueMgr.updateIssue(assignUser, mIssue, EventDispatchOption.ISSUE_UPDATED, true);

MutableIssue test = issueMgr.getIssueObject(newIs.getId());
System.out.println(test.getAssigneeId()); // this returns correct Assignee

Any suggestion, what I am missing?

[Pavla Kurkova · Accepted solution]

Since JIRA 5.0.3 Atlassian added a new feature - Autowatch. This is implemented also as an listener and because there is no given order to listeners, the Autowatch module runs after mine and overwrites my changes back to original values.

So if you have troubles with IssueService/IssueManager in listener in JIRA 5.0.3 or higher, try to turn off the Autowatch (depends on version, see more info here).

This will be also reported to Atlassian as an bug - Autowatch should read actual issue state from database, not to hard use version in Event variable and overwrites changes done by other listeners.

[JamieA]

If this is the case, good spot, and this is indeed a bad bug.

[Henning Tietgens]

Is there a link to the bug report? I would like to vote... :-)

[Pavla Kurkova]

One more think - Autowatch module works fine, but it is not suited to case when other listener owerwrite Issue with its copy getted by issueManager.getIssueObject() function. E.G.:

// use original issue from event, over-typed to mutable
// seems to work fine even with autowatch enabled
MutableIssue issue = (MutableIssue) issueEvent.getIssue();
// ...changes to issue...

// use copy - as supposed in many tutorials
// doesn´t work as expected
Issue issue = issueEvent.getIssue();
MutableIssue mutableIssue = issueManager.getIssueObject( issue.getId() )
// ...changes to mutableIssue...

Main problem is, that nowhere is written you have to use overtyping and not the getIssueObject function, even more you can find lot of code using second option. I will do some more testing and then report to Atlassian. More than a bug it looks like an unhandled state.

Edit: Thaks to Radu Dumitriu answer.

[Alexander Urzhumtsev]

Good day. I have 2 JIRA: 5.2.1 and 5.0.1.

This aproach

In 5.2.1 works

In 5.0.1 doesn't work

What can I do for version 5.0.1? Do you know?

[JamieA]

Changing issues in a listener is generally hard to do post 5.0. The reason is that, all issues modified by a thread don't get indexed until the workflow action is completely finished.

Even if you modify your issue in a listener, then reindex it, the original copy of the issue will get reindexed afterwards. So your jql filters will show you something different from the actual issue.

The only way I've found to do this is to start a new thread in the listener.

The list of issues to be indexed are presumably in a thread local, but I can't find it. If you could it might be possible to add the issue object with the changed values after the original one, in the indexing queue.

[Pavla Kurkova]

Probably this is a bug, that IndexManager uses an old version of Issue. It comes with JIRA 5.1 update Indexing of issues during workflow transition has changed.

After this it is actually not possible to use IssueManager or IssueService in a listener, what a pitty.

How do you start a new thread in the listener (code example please)? I will do it this way, if there is not an other option.

Thanks.

[Dmitry Miroshnichenko]

Had the same problem with timespent in Jira 5.1 (Jira 5.0 updated fine). Try

ComponentManager.getInstance().getIssueUpdater()
.doUpdate

It helped me

[David Lemon]

My friend ComponentManager is depricated in befire5.0 version.

we now use ComponentAccessor

[Dmitry Miroshnichenko]

It's deprecated in Jira 5.2 and I don't see any reasons not to use it. It works and it's good. Deprecation is not the worst thing in Jira

http://docs.atlassian.com/jira/5.1/com/atlassian/jira/ComponentManager.html

[Henning Tietgens]

I think a reindex after updateIssue() is missing.

IssueIndexManager issueIndexManager = ComponentManager.getInstance().getIndexManager();
// to be sure, we get a current object of the issue
MutableIssue newIssueObject = issueManager.getIssueObject(newIs.getId());
issueIndexManager.reIndex(newIssueObject);

Henning

[Pavla Kurkova]

It does not help (I hope the IssueManager call re-index automatically). I tried also to use IssueSevice instead of IssueManager, but same result.

It is somehow related with changes in JIRA itself, because it works OK in 5.0, but does not work in 5.1 or 5.2. I looked into API for 5.1 and I found, that a new event in EventDispatchOption was added - ISSUE_ASSIGNED. Can the problem relates with this change?