Atlassian Marketplace
For Ganttry Lite, the free edition of Ganttry, built from the same code. A Forge app with no servers behind it has little to disclose, and the part that is not short is the list of everything it can do to your Jira, which is the answer a review actually needs.
Ganttry Lite uses Atlassian Forge for application compute and storage. We operate no separate customer-data backend. Deployment access and support handling remain our responsibility.
Runs on Atlassian, checked 15 October 2026
$ npx forge eligibility --environment production
The version of your app [2.0.0] that's deployed to [production] is eligible for the Runs on Atlassian program.Recorded from Forge CLI against Ganttry Lite's production environment; the result applies to that exact deployed app version.
These are Atlassian's controls, not ours, and saying so is the point. A small studio claiming to have implemented its own encryption at rest is a claim worth less than the platform's, and it is the sort of thing a reviewer checks.
Encryption
Forge app storage encryption at rest and transport TLS are provided by Atlassian.
Interactive authentication
There is none of ours. The person looking at the chart is whoever Atlassian says is signed in to the site. We issue no credential, store no password, and have no login of our own that could be phished or reused.
No integration API
Ganttry Lite registers no web trigger, so nothing outside your Jira can call it. Every request it serves comes from a signed-in person in Jira.
Tokens
No personal access token, API token or OAuth credential of yours is asked for, entered anywhere, or stored. Ganttry Lite talks to Jira through Forge's own product API, which carries the signed-in user's identity for us.
Access by us
There is no customer-support impersonation feature or separate vendor customer-data database. Authorized Forge contributors can access platform tooling and logs subject to Atlassian roles and customer log-sharing controls. Deployment access and any support files you send are governed access, not a claim that developer access is impossible.
Everything above is about the platform Ganttry Lite sits on. This is the part a review actually came for. The numbers below are Ganttry's, read from its test suite against the real manifest and the real source, less the calls that only the features Ganttry Lite closes make. Last checked 15 October 2026.
5
Scopes
17
Read endpoints
8
Write calls
over 7 endpoints
A sixth is not an implementation decision. Adding one makes the next deploy a major version, and a major version reaches nobody until each customer's admin approves the new permissions by hand — which is the protection this app is built on, pointed at us as much as at you. Nobody is upgraded quietly, including by us.
read:jira-workEverything the chart is built from: issues, their dates, estimates, links, sprints and fix versions. What it costs: A read of the work in projects the person opening the chart can already see.
write:jira-workPublishing reviewed dates, and issue, status, assignee and dependency changes, back to Jira. What it costs: Jira has no scope meaning “may edit two date fields”, so this one permits every field on every issue. What narrows it is our test, not Atlassian's gateway.
manage:jira-projectChanging a chart project's name, description or lead from an explicitly saved project form. What it costs: Wider than what is used. Ganttry Lite sends only a project's name, description and optional lead account id. It never creates or changes versions, components, roles, schemes or other project configuration. Jira's classic scopes have nothing narrower; the granular set does, and a manifest cannot mix the two.
read:jira-userThe names and account ids of people who may be assigned work in a project the chart is drawn from, so the assignee menu can offer them. What it costs: A directory read. Ganttry Lite already receives these names — every assigned issue carries one — so what this adds is offering them before the fact rather than reporting them after it.
storage:appGanttry Lite's own storage: baselines, the bars you moved, the working calendar, the record of what was published. What it costs: Nothing in Jira. It grants access to this app's data and to no issue.
Ganttry Lite uses Jira's permission schemes rather than keeping a second list of roles that can drift when somebody changes team or leaves the company.
View
Anyone Jira allows to browse the underlying work may view it in Ganttry Lite. Every Jira read is made as the signed-in person, so Jira remains the boundary.
Edit a shared plan
Edit Issues and Schedule Issues are required in every project represented by the plan. If either permission is missing in one project, the shared plan is read-only.
Change a chart's source
A JQL or filter source has no bounded project set before it runs, so changing a chart to one is Jira-administrator only.
Checked behind the screen
The resolver checks these permissions on the server before Forge storage is changed. Hiding a button is not treated as authorization, and a direct resolver call reaches the same check.
8 calls over 7 endpoints. Not a summary of them — this is the list, and there is nothing under it. Every one is made as the signed-in user, so your own Jira permissions decide before the app is involved, and a test fails the build if a 9th appears.
/rest/api/3/project/{projectKey}Changes only a chart project's name, description and optional lead account id after an explicit save. It never changes the project key, components, roles, schemes or other configuration.
/rest/api/3/issue/{key}Sets the start date and the due date on an issue ticked in the publish dialog. One request per issue, and no other field.
/rest/api/3/issue/{key}Deletes one issue that is on the chart, after a dialog naming it. See below — this one is stated rather than buried.
/rest/api/3/issueFallback sub-task creation sends a summary, type, optional parent and the two dates in a chart project. Standard creation opens Jira's native form, which can collect its required custom fields and attachments; Ganttry Lite makes no app-owned attachment REST write.
/rest/api/3/issueLinkCreates a link between two issues that are both on the chart.
/rest/api/3/issueLink/{linkId}Removes a link, by the link id Jira gave it. The id is checked as digits before it becomes a path.
/rest/api/3/issue/{key}/transitionsMoves an issue through one of the transitions Jira itself offered for that issue and that person, by an id from that list. The body carries the transition id and no fields.
/rest/api/3/issue/{key}/assigneeAssigns an issue by account id, or to nobody. By id and never by name: two people on a site of any size share a display name.
The transition is the widest of these
A transition runs your own workflow. A workflow can send mail, fire a post-function or close a parent, and nothing in Ganttry Lite can take that back. What is true is that it can only make a move the person could have made by hand, because the list it chooses from is Jira's own answer for that issue and that user.
Undo depends on the operation
Creating and deleting an issue have no in-app undo, and neither has a bulk form. Date publishing and dependency edits expose limited undo where the interface offers it. Other changes may require another explicit Jira edit and may not be reversible: workflow transitions, assignee changes and project edits do not carry a blanket rollback guarantee.
Carried, and refused
Ganttry Lite is built from Ganttry's code, so the code for Ganttry's other six writes — creating and changing versions, moving issues to a sprint or the backlog, setting the Team field and ranking — ships in it too. Its server refuses every request that would reach them, decided by the app's own id rather than by anything the browser sends, and a unit test fails if one of them opens. The same holds for the three reads only those features make.
True because of the shape of the code rather than because of a test guarding it. There is no code path that does these things, so there is nothing to get wrong.
It is on the list above and it deserves more than a line there. A competitor in this category deletes Jira issues when a project is removed from a view, its listing says nothing about it, and its reviews are where customers found out. So: Ganttry Lite can delete an issue. One at a time, from a dialog that names it, and here is everything standing between that and a bug.
And the part that is uncomfortable to write
Four of those five are our code, and code can be wrong in a way an arithmetic cannot. Ganttry used to have one DELETE, it reached one path, and that path took a link id — no argument it could be handed, mistyped or crafted, would delete an issue, because Jira's endpoint for a link cannot address one. That was not a check, it was arithmetic, and it is gone. The guarantee that replaced it is real and is a weaker kind, and the difference is what anyone asking what this app can do to their data should be told.
If your review would rather the capability did not exist, say so. It is one dialog, and we would rather know that than find out from a renewal.
Every app in this category says it is safe. The difference worth asking about is what happens on the day somebody adds a feature that quietly is not. In Ganttry Lite that day fails the build, and here is each thing that fails it.
The scope list is counted
A test reads the real manifest and asserts the scopes by name and by number. Adding one fails the build, so it becomes a deliberate act with somebody's name on it rather than a line that appeared in a diff.
The endpoint list is counted
The same test reads the shipped source, extracts every call to Jira with its verb and path, and fails if one appears outside the canonical machine-readable trust inventory. Ganttry Lite ships that same source.
Every Jira call is made as you
The test asserts that every Jira call site is made as the signed-in user, with one named exception: the Confluence macro's read-only subscription check, which Ganttry Lite has no macro to make. Your own Jira permissions decide what a write is allowed to do, before the app is involved.
The bodies are pinned, not just the endpoints
Holding a write scope permits every field on every issue, so the test also checks what is actually sent: which fields a date write assigns, that a transition carries an id and no fields, that an assignee carries an account id and nothing else. Widening a body fails the build the same way a new endpoint does.
Nothing can reach outside Atlassian
The test asserts that no shipped source file contains an outbound URL, and that the one module naming an XML namespace — which is an identifier, not an address — cannot make a request at all.
What Lite closes is counted
A unit test pins every entry point and server resolver Ganttry Lite closes, and checks that Ganttry keeps them. Reopening one in Ganttry Lite fails it.
None of that is a promise about our intentions. It is a promise that a change of intention cannot ship quietly: the test has to be edited, by hand, by somebody who then has to write down what they gave up.
Security contact
security@plugthatapp.comSend it to the address above. It reaches a monitored inbox and it reaches a person, not a form.
You get a reply
Within four business hours, which is the severity 1 first-response target on our published SLA. We do not offer a faster number here, because a second commitment beside a specific one is how both stop meaning anything.
We tell you what we think it is
Confirmed or not, with the reasoning. If we disagree that it is a vulnerability we will say why rather than going quiet.
We fix it and ship it
A confirmed vulnerability is treated as severity 1: a fix or a written workaround within 48 hours of us confirming it. Forge deploys reach every install without an upgrade unless the fix needs a new scope, and we will tell you if it does.
We tell Atlassian, and we tell the people affected
Atlassian is notified through the Marketplace security process. If customer data was reachable, affected sites are told directly — what happened, when, and what it touched.
Those times are the ones on our service level agreement, which is published, versioned and dated. We deliberately do not offer a faster number on this page: a second commitment beside a specific one is how both stop meaning anything.
Report something in good faith and we will not pursue you for it. Test against your own site or a free Atlassian instance, not somebody else's; do not run anything that degrades a service or reaches data that is not yours; and give us a chance to ship a fix before publishing. We have no bug bounty and no budget for one — we would rather say so than run a programme we cannot pay out on. Credit in the release notes is offered, and declined as often as it is taken.
The response process follows Atlassian's Marketplace app security incident guidance. It applies to a suspected incident as well as a confirmed breach, because evidence has to be preserved before the conclusion is known.
A documented response plan
The internal runbook covers severity, named response roles, evidence preservation, containment, remediation, recovery, customer and regulatory communication, and a post-incident review.
Atlassian is notified within 24 hours
A security incident involving the Marketplace app is reported to Atlassian promptly and no later than 24 hours after awareness. During active containment, Atlassian receives an update at least every six hours.
Affected customers are told
When possible, affected customers are notified within 72 hours of identifying an incident. A shorter legal or contractual deadline always takes precedence.
Operational details stay restricted
Responder phone numbers, recovery credentials, evidence locations and containment procedures are kept out of this public page. Security reports go to the monitored address below.
A review checklist has questions this answers with a no. Answering them here is cheaper for both of us than a follow-up email, and a page that quietly omitted them would earn one.
A term is never edited in place. When one changes, the version goes up and the change is written here, so a reviewer who cited a version can see what happened to it.