AuditPack for Jira Service Management documentation

Requirements

• Jira Service Management Cloud and at least one service project you can browse.
• AuditPack appears as a page in each Jira Service Management project’s sidebar, fixed to that project, and as a global page under Apps where you pick any service project you can browse.
• AuditPack is a paid app sold through the Atlassian Marketplace. Building a pack requires an active licence in production; a missing or inactive licence blocks it. The licence is checked on every backend call.
• Approvals and SLA data appear only if you are allowed to read them. SLA data needs agent access.
• A browser that allows downloads from your Jira site.

Build a pack

• Open AuditPack from the project sidebar, or from Apps for the global page, and choose the service project if the page asks for one.
• Choose the date to filter on: created, resolved or last updated.
• Set the from and to dates. The range can be at most 24 months.
• Choose what to include: change requests only, or every request.
• For change requests only, choose which issue types are change requests. Types named like “change” are preselected.
• Optionally adjust the rules: the implementation statuses and the approval-by-status-change switch described below.
• Build the pack, then download the PDF report, the gap-report CSV or the ZIP. Your browser builds each file locally and saves it to your device. Closing the page discards the pack.

Gap rules

Each gap states the evidence it rests on. A gap is a fact to explain, not a finding of non-compliance.

• Change without an approval: Jira recorded no Jira Service Management approval step for the change. The severity is high if the change reached an implementation status and medium otherwise.
• Approved after implementation started: an approval was completed after the first transition into an implementation status.
• Implementation started while the approval was pending or declined.
• Approved by the person who raised the change: the approver is the reporter or the creator.
• No linked incident: none of the linked issues is of an incident type.
• Evidence that could not be read: Jira refused a read for that issue, so the pack is incomplete there. This is shown as an info row.

Implementation statuses and the approval switch

Implementation statuses are matched by part of the status name. The default list is implementing, implemented, in progress, deploy, validating, completed and done, and you can edit it.

An optional switch, off by default, counts a status change out of an approval status (default names: approval, peer review) as an approval. It is meant for workflows that approve with an Approve or Decline transition. These approvals are inferred from the status history, because Jira’s history records statuses and not the transition name, so an emergency override that leaves the same status would also count. They are labelled “status change” in the pack.

What is in the files

• The PDF report presents the pack and its gaps. Its cover shows the fingerprint of evidence.json. For comments it shows the first 700 characters.
• The gap-report CSV lists the gaps and the evidence each one rests on.
• The ZIP holds one CSV per evidence type (change requests, approvals, status history, comments, attachments, linked issues and SLA outcomes) plus evidence.json, README.txt and SHA256SUMS.txt. SHA256SUMS.txt lists the SHA-256 checksum of every file.
• Comments are marked public or internal. The CSV and JSON files hold the full comment text, up to the cap described under Limits.
• The attachment list holds file names, sizes and types. Attachment content is never included.
• People appear as Atlassian account IDs and display names. A pack contains no e-mail addresses and no avatars.

Permissions

AuditPack requests exactly two read-only scopes. Every Jira read runs as the signed-in person (Forge asUser), so the pack contains only what that person may see. The app never calls asApp and does not write to Jira.

• read:jira-work to search requests and read comments, status history, attachment metadata, links and permissions.
• read:servicedesk-request to read approvals and SLA data.

Limits

• At most 1,000 issues per pack. Narrow the date range to cover more; the pack says when it was cut.
• A date range of at most 24 months.
• At most 500 comments read per issue. Comment text is capped at 20,000 characters, and the description at 4,000 characters.
• Jira records one completion time per approval step, not one per approver.
• SLA data and approvals need the viewer to be allowed to read them; SLA data needs agent access. What cannot be read is reported as a gap, not hidden.
• The PDF uses DejaVu Sans (Bitstream Vera licence), which covers Latin, Latin Extended (including Turkish), Greek and Cyrillic. Other scripts print as “?” in the PDF, while the CSV and JSON files keep the original text.
• Attachment content is not included, and custom fields beyond the standard issue fields are not included.
• AuditPack does not write to Jira.

Troubleshooting

• A licence banner appears and the pack will not build: building a pack requires an active licence in production, and a missing or inactive licence blocks it. Ask your Jira site administrator to check the app’s licence, then try again.
• “No access to the project”: every read runs as you, so you can build a pack only for a project you can browse. Ask a project administrator for access, or choose another project.
• The pack is empty: check the date to filter on (created, resolved or last updated), the from and to dates, and whether you chose change requests only with the right issue types. Widen the range or include every request.
• “Evidence could not be read” info rows: Jira refused a read for that issue, so the pack is incomplete there. Approvals and SLA data need permission to read them, and SLA data needs agent access. Ask someone with that access to build the pack, or treat those issues as incomplete.
• The PDF shows “?” for some characters: the PDF covers Latin, Latin Extended, Greek and Cyrillic. The CSV and JSON files keep the original text.
• A download is blocked: the files are built in your browser, so allow downloads for your Jira site in the browser’s site settings and build the pack again.
• The pack says it was cut: it holds at most 1,000 issues. Narrow the date range and build again.

Data handling summary

The application stores nothing. Jira data passes through a Forge function in memory for the length of each request and then to your browser, which builds the files locally. There are no external network calls, and nothing is written to logs. The application privacy page has the full statement.

Atesen Software security policy