Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,456,628
Community Members
 
Community Events
176
Community Groups

Disambiguating users??

I have a client with an interesting problem that is probably quite common but I have not had to address it before. 

They have an IT Helpdesk that supports their internal user base. However, for various reasons, they also allow users to submit tickets from personal accounts. This means that if Sally Smith is an employee and she submits a ticket from sally.smith@personal.com, Jira creates an account for her with the same name as sally.smith@company.com. This creates two entries for "Sally Smith". It makes it very difficult for someone who then later wants to assign Sally Smith to a ticket or @mention her to pick the right user.

What would be really helpful would be if Atlassian would show the domain associated with the account when selecting a user from a user pick list. They wouldn't have to reveal the entire name, but knowing the domain would help to disambiguate the user.

Any ideas how to address this? What have you done in this situation?

1 comment

@Derek Fields My first thought in this is why are they letting user enter tickets with a personal account. This just opens you up to hacks and other nefarious activity.

That said, could you process the emails and, if the domain does not match the company domain, use a service or 'dummy' account as the reporter? You could always add the email account to a custom field if you still wanted to be able to search for submits from that domain/email.

Jeanne

@Jeanne Howe - The problem isn't with the reporter. It is with the fact that "Sally Smith" now shows up as 2 different users in Jira. 3 months later, someone wants to @mention Sally Smith or assign her to a ticket and they can't tell which Sally Smith is the right one. 

The problem boils down to the fact that Atlassian won't display the login name so I don't know which user I am picking if they both have the same name.

@Derek Fields The problem is you are creating multiple accounts for a single user.

If Sally Smith has an "internal" user account, she should not also have an "external" user account. By checking the email domain before creating an account you will ensure that the "internal" accounts are the only accounts you will see in the dropdown and that "external" accounts are not created to begin with.

If personal email accounts must be used to communicate with these users, I would still not create these accounts within my instance. They are too easy to hack. Instead I would capture the data in a custom field and use this field to set up an automation rule that will notify the user of ticket updates based on the value in this field. This custom field should be validated at entry to verify it is in the correct email format, e.g. sally.smith@personal.com and not simply Sally Smith. 

This does mean that all @mention and Assignee notifications to Sally Smith will be sent to her "internal" user account; as this will be the only account Sally has within Jira. Once the ticket is assigned to her (or she see's the @mention), she would have the option of updating the custom field and entering her "external" user account in the field, thus allowing notifications to be sent to her "external" account. 

Bottom line, if Sally is going to be permitted to work with 2 different email addresses, she is responsible for monitoring both accounts.

For us, all accounts in our Jira instance must have a company domain email address. This allows the company to enforce 2FA and/or SSO authentication when logging into your company email account, which they can not do if you are using a personal email account.

Comment

Log in or Sign up to comment