Claervo Undo for Jira

Security overview

The trust boundary, permissions and safeguards behind restoring deleted work items and undoing batches in Jira Cloud.

Forge-only architecture

The application runs on Atlassian Forge with no external fetch permission, remote backend, external database, analytics endpoint or AI processor. The mirror, the ledger and the audit records stay in Forge SQL and Forge storage for your installation; the app is eligible for Runs on Atlassian.

Least-privilege scopes

Scopes are limited to reading Jira work items, comments, worklogs and links, writing work items to recreate or revert them, reading user display names and account types, and storing tenant-local application state.

Authorization

The console is a Jira administration module that Jira shows to site administrators only. Every call additionally checks an active Marketplace license and that the call comes from that module. Payloads, work item identifiers, batch keys and settings are validated server-side; SQL uses prepared statements.

Safe write path

A restore re-reads Jira immediately before creating anything, so a work item that still exists is never duplicated, and each restore is claimed once so a redelivered job cannot run twice. A batch undo re-reads every field and reverts it only when it still holds the value the batch produced; anything changed since is left untouched and reported. Fields Jira rejects are dropped from the restore and listed, never guessed. Every restore and undo is recorded with the requester, the steps taken and what was skipped.

Honest output

Before every restore the preview lists what will come back and what cannot: the new key, the created date, authorship of comments and worklogs, attachment content, change history, watchers and votes.

Rate limits and budgets

Jira requests honour Retry-After on HTTP 429 and retry idempotent calls on transient 5xx responses. Event handlers write one small ledger row per change, snapshots are refreshed only for rich fields, bursts are smoothed through an async queue with concurrency limits, and a handler that cannot reach storage parks the event for replay instead of losing it.

Data minimization

Attachment file content is never read. No e-mail addresses are stored. Logs carry work item keys, counts and timings only, never field values, comment bodies or Atlassian error bodies.

Responsible disclosure

Report suspected vulnerabilities privately to support@claervo.com with impact, safe reproduction steps and affected scope. Do not send live credentials or disclose the report publicly before coordination.