Jira User License Optimizer

Built around five guarantees, each of which is a property of the code rather than a promise in a document.

1. Users are never deleted. There is no delete action type, no code path that calls the account-deletion endpoint, and no setting that enables one. The app can only suspend directory access, remove a group membership, or revoke a product role — all reversible.

2. Every change is reversible. A pre-change snapshot is captured before each action, and execution refuses to proceed for any account whose snapshot could not be written.

3. Every change is auditable. The audit log is append-only; the repository exposes append, page and listAll and nothing else.

4. Safe mode is the default. Every plan starts as a dry run. Live execution requires an explicit submit, an approval from a different person, and an explicit execute.

5. The ignore list is governed. Entries have an owner, an approver, a reason, an expiry and a review cadence, and move through an enforced lifecycle.

The Forge entity store types integer as 32-bit signed, so every timestamp in this app is epoch seconds, never milliseconds. A single module centralises that so it cannot drift.

A query can range-scan only one index. The scan-user and audit query planners therefore pick the most selective partition available for the supplied filters and apply everything else as post-index filters — and the Users tab states plainly which filters are server-side and which are not.

Scan history is pruned to the most recent N scans (default 12) because each scan stores one row per user.

Who this is forJira administrators for setup, plus whoever they grant a role to. Executing a plan needs an approval from a different person, so it is never a one-person job.

Setup is five steps, and the first one is a credential the app cannot mint for itself: last-active data lives only in the Atlassian Organization API. Until it is supplied, there is nothing to scan.

1. Connect the organization

   On the Setup tab, enter your organization id and an organization API key. The key is validated against the live API before it is stored, and is written to Forge’s encrypted secret store.

   It is never returned to the browser: only OrgApiClient reads it, and the UI only ever sees a masked hint such as ****6789.

2. Review the rules

   A conservative default rule set is seeded on first use. Rules carry conditions, a priority ordering and versioning; disabled rules and validation are covered by the test matrix.

3. Run a scan

   From the Overview tab. Progress is polled and the UI never blocks — scanning is checkpointed and queue-driven, so an organization of 100,000 users is processed a page at a time rather than in one invocation.

   A page that fails is recorded, audited, skipped, and the scan continues. Losing 50 accounts must not cost the other 99,950.

4. Generate a dry run and read the plan

   On the Cleanup tab. Every plan starts as a dry run — that is the default, not a mode you have to remember to choose.

   A pre-change snapshot is captured before each action, and execution refuses to proceed for any account whose snapshot could not be written. No snapshot, no change.

5. Grant roles, so approval is a genuine second pair of eyes

   On the Setup tab. Live execution requires an explicit submit, an approval from a different person, and then an explicit execute.

   requireDifferentApprover rejects self-approval of an execution plan, and an ignore entry cannot be approved by whoever created it.

6. Govern the ignore list rather than accumulating a skip list

   Entries carry an owner, an approver, a reason, an expiry and a review cadence, and move through an enforced lifecycle. Matching, per-status enforcement, the full lifecycle and the self-approval refusal are all covered by tests.

Requests carry Atlassian account IDs, display names and email addresses. The destination is Atlassian’s own admin API, so that data does not leave the Atlassian trust boundary. The credential used is an organization API key the administrator supplies in-app, not Forge’s own.

• Forge scheduled triggers have no cron. Custom schedules are evaluated by an hourly heartbeat against a five-field cron parser, so effective resolution is one hour.
• Jira Cloud JQL has no comment-author predicate, so the “no comments” service-account signal cannot be collected. The scorer treats it as unknown rather than zero, and uses issue authorship as the nearest supported proxy.
• Free-text, product and group filters are not indexable and are applied to the returned page. The Users tab states this rather than implying a server-side filter.
• Exports are capped at 25,000 rows and report when they were truncated.
• Project-role enumeration costs projects × roles requests, so it is built once per scan and shared, bounded to 100 projects.
• Per-user enrichment is budgeted to the first 40 accounts per page; the rest use list-response summary data.

Version history for Jira User License Optimizer. The most recent release is listed first.

1. v1.0.0 Current

   Initial release.

   What it does

   • Inactive-seat detection across the organization, with a billable-path breakdown per user.
   • A configurable, versioned rule engine with priority ordering and a conservative seeded default set.
   • A governed ignore list with owner, approver, reason, expiry and review cadence, moving through an enforced lifecycle.
   • Dry-run plans, a separate-person approval step, live execution, and rollback — all queue-driven and checkpointed.
   • An append-only audit log, CSV export with formula-injection neutralisation, and a recommendation engine that reports confidence and expected savings.

   Safety

   • No deletion is possible: there is no delete action type and no code path to the account-deletion endpoint.
   • Execution refuses to proceed for any account whose pre-change snapshot could not be written.
   • Self-approval is rejected for both execution plans and ignore entries.
   • The organization API key is validated before storage, written to the encrypted secret store, redacted from logs, and never returned to the browser.

   Platform work

   • Epoch seconds throughout, because the entity store’s integer is 32-bit signed.
   • Query planners that select one range index and apply remaining filters after it, because the platform allows only one.
   • An hourly heartbeat plus an in-app cron parser, because Forge scheduled triggers have no cron interval.
   • Two scheduled triggers used of the platform’s five; the weekly digest self-paces inside the daily one.