Skip to content
Foundation Docs

Jira permission interplay

Foundation never overrides Jira. A lens grant lets you into the lens, but Jira’s own permission schemes decide which rows inside it you can read and which fields you can change. This page explains how the two layers combine and how to reason about unexpected visibility.

Two layers, two checks

Section titled “Two layers, two checks”

Every action in Foundation goes through two checks:

  1. Lens-level role — view, edit, edit generators, or control on the lens. Set by the lens owner in the Share dialog.
  2. Jira-level permission — for example, BROWSE_PROJECTS to read an issue, EDIT_ISSUES to update a field, TRANSITION_ISSUES to change status.

You need both to pass. The strictest of the two wins.

How BROWSE filters rows

Section titled “How BROWSE filters rows”

When a lens loads, Foundation fetches the tree from its own cache, then filters it against Jira’s BROWSE permission:

  • Rows for issues you can BROWSE appear normally.
  • Rows for issues you can’t BROWSE are dropped entirely — you never see the key or summary.
  • If a parent is dropped, its children go with it (a hidden epic hides its stories, even if you’d technically have BROWSE on those stories).

Foundation uses a batch JQL check and caches the result for 15 minutes per user to stay well inside the Jira API rate budget.

How edit permissions gate changes

Section titled “How edit permissions gate changes”
  • Inline edits go through Jira’s REST API as you. If Jira rejects the change (missing EDIT_ISSUES, workflow validator, required field), Foundation shows the exact error.
  • Status changes respect the Jira workflow. You only see transitions you’re allowed to trigger on that specific issue and its current status.
  • Sync Agent execution runs as the user who triggered it. Issues they can’t BROWSE don’t land in the lens.

Common consequences

Section titled “Common consequences”
  • Two users, same lens, different rows. Entirely expected — they have different Jira access. Not a bug.
  • A teammate can view but not edit. Either their lens grant is View-only, or they have View lens access but lack EDIT_ISSUES in Jira. Check both.
  • Sprint changes rejected. Usually the Jira Sprint field is locked on that issue type or workflow.

Fail-open behavior

Section titled “Fail-open behavior”

If Foundation can’t reach the Jira API to check BROWSE, it assumes you have access rather than hiding everything. This keeps the lens usable during transient Jira outages and is re-checked on the next load.

If you need a user to see everything in a lens

Section titled “If you need a user to see everything in a lens”
  1. Grant them the right level on the lens.
  2. Make sure they have BROWSE on every Jira project that feeds the lens.
  3. Wait up to 15 minutes or have them reload the lens twice to bust the group cache.
Section titled “Related”