Mirroring Jira
Configure task synchronization with Jira and choose which system takes precedence.
Beside the tracker when wanted
Use vitrinka to manage your project on its own, or connect its tasks to Jira. Each project has its own mirror configuration.
One side is the truth
The project setting names the connector and which side wins — local (vitrinka) or remote (Jira) — plus a state map between the project's states and the tracker's. New tasks are pushed, changes flow from the truth side, and when both sides changed the same task the truth side's version is kept, the other overwritten on the next sync, and a mirrored event on the task's ledger says what was overwritten. Nothing is silently merged.
| Setting | Meaning |
|---|---|
connector | jira — uses the workspace's Jira connection from Settings → Trackers (without one the server answers 409); empty clears the mirror. |
truth | local or remote — which side wins a conflict. |
config.stateMap | Project state key → Jira status. |
{"connector":"jira","truth":"local","config":{"stateMap":{"in_review":"In Review"}}}Binding and syncing
Administrators configure the mirror with PUT /api/v1/projects/{project}/mirror and request a sync with POST /api/v1/projects/{project}/mirror/sync. These operations use the workspace's stored tracker credentials. A sync transfers changes since the previous run and records syncedAt. This project mirror is configured through the API; the browser's Trackers settings manage report promotion.
What is mirrored
Outbound: title, body (with a link back to the task), labels when the ticket is created, and state through the map. Inbound: the ticket's title, status and assignee. Priority, comments, sprints, milestones, rank and intake drafts stay local — they are vitrinka's own vocabulary.
Plane is deliberately not wired as a mirror. The Plane integration a deployment can configure posts one comment per published set on the referenced issue; it does not mirror tasks.