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.
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.
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.
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.
@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?
@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
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.
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?
Yes, I'm using approvals. That's the whole reason I added the field: so that users can choose their supervisor for the approval.
The approval is working as long as the user manually types the supervisor's username. I just wish I could make it where the user didn't need to type it.
This may be the issue (I'm not at work and can't verify right now):
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
But even if this works, this will make it where users can share their requests, right? Is there a way to allow user search without allowing request sharing?
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
...+ reading Fantasy). The same is true for him at the bank he works for: Efficiency is key when time literally equals money. Read on to learn how Sergey makes most of the time he has by...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs