Page Comparison

...

Headers

IssueSYNC requires Basic Jira Authentication. Every request needs to provide username and password as well as a Content-Type of application/json. Every request to configuration endpoints needs the following header:

...

The base API URL is: http://your-jira-baseurl.com/rest/synchronizer/1.0/

Step by step configuration

Creating and testing an IssueSYNC Technical User.

A Technical User is a Jira user that has been delegated towards synchronization. All changes and issues will be created by the technical user on IssueSYNCs behalf. Every connection requires a Technical User in order to make requests to the interlan Jira API and create issues, apply changes to issues and so on. It is desireable that such user will not be normally used (i.e. it should not be an actively used admin account). We recommend creating a separate Technical User to be used throughout IssueSYNC.

...

Upon successful creation we can now use the technical user credentials (username and UNENCODED password in our request headers).

Creating connections

Local (within one Jira instance)

The request body consists of two connections. Functionally, a local connection is treated the same as a remote connection so it is necessary for two connections to be created. Remote and Local keys need to be manually generated and they must be unique in every connection. Technical User id is the id we get when making a GET request to /technicalUser.

[  
   {  
      "id":1,
      "localKey":"key1", // this is normally generated automatically, because configuration is done via API calls, we have to create keys manually
      "remoteKey":"key2", // Connection2's local key
      "remoteUrl":"http://localhost:8080/jira1",
      "remoteJiraType":"SERVER",
      "name":"Connection1",
      "technicalUserId":1 // this is NOT Jira User id
   },
   {  
      "id":2,
      "localKey":"key2",
      "remoteKey":"key1", // Connection1's local key
      "remoteUrl":"http://localhost:8080/jira1",
      "remoteJiraType":"SERVER",
      "name":"Connection2",
      "technicalUserId":1 // this is NOT Jira User id
   }
]

Remote (two Jira instances)

Both sides of the synchronization need to do this.

...

After saving connections, we can now proceed to Synchronization Scheme creation.

Synchronization Schemes

In order to create a new Synchronization Scheme we need to have a working connection.

...

This leaves us with a default empty Sync Scheme. Now we can create Contexts;

Contexts

Firstly, we need to create a Context draft by specifying a name and the id of the Sync Scheme the Context will belong to.

...

Afterwards, we need to activate the context. This is done by executing a PUT request to /context/activate with the payload we received as a response to the above PUT to /context

Field Mapping

Field mapping is divided into two sections. First, we will configure Exposed fields. To do this, we need to fetch all exposable Jira fields (meaning fields from Issue Types specified in Contexts). We can do this by executing the request below:

...

{  
   "id":150, // Sync Scheme Id
   "connectionId":76,
   "exposedFields":[  // list of all exposed
      {  
         "syncSchemeId":150,
         "localFieldId":"customfield_10501",
         "localFieldName":"test2",
         "exposed":true
      }
		// ...
   ],
	"receivedFields": [
		"exposed": false,
		"id": 413518,
		"legacy": false,
		"localFieldId: "customfield_1234",
		"localFieldName: "demo custom field",
		"received": true,
		"remoteFieldId": "labels",
		"remoteFieldName": "Labels",
		"syncSchemeId": 150
		/// ...
	],
}

In depth API documentation

We provide an API description json file that can be pased into Swagger editor. On the right side of the editor all configuration endpoints, their requests and responses as well as data models will be shown. 

...