Security and organization access

Customer imports belong to an organization and project. Access is controlled by membership and role, rather than by hiding dashboard links.

What protects organization boundaries?

The application uses Supabase Auth and database row-level security policies. The supplied migrations restrict organization records to members and restrict changes by role. These protections depend on the deployment applying the migrations and preserving those policies. Customer Jira data is not included in public pages or the public sample project.

Who can access imported work?

Organization members can read their organization’s data. Owners and admins manage projects and deletion; members can import; viewers have read access. The operator of the Supabase service has administrative database access. Organization membership is not a substitute for minimizing sensitive fields before import.

Roles and what each can do

RoleCanCannot
OwnerEverything an admin can, plus delete the organization and grant or remove ownershipLeave the organization without another owner in place — an organization always keeps at least one owner
AdminManage projects, Jira configuration and members; delete imports and project dataGrant, remove or demote ownership
MemberRead the organization’s data, import Jira CSVs and edit field mappingsManage projects or Jira connections, or delete imports
ViewerRead the organization’s dataChange anything

Why a changed browser request cannot reach another organization

Organization boundaries are enforced by the database, not by the dashboard. Every organization table has row-level security, so a query without any filter still returns only the rows of organizations the signed-in user belongs to. Records are linked with keys that include the organization, so a row cannot be attached to another organization’s project by editing an identifier in a request. The browser only ever holds the public, low-privilege database key; the application refuses to start if a privileged key is configured for the browser.

Jira credentials

Jira data is imported from a CSV export. The Jira connection record stores the site address and connection type, never an API token or password. Any future API token or OAuth connection is designed to keep its secret in a separate secret store that browser roles cannot write to.

How isolation is tested

The database migrations run in an automated test suite that signs in as different users and tries to cross organization boundaries: unfiltered queries, forged organization identifiers, updates and deletes against another organization, adding oneself to another organization, anonymous access and role escalation. Each of these must return nothing or be rejected. Deletion is tested too: deleting an import, project or organization removes exactly its own data.

What is outside this guarantee?

Browser storage is available to people using the same browser profile, and extensions may read pages. Exported reports are ordinary files under your control. This project does not claim SOC 2 certification, an independent security audit, or a service-level agreement.

Before importing company data

Check your company’s authorization to use this deployment, review organization membership, and omit unnecessary descriptions or personal information. Review the deployment’s authentication providers and database configuration with its operator.

Usage analytics and your choices

Product events measure signup, import and first analysis with allowlisted categories. They exclude Jira content, organization names and email addresses. Google Analytics may use browser identifiers; these events should not be described as anonymous. You can opt out on the privacy page. Ads appear on educational content, not in the workspace.

Privacy and local deletion controls · Data storage and deletion details · How analysis uses your data

Start with data you are authorized to use

Create your account, set up an organization and project, then import a Jira CSV. You can explore the synthetic sample first.

Create free account