Workflows
Status Synchronization
Your JIRA workflow can be synchronized:
- one-to-one (assuming remote workflow is same as local)
- partially at some defined status transitions
Here is an example of two different workflows synchronization. You may notice that:
- Open → In Progress is mirrored
If someone will click in progress, it will be reflected in second JIRA. - Closed → Open is one way
Only if left side will reopen issue, the transition will be executed on remote JIRA.
Workflow transitions are made on behalf of Technical User.
How it works
Basics
You are configuring workflow mapping inside your synchronization scheme.
Workflow mapping is a configuration of synchronization scheme and Jira's Workflow.
All contexts from your synchronization scheme using some Jira Workflow will use shared (by synchronization scheme) workflow mapping configuration.
Jira's Workflows are automatically found by project and issue type configured within contexts.
- If all local contexts (projects & issue types) are using the same workflow you will be able to configure shared transitions just once for whole synchronization scheme
- if your local contexts are using different workflows then you will configure workflow mappings separately per each workflow used by contexts
Exposing local transitions to remote issue.
You can configure which status changes (based on possible transitions) from your desired workflow you want to synchronize.
You have to set pair of statuses, which reflects status change (transition) i.g. from TO DO to IN PROGRESS.
When a user will transition an issue IssueSYNC will check Expose configuration and when there will be a match, it will send proper information to remote issue.
Resolution
By default resolution is always *[1] send as a metadata of transition mapping to remote issue.
[1] Resolution is send only when transition sets a resolution.
Receiving transitions from remote issue.
Once a remote issue has been transitioned and your issue has received a information about that IssueSYNC will look for a Received workflow mapping configuration.
It is quite similar to Expose workflow mapping configuration but here you defined exact transition *[2]. Once remote transition has taken place you will receive a code i.g. "To Do → In Progress" and you have to map this remote transition to your local one. In order to make it easier for you to configure you select base status "from" in Local From Status, which is followed by a transition from this base status. In Local To Status you have to select local transition which is displayed in a "transition name >> STATUS NAME" (same as Jira workflow text form).
Once receiving a transition from remote Jira, IssueSYNC will look for configured local transitions for matching remote transition.
Configuring more than one local transitions for the same remote transition
IssueSYNC mechanism will check for actual issue state and validate which transition is valid for current issue state and only that one will be performed. In more than one transitions will be possible, then first on the list will be invoked.
Resolution
By default IssueSYNC will always receive resolution from remote issue (see expose section). IssueSYNC will check if resolution should be added to transition request. If such transition contains a resolution field, IssueSYNC will validate if such resolution exists (by name and name translations matching) and if not it will try to create such resolution in your Jira.
[2] Instead of pair of status change.
Triggers in workflow transition
Workflow transition (post-function event) can trigger :
- Create remote issue
When issue reach given stage it can be replicated (for example in Service Desk: forward to 3rd line support).
- Update remote issue
You don't need to synchronize all field changes over and over but maybe at some point in workflow you may want to push that changes to remote JIRA.
Limitations
There are some limitations you need to consider:
- Expose transitions are defined between two statuses. You CANNOT point given transition if there is more than one transition between two statuses.
- Receive transitions (local transition) will fail when there is a field screen with required field *[3] associated with desired local transition, look here for workaround.
[3] Other than resolution