Most of my JIRA requests are coming in from email, but we refer to clients by their clientID instead of by their domain. (IE - CompanyName1 -> CL1; CompanyName2 ->CL2)
Is there a way to set a custom field called "Client" based on the email reporter's domain?
For example:
Case:
Reporter = JoeSmith@CompanyName1.com
Then
ClientId = CL1
Case:
Reporter = FrankJones@CompanyName1.com
Then ClientId = CL1
Case:
Reporter = JaneDoe@CompanyName2.com
Then
ClientId = CL2
etc.
I understand I'll have to map the Domain to ClientID manually somewhere, but I don't know another way to do it.
Hi @Robert Levine -- Welcome to the Atlassian Community!
I cannot discern if you are using Jira Cloud or Server/Data Center; I am going to assume Cloud...
If you have just a few email address domains and clients to parse, you could extract the domain and use if/else conditions to set the client.
If you have a lot of clients, and you have tools to easily maintain entity properties, you could set the client ID as a property at the user level, or make a lookup table at the project level, and parse them from the list.
https://support.atlassian.com/cloud-automation/docs/jira-smart-values-users/#Entity-Properties
Kind regards,
Bill
Thanks - I am using JIRA Cloud.
I am having trouble figuring out WHERE to extract the domain and use the if/else condition.
If I go into my Project's Automation Settings and select Create Rule and create a rule for then the Reporter gets updated, I don't see a place where I can parse the domain and create the if/else statement.
Or... even better, I have no idea on how to make a lookup table and parse from there (but will do some digging into how to do that).
Either option would work - I just have to figure out how to do it.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
First...how is your rule getting triggered: when the issue is created, or when the reporter is later assigned, or something else? That will help to pick the rule trigger.
Once you have the reporter set, you can use the text functions to split out the domain to then test with conditions, such as with substringBefore():
{{issue.reporter.emailAddress.substringBefore("@")}}
Perhaps try that in a test rule and write it to the audit log first. That will help you experiment when implementing the rule.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
It will be when the issue is created, because the reporter will set when the email is received.
For issues raised via front-end or re-assigned, I can create a 2nd set of rules.
I'm still having trouble finding WHERE to enter the code to do the if/else statement.
Thanks for all the help!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Again, if you have a lot of clients I would advise against the if/else type of rule due to the maintenance challenges. That noted...
How about something like this, using the Create Variable action to save the result before testing in conditions...
Please note: Automation rules are limited up to 60 component parts, and so this type of rule will only work for up to 28 client checks:
1 trigger + 1 re-fetch + 1 create variable + (1 if/else condition + 1 edit action) X 28 = 59
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, definitely would need to go the lookup table route. More than 30 clients at this point.
I still don't see where to create a lookup table, even though the Atlassian instructions say I could find it in the Issues settings. And I'm an admin for our Atlassian products and have access to everything.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
So... maybe lookup tables are an add-in?
Is this what you were talking about:
https://marketplace.atlassian.com/apps/1214700/lookup-manager?hosting=datacenter&tab=overview
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Although there are probably addons for this capability, I was noting something a bit more home-grown using:
#1 should be easy to set up and try. #2 and #3 would be more difficult to do and maintain.
If you can find/use a marketplace addon that may provide a more maintainable approach for this use case.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Option 1 seems to be the best approach here, but I have no idea how to create variables and use a smart value to pull them out. If you can give a small example, I'm sure I could follow the logic and reproduce.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi, Robert.
After testing I learned that the match() function cannot accept a variable as a parameter, which is needed for your scenario because you want the client ID, not just the domain value. What I suggested will not help solve this. Sorry if this caused any detours for you to resolve this.
Your next steps may be to investigate the Atlassian marketplace to learn if there are addons for calculated fields to help.
Kind regards,
Bill
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.