Jira 4.4.4 : Migrated Project to new Workflow, but closed issues doesn't reopen

[mijil das]

Hi,

I successfully migrated BM Project to a new workflow with no new addition. The issues which are already closed before WF migration fails to open and throws an exception but issues which is closed after WF migration reopens fine. The migration was successfull. On MultiselectCFTType throws NPE.

The exception is as given below. Please advice ASAP.

012-02-08 04:31:08,507 http-8080-4 ERROR bmij 271x196x1 1rfk5e9 10.99.54.110 /secure/CommentAssignIssue.jspa [atlassian.jira.workflow.OSWorkflowManager] Caught exception while attempting to perform action 31 from workflow 634354 on issue 'BLU-37849'
java.lang.NullPointerException
at com.atlassian.jira.issue.customfields.impl.MultiSelectCFType.getChangelogString(MultiSelectCFType.java:259)
at com.atlassian.jira.issue.fields.CustomFieldImpl.getChangelogString(CustomFieldImpl.java:357)
at com.atlassian.jira.issue.fields.CustomFieldImpl.updateValue(CustomFieldImpl.java:413)
at com.atlassian.jira.issue.fields.CustomFieldImpl.updateValue(CustomFieldImpl.java:362)
at com.atlassian.jira.workflow.function.issue.GenerateChangeHistoryFunction.execute(GenerateChangeHistoryFunction.java:64)
at com.opensymphony.workflow.AbstractWorkflow.executeFunction(AbstractWorkflow.java:869)
at com.opensymphony.workflow.AbstractWorkflow.transitionWorkflow(AbstractWorkflow.java:1265)
at com.opensymphony.workflow.AbstractWorkflow.doAction(AbstractWorkflow.java:567)
at com.atlassian.jira.workflow.OSWorkflowManager.doWorkflowActionInsideTxn(OSWorkflowManager.java:905)
at com.atlassian.jira.workflow.OSWorkflowManager.doWorkflowAction(OSWorkflowManager.java:865)

[Nic Brough -Adaptavist-]

Your comment now has provided some more information, which may lead to a fix. so...

The problem is still with the workflow. As I said I suspected before, it's trying to work with data that was created by your old workflow and you've removed the code that tells it how to handle it.

