# Permission mode

Permission mode decides **whose permissions the picker searches with**. It is set per
field context, alongside the [JQL scope](../jql-scope/), and it is the setting with the
largest consequence in the application.

There are two modes.

| Mode | The picker searches as | Effect |
|---|---|---|
| `RESPECT_USER` | the person using it | They see only work items they could already browse. **The default, and the recommendation.** |
| `IGNORE_USER` | the application | They can select work items they cannot normally browse. |

**A field context you have created but not configured uses `RESPECT_USER`.** The
permissive mode is never reached by leaving a setting alone: widening what the picker
can see is something an administrator chooses deliberately, in a context they opened on
purpose. This page said which mode was recommended but never said which one you get by
default, which is the question a security reviewer asks first.

## `RESPECT_USER`

The picker runs the JQL scope as the viewer. Jira's own permissions apply first, so the
candidate list is the intersection of the scope and what that person can already see.

This is the right choice unless you have a specific reason to need the other one.

## `IGNORE_USER`, and exactly what it exposes

<Aside type="caution" title="This lets people select work items they cannot browse">
Under `IGNORE_USER` the search runs with the application's permissions. A person can
therefore select a work item they have no permission to open.

**What they see of it is exactly the columns the administrator configured, and nothing
else.** They cannot open it, they cannot read its comments, and no field outside the
configured columns is transmitted to their browser.
</Aside>

This mode exists because the alternative is often worse. A support agent often needs to
mark a request as blocked by an engineering work item in a project they have no access
to. Without `IGNORE_USER` they cannot record the dependency at all, and the
usual workaround is granting them browse access to the whole engineering project, which
exposes far more.

**The JQL scope is the control here.** Under `IGNORE_USER` the scope is the only thing
bounding what can be selected, so write it narrowly and choose the columns
deliberately.

## Both modes apply on the portal

Jira Service Management portal customers get whichever mode the administrator
configured, including `IGNORE_USER`, on the portal request and portal view surfaces.
Portal customers hold no Jira application access, which is why the application declares
`read:servicedesk-request`: it is the one surface a customer can call as themselves.

**Anonymous visitors are always restricted**, whatever the mode says, because those
requests carry no account at all.

## Choosing

Ask what happens if the answer is wrong in each direction.

- If a person selecting a work item they cannot open would be a problem, use
  `RESPECT_USER`.
- If a person being unable to record a real dependency would be a problem, use
  `IGNORE_USER`, narrow the scope, and configure only the columns the decision needs.

## Related

- [JQL scope](../jql-scope/), which bounds what `IGNORE_USER` can reach
- [Privacy and data handling](../privacy/), where this is one of three disclosures
- [Set up the field](../set-up-the-field/)

---

A problem or a question? Write to [support@oktul.com](mailto:support@oktul.com) or open a request in the [Help Center](https://oktul.atlassian.net/servicedesk/customer/portals). Both reach the same service desk, so either way the request gets a reference and an SLA measuring the response.