Issues using User Picker (multiple users) custom group with condition "User is in custom field"

[Jeremy Jones]

Hi all,

I am trying to use a customer field as an approver list in conjunction with the transition condition specifying that the user must be in that field to have permission to transition an issue. However, no users either in the field or not are able to execute the transition. I have used approvals in this way at a previous company but cannot figure out why this is not working - can someone please assist?

This is the very simple workflow in question

---

In order to execute the transition between PENDING APPROVAL and AWAITING DEPLOYMENT, I have the following transition itself is very simple and has no other conditions or validators which would be causing a clash or issue

---

I have the parameters of the condition set as follows

---

This is the Group Field listed in the above 2 screenshots

---

This is the context for the custom field

---

And these are the only options available when attempting to transition the issue

---

Incidentally when I change the parameter to NOT being in the field I along with everyone else can transition the issue. Which leads me to believe there is a bug with the condition not recognising the field for some reason?

---

Available for any users within the project 

What am I missing?

[Trudy Claspill · Accepted solution]

Hello @Jeremy Jones 

Welcome to the Atlassian community.

There are a couple of pieces of information you left out that we need to ensure all conditions have been met.

When the condition is set to "user is in field" and you see only these options:

What value(s) are shown in the Change/Deployment Approver List field for that same field?

Is the user that is not seeing the transition for Approved logged in as a user that is specified within the Change/Deployment Approver List field?

[Jeremy Jones]

Thanks for responding @Trudy Claspill 

Sorry, I thought I had included the values in the above screenshots. If I understand your question correctly, this is what you are after????

---

Normally this will be filled with ~5 users (including myself) however whilst it's not working I only have myself in there

Hopefully this answers both your questions

[Trudy Claspill]

That is not what I'm looking for.

When you try to change the status of the issue you are viewing that issue.

When you are viewing that issue you should be able to see the Change/Deployment Approver List in the issue details.

I want to know the values displayed in that field in the issue for which you are trying to change the status.

I'm looking for confirmation that the field in the specific issue is actually set to a user and that is the user logged in and trying to change the status of the issue.

[Jeremy Jones]

I see

The field is not normally included in the Issue at all (and this has worked in the previous times I have used this method) however I have added it in for testing

---

This should show just me but it literally has all users in the company!

If I manually add myself in the field in the ticket, then I get the approval option

Ideally, I do not want this field visible within the ticket nor do I want users to have the ability to "pick their own approver"

[Trudy Claspill]

That explains the problem.

The field has no value set for it when you were attempting to transition the issue. Therefore the condition was not met (logged in user was not among the users specified in the field).

I see that in the context you set a Default Value for the field as "Jeremy Jones". The default value will be set only for new issues create after you specified that default value in the context. Was the issue you were trying to transition created after you set the field context to specify "Jeremey Jones" as the default value.

As to why you are seeing all users, when you click the pull-down option you would be shown a list of users that are valid to select for that field. That would be based on the context that you set for the field, and specifically the User Filtering setting of that context.

Since you have that set to "All active users are allowed", when you use the field pull-down to get a list of selectable values for the field then you will see all valid/active users of the Jira instance.

[Jeremy Jones]

I thought it may be something like that, so I cloned the test ticket just now to check whether I would be able to approve it as the default

But it did not work :(

Thank you so much for the responses!

[Trudy Claspill]

Cloning a ticket will not necessarily use the default value in the field context.

Try creating a brand new issue from scratch.

Can you also tell us the type of the project? Get that information from the Type column on the View All Projects page under the Projects menu.

[Jeremy Jones]

I will have to figure out an alternate method unfortunately. I did get it to work on 1 ticket some weeks ago, however what was odd was that a subsequent ticket of the exact same type and project did not work.

Most of the team(s) clone tickets in order to save time (which is already a pain as I find this does not seem to use updated issue type templates)

These ticket types and workflows are used in all of our projects which are made up of both Company Managed (in the case of this example) and Team Managed

Thank you so much for the replies

[Trudy Claspill]

The intent of the Clone function is to make a copy of the existing ticket as is. If a field is empty in the source, then the expectation is that you want it to be empty in the copy.

This is also why the native clone feature doesn't use templates.

The design of the functionality for default field values is to use them when a new issue is being created from scratch, not from cloning.

If you want to change the value of an issue that has been created by cloning, a couple of ways to do that would be:

• Automation Rules
• Third party apps that provide more robust cloning capabilities
• Developing an alternative cloning feature using native functionality, like Automation Rules, where you can set values during the clinic process.

[Trudy Claspill]

Oh, and the field does not need to be visible. In my testing I did not include the field on the issue screen but it was still set to the default value when a new issue was created from scratch.