CloneIssueDetails recieving a NULL Issue

[Steven Hicks]

I am writting a plugin that involves overriding the CloneIssueDetails. The plugin, upon submission, clones the current plugin. This works fine in the test harness, however when pushed to a production environment I get the error:

The issue no longer exists.

The current issue is null. Cannot display the issue.

I've debugged into the code and this happens upon doDefault within CloneIssueDetails, because the original issue id is null. I'm not sure how it is not able to determine the ID only in that situation. My question is

How would I go about fixing this issue? I'm stuck as that I'm not sure how it would detect the current issue [which it knows when the plugin loads, but forgets about it internally when it gets to posting from the clone plugin].

[Steven Hicks · Accepted solution]

It is getting a null issue because the getIssue is not being set nor is it understanding where the ID is coming from. This was fixed by overriding the getIssue, and adjusting for checking the parameter when the ID does not exist.

[Jobin Kuruvilla [Adaptavist]]

In doDeafult(), getIssue() should get you the original issue if you are extending CloneIssueDetails.

[Steven Hicks]

Thats part of the problem, the doDefault doesn't countain an issue. Its throwing an exception that the Issue is null. I'm not exactly sure why its getting to that point. [The request for a new title makes note of the issue at hand]

[Steven Hicks]

Thats part of the problem, the doDefault doesn't countain an issue. Its throwing an exception that the Issue is null. I'm not exactly sure why its getting to that point. [The request for a new title makes note of the issue at hand]

getIssueObject(getIssue()); is the method that is throwing the execption because it has no clue as to the issue.

[Jobin Kuruvilla [Adaptavist]]

That is a bit strange! Are you invoking the clone by passing the id of the original issue? What is the URL you are invoking?

[Steven Hicks]

Its coming in via the id. Its only lossing the issue type in the base class on the "2nd post back" I'm not sure why its doing 2 post backs, however I suspect its something to do with workflows. Although I'm a bit lost as to how to verify that suspicion. [The staging server has a lot of complex workflow instructions]