Conditional Behaviours Don’t Work Correctly When Switching Users

Conditional Behaviours that deal with User Picker fields have been observed to not work correctly when switching between users who have access to edit a field and those that do not have access.

First tested with the condition: “Except: Current user is current assignee,” but there is also another issue - the field is not readonly when the issue is unassigned.
Steps to reproduce:

1. Create a Behaviour to make a field (tested with Fix Version/s) readonly and add the condition “Except: Current user is current assignee” - field should be readonly except if the current user is the current assignee

2. Create an issue. The assignee is “Unassigned” and the field should be readonly. The field is not readonly (unexpected).

3. Now on the View issue screen, the message

Enable the edit popup for fields: []

is in the console, but the [ ] for fields to add the Behaviour to is empty. The field is still not readonly and the Edit popup form does not pop up. This might have something to do with the fact that the field was not readonly on the Create screen (/?)

4. Assign the issue to yourself (current user)- the field should be writable. It is writable - expected. In the console is the same message:

[SR Behaviours] Behaviours not applicable to the current form / screen

5. Assign the issue to another user. The field should be readonly. It is still writable - unexpected.

6. Refresh the page. The field is now correctly readonly and it the edit popup form is enabled. In the console:

Enable the edit popup for fields: ["fixVersions"]

and the [ ] now contains the field ID, “fixVersions” —> [“fixVersions”]

Tested the condition “Except: Current user is current assignee” with a custom field of type Text Field and it has the nearly the same output in the console and it doesn’t work until after a page refresh. This means that it is not an issue with the Version Picker or Fix Version/s.

Another test instance: Tested this Behaviour on an existing issue by switching the assignee to someone who doesn’t have permission to edit the field. The Behaviour doesn’t run and same message is logged in the console

Enable the edit popup for fields: [ ]

After this, switching the assignee to someone else who doesn’t have permission to edit the field also does not enable the Edit popup. The message

[SR Behaviours] Behaviours not applicable to the current form / screen

is logged out each time the assignee is changed at this point (until a page refresh). After a page refresh, the Behaviour works correctly and the message

Enable the edit popup for fields: ["customfield_10101”]

is logged in the console with the correct field inside the brackets.

Tested with a Behaviour to set a field readonly. Condition: “When: Current user is issue reporter.”
This condition works correctly on the Create screen, but doesn’t work when the reporter is switched to someone else and then switched back to the current user. A refresh of the page is required to make the Behaviour work again.

1. Create a Behaviour to make a field (tested with Fix Version/s) readonly and add the condition “When: Current user is issue reporter”

2. Create an issue where the current user is the issue reporter (the field will be readonly and the popup edit form will work - expected)

3. Change the reporter to a different user (the field will NOT be readonly - expected)

4. Change the reporter back to the current user (the field is no longer readonly - unexpected). The message

[SR Behaviours] Behaviours not applicable to the current form / screen

is logged in the console
5. Refresh the page and the field is now readonly again. The message

Enable the edit popup for fields:  

is logged in the console

SUMMARY:
2 main issues here, probably related:

1. The condition “Except: Current user is current assignee” doesn’t apply (presumably) when the assignee is null (most noticeable on the Create screen).

2. When switching from the null user, the page must be refreshed before the Behaviour will apply correctly. This happens on the first time the issue is created AND anytime the issue is reassigned to “Unassigned” and then put back to an actual user. However, this also happens when an issue is assigned to someone who does have permission to edit the field and then reassigned to someone who doesn’t have permission to edit (meaning it probably doesn’t deal exclusively with NULL assignees). Furthermore, if you change the user to someone who doesn’t have permission to edit the field and then change it to another user who doesn’t have permission to edit the field, the Behaviour still doesn’t work. The page must be refreshed in order for the Behaviour to work.