Image Removed
Connection
It's a key configuration in synchronization. It defines the target and / or source JIRA. All changes are pushed to or pulled from the target JIRA instance.
Connection consists of:
Name - which won't be visible in remote instance, but it's mandatory for synchronization (target of synchronization)
...
Remote URL - point to remote JIRA instance (it is not required if you select passive instance flag)
Technical User - it is the local JIRA user, defined in Technical User section
Local Authentication Key - it's token base solution, only data send with proper key will be synchronized, so it prevent unauthorized access to plugin API. We do recommend to use key matching your password policy. This value has to be unique, because it defines explicit connection on incoming request
Remote Authentication Key - it's token that allows access to remote JIRA instance (it's local authentication key set on remote instance)
Passive Instance - it sets communication model between passive and active, read more on Communication Models.
Often set when remote JIRA is behind firewall, so your local instance cannot send data to remote instance. In such case we turn passive instance flag on 
the other side (the instance not accessible / behind firewall need to stay active).
If you check it, remote URL and remote authentication key will not be required any more and that's because communication responsibility has been moved to active instance (active instance performs all requests in order to keep issues synchronized).
Please be sure that if you need active instance you can reach remote instance, and there is an exception in firewall, to avoid infrastructure problems not related with plugin.
If you fill all necessary data you can:
Test Connection (Remote JIRA test call) - to check if remote JIRA is accessible and we can connect to it. This call is skipped if connection is in passive mode. This test can also fail if remote JIRA is not set or is inaccessible.
Add connection - add connection, because dual configuration (to finish configuration you have to set proper connection on both JIRA instances), you can add connection without testing.
Connection monitoring and diagnosis:
...
| title | show IssueSYNC 1.x.x... |
|---|
| Section |
|---|
| Section |
|---|
|
| Column |
|---|
| Connection is the entry point to setup synchronization. The concept is pretty easy, but there are some keynotes that need to be highlighted. Access connection setup page Administration -> Addons -> IssueSYNC -> Configuration -> Connection
| Info |
|---|
If you have problems with connection, please refer to |
|
|
|
...
| Column |
|---|
| .JPG?version=1&modificationDate=1490257708106&cacheVersion=1&api=v2&width=250) Image Modified
|
|
| Section |
|---|
To create the connection you need to provide: - Name - which won't be visible in remote instance, but it will be wrapper like solution, you will define then contracts, mappings, status customfield in connection context
- Local User - it is the technical user, so the one that will be for example create/update issues on behalf remote instance users. There are few pitfalls here, so please double check this:
- User have to be dedicated, if you evaluate plugin you cannot use your current user, it is because changes made by technical users are not synchronize.
- User have to have proper permission - this may be obvious but it is the most common reason why synchronization don't work as you expected, please note that technical user if you want to synchronize issue need to have permission for browse/create/update issues, remember about comments and attachments permissions if you want to synchronize them.
- It is recommended that Technical user is dedicated for connection. If you have simple communication model (JIRA to JIRA) use only one technical user. For many connections, with more advanced user permissions use dedicated users.
- Remote URL - point to remote JIRA instance, it is not required if you select passive instance flag. Please be sure that if you need active instance you can reach remote instance, and there are exception in firewall, to avoid infrastructure problems not related with plugin.
- Local Authentication Key - it's token base solution, only data send with proper key will be synchronized, so it prevent unauthorized access to plugin API. It could be any value but we recommend to create this key using for example password policy. This value has to be unique, because it not explicit bind request with proper connection
- Remote Authentication Key - it's token that allows access to remote JIRA instance (it's local authentication key set on remote instance)
- Passive Flag - there are different communication models, the one which appears often is when one JIRA is behind firewall, and cannot sent data to remote instance. In such case we add passive instance flag on the other side (the instance, which is not visible over network need to stay active). If you check it, remote URL and remote authentication key will not be required any more and that's because we move all communication to active instance. Active instance perform all request in order to keep issues synchronized.
- Alternative BaseURL - URL that your JIRA server can access itself. Sometimes JIRA domain is not accessible from server directly so you can try to enter http://IP:port/context or localhost or 127.0.0.1.
If you fill all necessary data you can: - Test Connection - this test consist of two parts:
- Internal test call to check whether technical user exists and this call is possible
- Remote test call to check if remote JIRA is accessible and we can connect to it using remote technical user, this call is skipped if connection is in passive mode. This test can also fail if remote JIRA is not set or inaccessible. If remote JIRA instance is not set it's ok.
- Add connection - add connection, because dual configuration (to finish configuration you have to set proper connection on both JIRA instances), you can add connection without testing.
|
|