UserInFieldInRolCondition fails in NPE after migration

[Vincent Thoulé [Alkaes]]

Hi Fidel

I have just migrated a customer from JIRA 5.1.8 from 6.2.7. Related Workflows Toolbox, we migrate from 2.0.19 to 2.1.21.

We are using the condition "com.fca.jira.plugins.workflowToolbox.UserInFieldInRolCondition". After the migration, we are encountering some NPE.

Caused by: java.lang.NullPointerException
        at java.util.StringTokenizer.<init>(StringTokenizer.java:182)
        at java.util.StringTokenizer.<init>(StringTokenizer.java:204)
        at com.fca.jira.plugins.workflowToolbox.UserInFieldInRolCondition.passesCondition(UserInFieldInRolCondition.java:109)
        at com.opensymphony.workflow.AbstractWorkflow.passesCondition(AbstractWorkflow.java:1085)
        ... 304 more

Before the migration, the condition was : User in field Reporter isn't in project role "My Business Role" with

          <condition type="class">
            <arg name="selectedUserGeneralizedField">6</arg>
            <arg name="condition">isn't</arg>
            <arg name="class.name">com.fca.jira.plugins.workflowToolbox.UserInFieldInRolCondition</arg>
            <arg name="selectedProjectRole">10400</arg>
          </condition>

After the migration, the condition is : All users in field "Reporter" are at least out of one of the following project roles: "My Business Role". Field may not be initialized.

The related Edit Condition screen has been changed in order to support Single/Multi User fields and one or many Groups.

Users in Field: Reporter Condition required: all users in field are at least out of one of the selected project roles Selected project roles: "My Business Role" selected Field must be initialized: Not selected

always with :

          <condition type="class">
            <arg name="selectedUserGeneralizedField">6</arg>
            <arg name="condition">isn't</arg>
            <arg name="class.name">com.fca.jira.plugins.workflowToolbox.UserInFieldInRolCondition</arg>
            <arg name="selectedProjectRole">10400</arg>
          </condition>

After having Edit and Save the condition without changing values, we have

          <condition type="class">
            <arg name="selectedUserGeneralizedField">6</arg>
            <arg name="condition">isn't</arg>
            <arg name="class.name">com.fca.jira.plugins.workflowToolbox.UserInFieldInRolCondition</arg>
            <arg name="selectedProjectRolesCommaSeparatedIds">10400</arg>
            <arg name="fieldMustBeInitialized">false</arg>
            <arg name="selectedProjectRole">10400</arg>
          </condition>

The NPE always occurs.

We have finaly set to enabled "Field must be initialized"

          <condition type="class">
            <arg name="selectedUserGeneralizedField">6</arg>
            <arg name="condition">isn't</arg>
            <arg name="class.name">com.fca.jira.plugins.workflowToolbox.UserInFieldInRolCondition</arg>
            <arg name="selectedProjectRolesCommaSeparatedIds">10400</arg>
            <arg name="fieldMustBeInitialized">true</arg>
            <arg name="selectedProjectRole">10400</arg>
          </condition>

And it works.

I did not have yet time to test if the error occurs with any type of Field (System/Customfield Single/Multi Users). I let you check that. Do you think it can be resolved in a near version ? It will be painful to make a manual correction in each of these conditions in each Workflow just during the Upgrade.

Thanks Vincent

[Fidel Castro Armario]

Hi Vincent,

The problem was reported yesterday in issue #73 and I have already fixed it. A new version will be released in a few hours solving the problem and providing new features.

The problem is due to new parameter selectedProjectRolesCommaSeparatedIds causing a NPE when not initialized. In new version, that parameter is automatically initialized with existing parameter selectedProjectRole if detected being null.

As a workaround you can edit the condition configuration and save the configuration without doing any change. This action will initialize parameter selectedProjectRolesCommaSeparatedIds.

Each time new configuration parameters are added to an already existing feature, previous configuration should be compatible, and no configuration adjustment should be required. This is an unfortunate bug introduced in version 2.1.21, although much care is always taken to make configuration migration transparent to the user.

Regards,

Fidel

[Vincent Thoulé [Alkaes]]

Hi Fidel,

Thanks for you quick return.

Note that your proposed Workaround to just Edit and Save without changing values did not worked for me. As I mentionned, I have to change the fieldMustBeInitialized from false to true.

Vincent

[Fidel Castro Armario]

Vincent,

Thank you very much for your detailed description, but I have tried to reproduce the exact case you describe, and in my case, when I edit and save the condition configuration without doing changes, the condition works and I don't get any NPE.

I have carefully examined the condition code, and unlike parameter selectedProjectRolesCommaSeparatedIds, not initialized parameter fieldMustBeInitialized is correctly managed by the plugin, and assigned a default value (as you show in your own case).

Unfortunately in the second NPE you got (after edit and save configuration), you didn't copy+paste the stack call, and I don't have the detail of the failing line of code. That information might be very useful diagnose the possible problem. Is it possible that you rescue that information from your log file?

It would also be fantastic, If you had the time to try to reproduce the problem again in the next few hours, to find out whether there is any mistake in your description, or if there really is a problem related to parameter fieldMustBeInitialized. In case you don't have the time to do it, I have to assume that there is some mistake in your description, and I will release the new version in a few hours, since the problem is quite important, and I have the new version almost ready to be released.

Thank you very much.

[Vincent Thoulé [Alkaes]]

I do not have time to make a refresh of the Database with th Backup, but I think I can Stop JIRA and restore the Workflow as it was before the change. I come backt to you ASAP.

V.

[Fidel Castro Armario]

Thank you, Vincent.

[Vincent Thoulé [Alkaes]]

Apparently, your workaround is working well, now.

In my 1st test, I may have omit to change one of the 6 transitions using this condition and evaluated for the current step. Other difference, is that in my first I have upgraded from 2.0.19 to 2.1.21 in the same session without restarting JIRA. Here, in the last test, I was already with 2.1.21.

Go forward with your new release with current fixe. I will have the opportunity to make new migration test on Thursday.

V.

[Fidel Castro Armario]

Thank you so much for your collaboration.

[Fidel Castro Armario]

Duplicate of #73.

[Fidel Castro Armario]

Fixed in version 2.1.22.