I am guessing (because you refused to answer the question five times, and still haven't) that your plugin provides Frequency and/or Severity field types.

You've removed the plugin, which disables the field types and prevents the workflow from handling them properly.

So,

1. again, what does your plugin provide
2. what did you remove from the workflow
3. what happens when you put the plugin back and re-enable the modules in it?

This time, could you please answer the three questions before rambling off about something else - the extra information maybe helpful, but the answer to those three questions is far more important.

[mijil das]

I think i have got the problem but need your help to resolve. The problem is not with workflow, its' with Frequency and Severity Options in View Issue. I noticed that Issues are not displaying the value of Frequency and Severity for an Issue but in database customfieldoption has the value for Freq and Seve exist.

How to dispaly the value of these two system custom field values. If it picks up then the issue is resolved.
Please respond ASAP.
Let me know if you need more information to debug.

[Nic Brough -Adaptavist-]

You still haven't told us what the plugin actually provides (yes, a field, but you then said "etc" which could be anything, so my previous suggestion was based on nothing but the field)

Now, that NPE is actually telling you that there is something wrong with the history, which could still be caused by your plugin. Possibly on trying to interpret the history, but I suspect it's more likely it's on the write.

The nagging doubt I have is because you originally said you were "editing the workflow to remove references to the plugin". That almost certainly means your plugin was doing something with the issue which is creating data which then cannot be read back properly. So you need to tell us what your plugin actually does, and exactly how the workflow was using it.

[mijil das]

I enabled the plugin.jar and accessed Projects which was assigned to Escalate, the problem is same, i am not able to reopen issues. It's not related to plugin.jar. NPE is related to at com.atlassian.jira.issue.customfields.impl.MultiSelectCFType.getChangelogString. Let me know if need further details.

[Nic Brough -Adaptavist-]

I'm not quite sure I understand the question.

>I successfully migrated BM Project to a new workflow with no new addition.

What's a BM project? (is it relevant to the question?)

When you say you migrated to a new workflow, does that mean you created a new workflow and workflow scheme and swapped them over?

What do you mean by "with no new addition"? No new steps/status? Just transition changes or something?

>The issues which are already closed before WF migration fails to open

What does "fails to open" mean? You can't see them on issue view? If not, then do they look ok on issue view? They have the correct status? Then where does the failure occur - on edit or a transition? Or both?

>and throws an exception but issues which is closed after WF migration reopens fine.

So you can reopen a closed issue ok. That points to something in the close transition in the new workflow not being able to handle the "close" of old issues, but I'm muddled on exactly what's happening and where you get the error, so I'm not sure

>The migration was successfull. On MultiselectCFTType throws NPE.

When does this happen? You said the migration was successful, but then say you're getting NPE in it?

[mijil das]

I shall give the details. A workflow by name Escalate was assigned to a Project BM this works fine. Now we removed a custom plugin.jar developed by us, this had reference to the workflow, hence removed all the custom class reference from the Escalate workflow in the xml file and created a new workflow by name RP. Now i have to assign BM Project to RP workflow hence did the migration which took 2 days and migration was successfull.

When i view a issue i get the workflow transition. The issues which are in closed state before the workflow migration had problem when i click on Re-open issue which throws NPE (as mentioned above), but when an issue is in open state or design pending or qa pending etc.. and migrated then when i close the issue and re-opens it works perfect.

I hope you have understood. Please let me know if you need further details.

Regards,
Mijil

[Nic Brough -Adaptavist-]

Again, you've said BM without explaining what it means or what it's labelling. I'm going to assume it's irrelevant. I also don't understand what "custom plugin.jar, this had reference to the workflow", but I'll guess you mean "custom plugin.jar provides something that the workflow uses" (e.g. a post function/validator/condition)

So, if I've understood this correctly, you have

1. An old workflow called Escalate
2. A new workflow called RP
3. RP is a copy of Escalate, but you've tried to remove the bits that tried to use the classes that plugin.jar provided
4. You have migrated the project from the old workflow to the new one manually.

The symptoms you are seeing are:

1. If an issue was in the status closed before the migration, and you use the "re open" transition, you get the NPE
2. If you work on a new issue, or one that was not in status closed before migration and you close it, and then use the "re open" transition, then it all works fine.

That tells me that the plugin was doing something to the issue on the "close" transition, and it's left data behind that it can't cope now that the plugin.jar has been removed.

I don't think the migration is a problem to be honest, even if it was a little long (I assume from the numbering there was a lot of issues to do)

I think the next question is "what did plugin.jar actually provide"? I'm pretty sure it's a custom field type, but I don't want to ramble about fixing that unless it definitely is one. Also, could you list all of the post-functions on the "re open" transition?

[mijil das]

BM stands for BlueMartini is the name of a Project(various Projects created in Jira). plugin.jar contains implementation of custom defined Asignee fields etc... We are working towards clearing all customization and install a vanilla version of jira 4.4.4.

Can you please tell me how to upload a file, so that i can upload the xml file, jar file etc.. i don't see an option on this page.

[Nic Brough -Adaptavist-]

Ah, so BM isn't relevant.

So plugin.jar contains a field, as I guessed, but can you tell us what else is in it? Is it just fields and nothing else?

If it is just fields, then you should have deleted the fields using that type before you removed the plugin. Your problem is (assuming it's just the field(s)) that the fields had data in them and the data is still there. When you're updating issues with that data, Jira can't handle them any more because you've removed the code that tells it how to.

There are three fixes

• The ideal fix is to put the plugin back in (which will re-enable the fields), then delete the fields, then remove the plugin again.
• The less ideal fix is to remove the data directly from the database. The process there is take backup, prove backup works (because you could destroy your installation with this process), shut down Jira, run SQL to remove the data, restart Jira and then re-index it after checking the data is ok.
• Write some code that will find the orphan data and remove it properly.

[mijil das]

As mentioned if the plugin.jar is a problem then DirectMarket Project which is assigned to Escalate workflow too fails in re-open. Please find all the files attached from the Atlassian support. Escalate.xml is the new workflow.

https://support.atlassian.com/browse/JSP-115151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

[Nic Brough -Adaptavist-]

We can't read support calls with Atlassian, they're not publically viewable.

I'm not sure what you mean anyway, we know the workflow is breaking, we know it's something in your plugins, and you still haven't told us what your plugin actually does, or how the workflow uses what is in it.

[mijil das]

The workflow consist of lot of classes pertaning to some additional implementation of these transisition. But the basic transition should work without these logic. Logically, if we look at the problem then none of the transition button should work its only with reopen. Please let me know how to attach files or any other means so that i can send the workflow.xml for you get a better understanding.

The reopen.java snippet is as shown below.

package com.escalateretail.jira.workflow;

import com.atlassian.jira.issue.Issue;
import com.atlassian.jira.issue.fields.CustomField;
import com.atlassian.jira.project.Project;
import com.escalateretail.jira.utils.EscalateProperties;
import com.opensymphony.module.propertyset.PropertySet;
import com.opensymphony.workflow.Condition;
import org.apache.log4j.Category;

import java.util.Map;

public class ReopenCondition implements Condition {
    private static final Category log = Category.getInstance(ReopenCondition.class);
    private static final EscalateProperties escalateProperties = EscalateProperties.getInstance();

    
    public boolean passesCondition(Map transientVars, Map args, PropertySet ps)
    {
        Issue issue = (Issue) transientVars.get("issue");

        Project project = issue.getProjectObject();
        boolean canReopen = escalateProperties.isSupportsReopen(project.getGenericValue());
        return canReopen;
    }
}

[Nic Brough -Adaptavist-]

>The workflow consist of lot of classes pertaning to some additional implementation of these transisition.

Well, that's almost an answer, but, again, could you tell us

1) What the plugin provides - your code is for one condition, but I suspect there is a lot more

2) How it was used in the old workflow

>But the basic transition should work without these logic. Logically, if we look at the problem then none of the transition button should work its only with reopen.

No. Logically, if we look at the problem, then the reopen problem occurs because there's something in your old workflow did to the issue that the new one can no longer handle. To follow that logical thread, we need you to answer the question "what does your old workflow do, that you have removed in the new one, and what does it call in the plugin?"

I'm really struggling here - this is the fifth time I've asked you to tell us what the plugin is providing and the third time to tell us what your old workflow is doing with it. I don't understand why you keep refusing to just answer the question. I don't need the code, just a simple list of fields, conditions, post functions, validators etc, and how your old workflow used them. Please, just answer the questions I've asked, and nothing else.