nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

The "User Picker" field doesn't autofill for any users except "admin" user

Jason Freeman

I am currently evaluating Jira Service Desk (server version), and one snag I've hit is that the "User Picker" field that I have on our forms will not autofill unless I'm specifically logged in with our "admin" account, which is also the only account that is not in Active Directory. Our "admin" account is a Jira Service Desk account only.

I have tried putting a user in the jira-administrators group, and this does not make autofill work. Autofill literally only works for the "admin" account.

However, even though autofill is not working, if the user correctly types another user's username, the name is recognized as a correct user once the form is submitted. It's just that the autofill is not working, which would be very inconvenient for users.

Any ideas?

Accepted answers

All comments

Jack Brickey

@Jason Freeman, this seems odd. As I was reading I was thinking it might be because the user doesn't have permissions for the project, i.e. can be assigned to work on the issue. However, the last part where you say that the name is recognized if fully entered and submitted would refute my initial thought. When you say user picker field I assume this is a custom field? Is the user recognized in the default JSD fields, e.g. assignee?

Jason Freeman

@Jack Brickey, yes, it is a custom field with the type "User Picker (multiple users)."

In relation to your question "Is the user recognized in the default JSD fields, e.g. assignee?": the user creating the ticket (i.e., the customer) is not recognized in the assignee field because the user is not an agent.

However, even if I put a "customer" user in the agents group, autofill still does not work.

It appears that "admin" is the only one autofill works for.

I just went into the properties of one of the customer user accounts, and I did see this notice (not sure if this is even related):

"This user has no application access and won't be able to log in until added to an application."

I don't know exactly what this message means because this user actually has successfully logged in and can submit tickets and everything. This message is showing up

Jack Brickey

ah ok. So first off as to the application access message, it means that the user is a "Portal Only" user. They do not have access to the application itself. Yes they can log into the portal but that is all. they cannot log into JSD, Jira, etc.

The reason they do not show up in autofill is that they are Customers, i.e. portal only access. They will not autofill because they have to have application access for that to occur. Adding them to the "agents group" does not make them an agent and I expect you do not want that to happen.

Now, if you say use JSW for internal projects (development) and you have users with JSW application access then you can give the 'collaboration' access to JSD in which case they will autofill.

I hope this makes sense. I realize it can be confusing when first being introduced to the different user types.

Jason Freeman

We're just using Jira Service Desk. We are using it only for ticketing, not software development or anything like that.

The reason there is a user picker on the form is so that the user can choose his/her supervisor from the list, who in turn will approve or deny the request.

So, does Jira Service Desk not support autofill for customers who just submit tickets? If so, is there any other way to allow the user to choose his/her supervisor without having to 100% type out the supervisor's username?

Jason Freeman

What happened to the comments posted to this question? Yesterday, there were several comments, and they seem to have disappeared today?

Jason Freeman

In any case, this worked around the issue:

"Before you begin, make sure your Customer permissions > Who can customers share request with? setting is on Any customer or organization, by searching in this project. This ensures that customers can search for approvers."

However, this introduces a new issue in my environment: it allows users to share their requests, which we do not want.

Jack Brickey

it appears that most if not all posts after a certain point yesterday were lost. It is being investigated.

In any case I believe the change you made is what would be required to achieve your goal. Basically if you want to have issues be aware of other users in the organization, i.e. users can search for other users then you have to share issues across the organization. The other way to deal w/ this is to add all possible approvers (managers) to the list and allow any one of them to result in approval. then the person creating a ticket doesn't have to select the approver. This places the responsibility on the approvers to approver only for their group however.

Jason Freeman

I think you're right. Thanks for the help.

I've submitted a suggestion to have permissions for the users and for request sharing to be separated. I hope that they'll be able to do it.

I don't know if this is a deal breaker for us purchasing Jira Service Desk or not. I hope it's not because I otherwise like it. It just needs a lot more options in terms of prohibiting users from doing certain things.

Bao Truong_zl7fnn

We encountered this error and discovered that the term "Organizations" in the Customer permissions section refers to Project organizations. These can be found in the Project sidebar -> Customers, where you can find a button Add organizations. It is important to note that this is different from the Jira organization.

If we enable this feature, all members of this organization will be able to notify the organization whenever they create a new ticket. However, we do not want this to happen.

Therefore, we must choose the option Customers can search for other customers within their project or organizations and restrict project access.