Connection

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


If you have problems with connection, please refer to

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. (warning) 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 (warning) 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.