How to map users between jira instances using exalate

[#1]

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?

[Alexey Matveev]

Thank you for this article. Very useful!

[francis]

@Alexey Matveev

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

[Alexey Matveev]

@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.

[francis]

Hi @Alexey Matveev

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

[Alexey Matveev]

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