Datasources are duplicated after migration
Table of contents
Symptoms
When migrating the Elements Connect configuration with Configuration Manager, some datasources are duplicated.
Cause
To prevent datasource duplication, Elements Connect uses uniqueness criteria to ensure that a datasource being migrated doesn't exist in the target instance.
If you notice that a datasource has been duplicated, it's probably because a uniqueness criteria has not been met and our app considers both datasources to be different.
Resolution
Here are the uniqueness criteria used for each type of datasource:
| Datasource type | Criteria | ||||
|---|---|---|---|---|---|
| URL | OauthAuthentication | Authentication Type (see below) | |||
| Database | Host name | Login | Scheme/Schema | Database | Driver |
| LDAP | Host | Port | Login | ||
| Salesforce | Salesforce URL | Customer Key / Client Id | |||
| File | File path | ||||
| JNDI | JNDI name | ||||
| Zendesk Support | Subdomain | Client ID | |||
| Zendesk Sell | Client ID | ||||
Regarding URL datasources, there are other criteria based on the Authentication type:
| Authentication type | Criteria | |||
|---|---|---|---|---|
| HTTP Basic | Login | |||
| OAuth2 | Client ID | Authorise URL | Token URL | Scopes |
When you notice that a datasource has been duplicated, you need to compare both datasources (in the source and target Jira instances) according to these criteria:
- If one of these criteria is different, then the behavior you're facing is normal, as Elements Connect considers both datasources to be different.
- If all criteria are identical, this may be a bug, so please report this issue to our support team.
"Application Links" datasources are specific to each Jira instance and are not intended to be migrated.