Security and daily use - Jira Cloud

Scopes and inheritance

Jira configuration has two levels: account and project. A project with no credentials of its own inherits the instance address, e-mail and token from the account - the same connection serves every project that has no reason to report to a different instance. Dock's internal account additionally has access to the platform configuration: that is the only case where a project with neither its own nor an account configuration falls back to settings a superadmin typed in. Subscribers never see the platform configuration - the same boundary as with Slack, Mattermost, Discord and Notion.

Who has access

The Jira screens require the permission to manage projects. Whoever can edit a project in DockRay can also connect or disconnect its Jira integration - there is no separate permission just for Jira, because it belongs to the same responsibility.

The API token and how it is protected

The API token is stored encrypted and never returns to the form - a blank field in the settings does not mean an empty token, it means 'keep the one already saved'. The instance address itself is restricted to public HTTPS addresses on the *.atlassian.net domain, and the Jira project key goes straight into the request path, so only its real shape is accepted:

^[A-Z][A-Z0-9_]*$

Without that rule, a string like ../ typed as the project key would steer the request outside the intended Jira API endpoint.

What goes to Jira, and what never does

The ticket description gets the relevant slice of the stack trace - frames belonging to the client application's own code, or the top of the stack when none exist. What it never gets is local variable values, request headers, user data or the query string - the address is trimmed down to the bare path, because tokens and keys most often travel in query parameters. That is the same boundary that governs the MCP and Notion integrations, since one place in the code decides what leaves an error toward the outside world. 'Occurrences' and 'first occurrence' in the fact list refer to a single day - as much as one row in the error table holds.

A blank field: 'clear' or 'leave unchanged'

Whether a blank form field clears a saved value or leaves it untouched is decided by the settings screen, not by the database write itself. That matters when switching a project from its own credentials to inheriting the account's: clearing the instance address must also clear the old token, so the project actually starts inheriting instead of just looking like it while quietly keeping someone else's token saved.

Rotating the token and people leaving the team

The API token belongs to the Atlassian account that generated it, not to the person who technically filled in the DockRay form. When that person loses access to the Atlassian account or leaves the team, the token has to be regenerated in Atlassian's settings and pasted into DockRay - the integration will not detect this on its own, because from its side the token simply stops working the moment the first request fails. A suspicion that a token has leaked is reason enough to revoke it on the Atlassian side right away, regardless of when someone gets around to updating the configuration in the panel.