Privacy Policy — Ditto: Bulk & Deep Clone for Jira
Effective: 8 September 2026
Ditto: Bulk & Deep Clone for Jira ("the app") is published on the Atlassian Marketplace
by Two Little Moons Consulting, ABN 49 732 400 198, Penrith, NSW 2750,
Australia ("we", "us"). Contact: support@twolittlemoons.com.
This policy is specific on purpose: every category of data the app touches is itemised
below.
What the app does
The app copies Jira work items — one with everything under it, or many at once from a
search — into the same or another project, including across the boundary between
team-managed and company-managed projects. It runs entirely on Atlassian's Forge
platform and sends data to no server outside Atlassian.
Data the app reads from Jira
When you preview or run a clone, these reads happen as you, with your own Jira
permissions and never with elevated rights:
the work items you selected and, if you asked for them, the work items beneath them:
key, id, summary, description, issue type, project, parent, priority, labels,
components, versions, due date, assignee and reporter account ids, sprint membership,
and the values of every other field on them;
the names and types of those fields, which is what makes matching them to a different
project possible;
the list of attachments on those work items — filename, size and content type — and,
while a job is running, the content of the attachments being copied;
the links and web links on those work items;
the target project: its issue types, the fields on its create screens, the values
those fields allow, and its board and sprints where the app is permitted to read them;
the projects you may create work items in, to populate the target picker;
your own account id and display name (/myself), recorded on the job as who ran it;
your permissions in the projects involved (/mypermissions), to decide whether to
allow the clone at all.
Data the app writes to Jira
the copies: new work items in the target project, with the field values, links,
web links and attachments described above;
an entity property called ditto-clone on each work item the app creates, holding the
job id, the key and id of the work item it was copied from, a timestamp, and a short
non-reversible digest of the pair. This is what makes a repeated or interrupted job
safe to re-run, and it is what dittoJob = "…" searches in JQL. It contains no
personal data.
Data the app stores
In Atlassian Forge storage, inside your own Atlassian site, and nowhere else:
job records: the job's id, when it was created and last updated, the account id and
display name of the person who ran it, the work item keys it started from, the target
project, the options chosen, counts and progress, the notes and failures described
above, and a short history of its runs;
job plans: for each work item to be copied, the field values that will be written.
Because a plan holds field values taken from your work items, it may contain any data
those fields contain, including personal data you have put in them.
Both are deleted when you delete the job from the app's job list, and both are destroyed
by Atlassian when the app is uninstalled.
Data the app does not do
It does not send anything to any server outside Atlassian. The app declares no
external permissions of any kind: no fetch, no egress, no remote backend, no
analytics, no third-party service.
It does not store attachment content. Attachment bytes pass through the app's
Forge function from the original work item to the copy and are not retained.
It does not use your data to train anything, and it contains no AI or machine
learning component.
It does not read work items you cannot read. Every read is made with your own
permissions.
The one thing the app does with its own privileges
A clone runs in the background so that a large job is not tied to a browser tab. Forge's
background workers have no signed-in user, so that part runs as the app rather than as
you. It is confined:
the job is authorised before it is created, in a screen that does have you signed
in: your permission to create work items in the target project is checked, and the
work items to be copied are read as you, so anything you cannot see never enters
the job at all;
the background worker executes only that stored plan. It takes no instruction from
anywhere else, and it cannot be pointed at a different project;
field overrides are restricted to fields the target project's create screen actually
offers, and a fixed list of privileged fields — reporter, issue security level, project,
issue type, parent — can never be set this way.
Data residency
The app stores end-user data exclusively within Atlassian apps and services, in the
Forge storage of your own site. It therefore follows whatever data residency your
Atlassian site is configured for. We operate no storage or processing of our own.
Retention and deletion
Job records and plans live in your site's Forge storage until you delete the job, or
until the app is uninstalled, at which point Atlassian destroys them.
The ditto-clone property lives on the work items the app created, and is yours: it is
removed if you delete those work items.
We hold no copy of any of it, so there is nothing for us to delete on request. A
request to erase data should be made to the administrator of your Atlassian site.
Roles
Under GDPR we act as a processor; you are the controller. Under the CCPA we act as a
service provider. We engage no sub-processors: the app has no infrastructure beyond
Atlassian's.