| Child pages (Children Display) |
|---|
...
| class | it_page_title |
|---|
...
| width | 8% |
|---|
...
| width | 900px |
|---|
...
| borderColor | #0288D1 |
|---|---|
| bgColor | #F7F7F7 |
| borderStyle | solid |
...
| width | 400 |
|---|
| Table of Contents |
|---|
...
| width | 500px |
|---|
Behind Firewall
| Div | ||||
|---|---|---|---|---|
| ||||
We want to keep one JIRA instance secured on network level. No external (user) access is allowed to JIRA behind a firewall. (This model works in many situations and is more a technical idea that can be used in other cases.) |
Prerequisites
\
Realization
In Connection configuration:
- JIRA A - has to be Active (Push&Pull)
- JIRA B - has to be Passive (do nothing)
Consideration
- Synchronization interval is controlled by Active JIRA.
- This model is transparent from fields, comments, attachments, workflows synchronization. You can switch between active/passive along the way.
Secure Isolation and Sharing (single JIRA)
| Div | ||||
|---|---|---|---|---|
| ||||
There is strict security policy where project are completely separated (for example, projects are dedicated for different customers that shouldn't even know about each other). We want to replicate some issues between such projects. For example, if we provide same solution for different customers, problems found in one customer can be replicated in other project. That will keep everyone up to date. |
Prerequisites
Given scenario (configuration) is for single JIRA instance.
Projects can have different configuration (issue types, workflows, etc.).
Communication model
Use INTERNAL model.
Realization
Create two Connections to your JIRA instance. The trick is to:
- use different Authentication Keys,
- if in given connection one key is used as Local Key, then it should be set as Remote Key in the second connection.
Create Contracts for each connection (see Connection & Synchronize 101).
From now on configuration is just like you will synchronize two JIRA instances.
Consideration
...
Archive
| Div | ||||
|---|---|---|---|---|
| ||||
We want to archive JIRA issues in Closed, Resolved, Done statuses. |
Prerequisites
You have to have two JIRA instances:
- Production
- Archive ($10 for 10 users; only 1 technical user needed)
Archive instance should have similar configuration like Production for projects and issue types you want to archive.
Communication model
Use OUTGOING model.
Realization
Create Connection & Contract on both JIRA instances (see Connection & Synchronize 101).
Configuration details
...
Create trigger should be an workflow event (GENERIC_EVENT or particular ones set in your transitions to Close, Resolved, Done statuses).
Comments should be Synchronize All
Attachments should be Synchronize All
...
Consideration
- Archived issues may not have the same issueKey (depending on sequence).
- Archived issues will not have change history nor workflow transitions executed according to original issues.
- This is good for keeping only fields data for further queries, statistics, etc.
Some of those drawbacks can be overcome when implementing synchronization from the very beginning of issue creation till it is closed including Workflow Synchronization.
Service Desk Instance + Internal
| Div | ||||
|---|---|---|---|---|
| ||||
We want to provide Service Desk for customers to handle support requests. |
Prerequisites
You have to have two production JIRA instances:
- Internal
Probably the one used right now in your organization. You can have there many processes implemented such as: Project Management, Software Development, Problem & Incident Management, Release Management, Change Management, Test Management, etc. For security reasons you don't want to give access for external users. - External
Single purpose JIRA for handling only external users requests. Optionally, it can have JIRA Service Desk installed.
Each JIRA instance will have different configuration because it servers different purpose.
Communication model
Use DUAL-MODE and (optionally) in PUSH&PULL flavour.
Realization
Create Connection & Contract on both JIRA instances (see Connection & Synchronize 101).
Configuration details
...
Access to this JIRA only for:
- administrator,
- technical user,
- agents.
Field Mapping should contains all data that describes a ticket.
Internal Comments should be enabled.
| Info |
|---|
In given configuration we assume that users from External JIRA does not communicate directly via comments. However, it is possible to allow them to do that. For more options please check Comments & External Comments Tab. |
Attachments should be disabled (it is more likely attachments will be transferred from External JIRA).
...
Corresponding mapping should be set.
Comments should be synchronized with 'All' option to let users from Internal JIRA understand ticket's context and history.
Attachments should be synchronized as well.
...
There are no outgoing tickets. You can consider to synchronize some fields on Update event but more likely synchronize comments and Workflow.
There are several options but in that scenario (with agents accounts on External JIRA) we suggest to use:
- Create Remote Issue Action - when Agent makes a decision that issue should be processed by 2nd line support, or
- Create event (see Contract) set to workflow event (GENERIC_EVENT or particular ones set in your transitions to Close, Resolved, Done statuses). There should be a status telling 'Pass to 2nd line support' or something similar.
Consideration
- Who (from your company) should have access to External JIRA? If you have dedicated 1st line support they can work on external JIRA and pass tickets to the 2nd line in your internal JIRA. Use some triggers combination that will work best for your case.
- Behind a firewall model is often used in that case to keep Internal JIRA secured on network level.
Working with many customers/providers
| Div | ||||
|---|---|---|---|---|
| ||||
We want to communicate with Customers or Providers via our JIRA instance. This scenario can be described as:
For better transparency we will describe the 2nd scenario. |
Prerequisites
There are several JIRA instances:
- Master
That is our's company JIRA instance that will be synchronized with many other Providers. We can loggin and work only with that instance. - Slave
Providers' JIRA instances. They don't know each other but they all connect to our Master JIRA.
Each JIRA instance will have different configuration because they are managed by different parties.
Communication model
Use DUAL-MODE or BROADCAST.
Realization
For each Provider's JIRA we need to setup Connection & Contract (see Connection & Synchronize 101).
Configuration details
...
Field Mapping should contains all data that describes a ticket.
Optionally you can synchronize Comments and Attachments.
Corresponding settings should be set.
...
There is a lot of outgoing tickets. You can consider to synchronize some fields on Update event but more likely synchronize comments and Workflow.
...
There is no outgoing tickets - Create issue trigger should be left empty.
Update trigger can be used to keep the other side up to date. Alternatively you can don't sent any feedback unless you reach given status (i.e. Resolved) and then propagate your changes (use workflow transition event).
You may want to keep the other side to follow some of your workflow, for example to inform if ticket was analyzed, in progress, tested, resolved (see Workflow Synchronization).
Consideration
- Based on security level you can consider different project structures and issue permissions.
- We suggest to create JIRA project for each Provider you synchronize. It is good mostly for two ways synchronization.
- If you it is more likely that you are pushing side (only you create tickets) then you may consider to handling that in single project with dedicated issue types for each Provider.
- Based on security level you can consider different project structures and issue permissions.
...
| width | 8% |
|---|