Settings
Admin-controlled feature toggles, thresholds, and operational preferences. Per Jira instance.
Overview
How Attachment Architect handles your data
Attachment Architect is a Jira Cloud app published by drinkits. It runs entirely inside the Atlassian Forge sandbox. The app is designed to help Jira users find files and help Jira admins govern attachment storage, without moving your data out of Atlassian.
This notice explains what the app processes, what it stores as Forge app data, what it deliberately does not store, who can access what, and how to contact us about privacy.
Platform
Built on Atlassian Forge
The app runs in Atlassian Forge. Forge functions execute in Atlassian-managed runtime, app data is stored in Atlassian-managed storage (Forge SQL and Forge app storage), and front-end resources are served from Atlassian's CDN. The hosting boundary is Atlassian's standard Forge boundary for your Jira Cloud instance.
The app does not run servers outside Atlassian, does not store your data on third-party infrastructure, and does not transmit attachment content to external endpoints.
Data categories
What we process
When the app is installed and used, it processes the following categories of data inside Jira and the Forge runtime.
| Category | Examples | Source |
|---|---|---|
| Attachment metadata | Filename, size, MIME type, created date, uploader account, parent issue and project | Jira REST API |
| User identifiers | Atlassian account IDs, display names, group/role membership for permission checks | Jira REST API |
| Project and issue metadata | Project keys, issue keys, statuses, assignees, dates | Jira REST API |
| License state | Active, trial, or inactive status; trial counters for fair-use limits | Atlassian licensing API |
| App configuration | Admin settings such as activity panel toggle, OCR publishing, security scanning, thresholds | Jira admins via the app |
| Attachment content | File bytes accessed transiently for preview, OCR, download, or security-signal scanning | Jira REST API on demand |
App storage
App data we store
The app stores the following data inside Atlassian-managed Forge storage so the product can work between sessions.
Folder metadata
Personal folder names, dates, item counts, and the attachment IDs saved into each folder. Per user account.
Scan indexes
Attachment metadata captured during admin scans: filename, size, MIME, content-derived hash, uploader, parent issue and project, plus computed analytics fields. Per Jira instance.
Audit and activity metadata
Records of admin actions such as scans, deletions, settings changes, and OCR publishing events.
Scan and export artifacts
Snapshots produced by scans and CSV exports requested by admins.
Operational state
Job queues, rate-limit counters, and short-lived caches required for the app to run reliably.
Boundaries
What we do not store
- The raw bytes of your Jira attachments. Scan indexes are metadata-focused. File content is accessed only when a user opens a preview, downloads a file, runs OCR, or when an admin-enabled scan inspects a file for security signals.
- Jira issue body content. The app does not index issue descriptions or comments.
- Authentication credentials or session tokens. The app uses Atlassian Forge identity and Jira permissions.
- Personal data outside Jira. The app does not import or enrich data from external sources.
Transient access
When the app accesses attachment content
Attachment file bytes are read on demand for specific workflows. Reads happen in the user's browser session or inside a Forge function. Content is not retained beyond the workflow.
Preview
When a user opens a supported file in the preview modal. Preview rendering happens in the browser.
OCR
When a user runs OCR on an image preview. OCR runs in the browser via bundled WebAssembly. Extracted text is held in the browser session.
Download
When a user downloads a file or a ZIP of multiple files. Bytes pass through Jira's download flow.
Archive inspection
When the Archive viewer lists or previews items inside a ZIP, TAR, or GZ archive.
Security scanning
When admin-enabled scanning evaluates file content patterns. Inspection happens inside a Forge function. Findings are stored as review signals.
Opt-in features
Optional admin-configured features
Some features change how data flows. They are off by default and configured by Jira admins in app Settings.
OCR publishing to Jira comments
When enabled, users can publish OCR-extracted image text to a Jira comment, making image text searchable with JQL. The app uses one structured comment per attachment.
Real-time security scanning
When enabled, new uploads trigger a security-signal scan. Findings are stored as review signals for admins; this feature is not a DLP system.
Attachment Activity panel
When enabled, an issue-context panel shows deletion and activity history for issues where the app has activity data.
Auto-Pilot scans
When configured, scheduled daily or weekly scans run automatically and refresh the admin attachment index.
Permissions
Permissions and data access
Attachment Architect uses Jira and Forge scopes for Explorer, previews, scans, analytics, OCR publishing, and cleanup workflows.
read:jira-work
Reads Jira issue and attachment metadata for Explorer, Issue Panel, previews, scans, analytics, admin reports, and exports.
read:jira-user
Shows user names in filters, attachment metadata, uploader information, audit history, and admin analytics.
write:jira-work
Supports confirmed attachment deletion and optional OCR publishing to Jira comments.
storage:app
Stores app settings, folder metadata, scan indexes, audit/activity metadata, scan/export data, and operational app data inside Atlassian-managed Forge storage.
Attachment Architect does not silently delete attachments. Cleanup actions require confirmation, respect Jira permissions, and destructive actions such as deletion are blocked for inactive licenses.
External services
Third parties
Attachment Architect does not use external sub-processors for processing your Jira data. The app does not call third-party analytics, telemetry, AI inference, or storage services from the user's browser or from Forge functions.
The Atlassian Forge platform itself is operated by Atlassian and handles runtime, storage, and event delivery on your behalf as part of the Marketplace app model.
Lifecycle
Data retention
| Data | Retention |
|---|---|
| Scan indexes | Replaced by each new scan. Cleared on admin Factory Reset. |
| Audit and activity records | Retained until admin clears them or runs Factory Reset. |
| Folder metadata | Retained until the user deletes the folder or the app is uninstalled. |
| Trial counters | Retained for the duration of the trial. |
| Operational state | Short-lived job state, queue entries, and rate-limit counters are recycled automatically. |
| All app data | Removed when the app is uninstalled from the Jira instance, following Atlassian's standard Forge data lifecycle. |
Controls
Your rights and controls
Most controls live with Jira admins of your Atlassian instance and with the data controller of your organization. The app supports the following actions directly.
Inspect
Admins can open Mission Control, Audit Log, Settings, and the Permissions section of the User Guide to see what is configured.
Export
Admins can export scan data and audit history as CSV. Users can export current Attachment Explorer results.
Delete app data
Admins can run Factory Reset in Settings to clear app data. Uninstalling the app removes all Forge app data per Atlassian's standard process.
Limit who can see what
Standard Jira permissions control which attachments each user sees and which actions they can take.
Defence in depth
Security measures
- Runs inside the Atlassian Forge sandbox with platform-level isolation.
- Content Security Policy with documented carve-outs for bundled WebAssembly OCR and Web Workers.
- HTML output sanitized with DOMPurify in Markdown, EML, and KML viewers.
- SQL access uses Forge SQL prepared statements plus an additional input guard layer (LIKE-pattern escaping, sort-column whitelisting, pagination clamping).
- Rate limits on deletion and OCR endpoints, with per-user, per-attachment, and global windows.
- Error boundaries wrap lazy-loaded routes so a single component crash cannot break the admin page.
- Archive and XML inputs use decompression-bomb and entity-expansion protections.
Updates
Changes to this notice
This page is the authoritative privacy notice for the Attachment Architect Jira Cloud app. Material updates will be reflected here. The Marketplace listing always points to the current version.
Contact
Privacy contact
For privacy questions, data-handling requests, or to report a concern, use the support portal. Include the Jira site URL and a short description of the request.