Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How to map users between jira instances using exalate

When you use synchronisation between multiple Jira's to coordinate the work between multiple teams, you might be faced with the problem that you have the same group of users, but different user id's.

 

But whenever you need to sync for instance the assignee, and you want to be sure that the assignee on the target instance is the same user as on the source instance.

 

Mapping the assignee based on user email

To implement such mapping, Exalate provides you a user lookup function based on the email address.

 

First of all make sure that the source Jira is sending out the assignee by adding to the outgoing filter

replica.assignee = issue.assignee

 

Second, on the target jira, use the nodeHelper.getUserByEmail to lookup the local user

 

issue.assignee = nodeHelper.getUserByEmail(replica.assignee.email)

 

What if the user doesn't exists - create user

It happens.  Imagine that a new team member is added to one of the two instances and but not added to the other system.  One might expect such problems to happen.

With the createUser method, you can add the user as required.

 

if (userHelper.getUserByEmail(replica.assignee.email) == null) {   
userHelper.createUser(replica.assignee.username,                         
"welcome",                         
replica.assignee.email,                         
replica.assignee.displayName)
}  

issue.assignee = userHelper.getByEmail(replica.assignee.email) 

 

What if the user doesn't exists - add a comment

Assume now that you're reluctant to have users added at will, and leave this to your administrator.  Another approach is to add a comment to the target issue, specifying that the assignee could not be set such that the administrator can take the next steps

 

def targetAssignee = userHelper.getUserByEmail(replica.assignee.email)

if
 ( targetAssignee == null) { 

String message = 
"""Dear [~admin],

Can you please create a user for $replica.assignee.displayName'?
The email address is '$replica.assignee.mail'
and assign this issue to the newly created user"""

issue.comments = commentHelper.addComment(message, issue.comments)
} else {
issue.assignee = targetAssignee
}

Flexibility through scripting

There is quite a bit discussion about the fact that UI based configuration is so much easier than scripting, and that's absolutely true.

The issue with UI based configuration is that it limits you in your options to configure the synchronisation behaviour your business needs.  

 

Whenever you bump into such limitation, you will have to wait for your vendor to adapt the product. You don't want to end up between a rock and a hard place - do you?

 

The flexibility of scripting provides you the means to implement any synchronisation case.

 

What is your point of view?

 

 

 

 

5 comments

Thank you for this article. Very useful!

@Alexey Matveev _cPrime_

We do have a whole array of potential articles in our sleeves. Is there specific content you would like me to focus on.

@francis I am interested with migration. It is very useful to map users during migration. And I know now that Exalate can help. 

There are 2 ways of migration (as far as I know):

1. Using plugins like Project Configuratoin or Configuration Manager.

2. Using plugins like Exalate, Backbone Issue.

I do the first way. But sometimes a step by step migration is needed. Projects must be migrated gradually and Exalate would be a good choice. I myself had it in mind but I never went with it because I was not sure that Exalate, for example, can map users. I did use Exalate but only for issue synchronization.

Would be nice to know more about the scripting language capabilities. It would be nice to know how Exalate can handle differences in workflow configuraion, for example. Right now for me, I can use Excalate only if two projects have the same configuration. I think it is not the case. But no time to read docs. Your article just made it simple to understand capabilites of Excalate.

It would be nice to know how Exalate can handle Jira Service Desk Configuration.

Hi @Alexey Matveev _cPrime_

 

When implementing a migration and thinking about Exalate - you have to be carefull.

Exalate is a synchronisation tool optimized to sync as fast as possible any change that is applied on an issue.  It is less a migration tool for some of the migration requirements:

 

* configuration migration
You want to be sure that the target configuration is identical to the configuration of the source. Tools like project configurator or configuration manager provide this functionality

* Issue key should remain the same
With a synchronisation tool, issue keys can be kept in sync - as long as the synchronisation is unidirectional and there are no deletes happening.  Jira has a deprecated API which allows to set the key - and Exalate has the flexibility to use this api which might be ok for the duration of the migration.

* Performance
When you migrate 50000 issues, you would like to do this overnight and in bulk.  As said before, Exalate will synchronise as fast as possible individual changes in a reliable way. To ensure that the sync succeeded, it is exchanging quite a bit of acks between the two systems.  When doing a bulk migration, there is no need to have this type of protocol.

 

Still it makes sense to combine a configuration migration with Exalate to implement - what we call - Life Migration.

 

The problem with a big bang migration - where the configuration and data is transferred overnight, is that in many cases - teams are not ready to switch systems, because of lack of testing.  People have not that much time to validate that a test migration succeeded and are postponing to the moment that it is too late. Reverting a big bang migration is probably not possible.

 

With life migration, and sync between the two systems, teams can work on both environments until the moment that the target configuration is fully operational.  Partial migrations like you indicate is another reason why to consider using a sync solution like Exalate.

 

The approach that a number of our customers took is

 

  1. Do a bulk migration to ensure that all historic data is available on the target system
  2. Connect issues on both sides such that these can be kept in sync - check here how you do this with Exalate
  3. Once that the team is fully switched to the target instance, remove all sync information.

 

If you would like to have more details on the migration check our blog here

I will add additional comments for the other topics you mentioned in your previous question

@francis Thank you for your answer. Very useful. I also read the blog. I will bookmark it.

Comment

Log in or Sign up to comment
TAGS
Community showcase
Published in Marketplace Apps & Integrations

Staying organized with Jira: best practices for a better project management

Project managers know this problem: A “mountain of work” lays in front of you, and you don’t know how and where to tackle them. Different to-dos lie ahead, but just one task after the other can be ha...

362 views 2 1
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you