Privacy policy

Who we are

JCB2 Consulting LLC provides ColumnFit for Jira.

What the app is

ColumnFit for Jira displays selected Jira issue fields in a dashboard gadget table and lets the dashboard author configure the query, fields and display settings.

What data the app reads

The app reads host context and gadget configuration, Jira field metadata, and selected issue fields. Requests run as the current viewer; Jira filters issue and field results before they reach the app.

While the dashboard author edits a saved-filter source, the app also lists saved filters: it sends the filter name the author types to Jira’s filter search and reads the author’s favourite filters, keeping only each filter’s ID and name. When the configured source is a saved filter, or the query names one, and the first page returns no issues, the app asks Jira to check the query with strict JQL parsing. These requests also run as the current viewer.

Configuration includes a JQL query or saved-filter ID, ordered field IDs, schema version, page size, density, overflow choice and column width/content settings. Query literals can contain personal or confidential data.

The app reads field names and schema, issue IDs and keys, and requested field values such as summaries, status, labels, dates, numbers, users, URLs and rich text. These can contain personal data, account IDs or names, confidential business information and user-authored URLs.

It also reads pagination tokens and last-page flags, Jira site URL, locale, entry point, Jira error messages and host design tokens. The view surface shows fixed error text; the edit surface can show up to two lines of Jira error detail containing query or business context.

Where data goes

Queries, selected field IDs and pagination tokens go to Jira enhanced search through the Atlassian bridge. Field metadata and issue results reach the field picker, headings and table in the viewer’s browser.

Typed filter names go to Jira filter search, and a query checked for a saved filter goes to Jira’s JQL parser, both through the Atlassian bridge. Saved-filter names and IDs reach only the edit view’s filter picker.

The app has no backend, remote service or analytics. App code transfers no data outside the Atlassian boundary and declares no remote or external permission.

Clicking an HTTP(S) field link navigates your browser to the field-supplied destination, which receives ordinary browser request metadata. This is an explicit viewer navigation.

What the app stores

Jira stores the gadget configuration. The app has no storage outside Jira and creates no second copy of that configuration. The configuration contains no issue response rows.

Issue rows, field values, field catalog, pagination tokens, errors and user profiles are not persisted by the app. There is no per-user state, browser persistence, app database, Forge storage or module-level user-data cache, and the app uses no cookies.

Issue content and metadata exist transiently in component state and the authorized viewer’s DOM. Display text in truncated and off-screen cells remains in that DOM; CSS visibility is not a privacy boundary.

Retention

Jira controls configuration retention, dashboard permissions, residency, backup and deletion. Configuration remains until the author changes or removes the gadget or Jira applies its retention policy.

Transient field metadata, issue results, pagination state and host context last for the iframe lifetime; field metadata is gone on reload. Rendered field content remains until rerender or reload, and errors remain until retry, rerender or reload.

Saved-filter names and IDs last until the filter picker reloads or the iframe closes. A JQL check’s errors are kept like other Jira errors.

Logs

The vendor has no telemetry path in the app source. Jira errors appear transiently in the interface and are not persisted by the app.

App code writes no logs: the app source makes no console, browser-storage or cookie call and includes no telemetry or error-reporting library, so the app logs none of the data it reads. Atlassian operates its own platform logs for the host and Jira REST APIs; this policy does not describe them.

Third parties

Jira/Atlassian operates the host, bridge, REST APIs and configuration store. The vendor has no remote service or telemetry path.

The Atlassian host picker fetches a pinned icon from developer.atlassian.com; app code fetches nothing for that thumbnail. User-clicked field links can take your browser to other destinations, which receive ordinary browser request metadata.

Your rights and data controls

You can access the Jira data returned to your viewer-scoped bridge requests and the resulting DOM. Dashboard authors can access and change gadget configuration in edit mode; dashboard viewers receive that configuration as host context.

Jira controls backup, retention and deletion of stored configuration. The app keeps no separate persistent copy of issue content or user profiles.

The data map does not determine statutory privacy rights or the vendor’s legal role under privacy law.

Changes

This policy describes the data handling recorded in the app’s privacy data map; that map does not specify a policy-change notification process.

Contact

For questions about this policy, contact security@jcb2consulting.com.