How to reliably detect whether the current user is a Jira "guest" (from a Forge app)?

Forge Forge Platform and Tools
1

We’re building a Forge custom UI app for Jira and need to know whether the current user is a guest ( Invite guests to Jira | Atlassian Support ) vs. a full site member, from inside the app itself.

We also noticed something that might be a clue, but we’re not confident it’s meaningful: context.userAccess (documented for user-based billing: https://developer.atlassian.com/platform/forge/adopt-user-based-billing/) is populated even when our app hasn’t opted into that billing model (access.userAccess in our manifest):

"userAccess":{"enabled":false,"hasAccess":false}

For the same Atlassian account, on a site where this user is a confirmed guest, hasAccess came back false. On a different site, where the same account is a full member, hasAccess came back true - with enabled: false in both cases. Since the user-based billing docs only describe hasAccess semantics once an app has opted in, we don’t know if this is a real, stable signal of guest/product-access status, or coincidental.

Questions:

  1. Is there any officially supported way to determine guest vs. full-member status?
  2. Is userAccess.hasAccess meant to carry any meaning when enabled is false, and could it reliably reflect guest status, or is that coincidental/unstable behavior we shouldn’t depend on?
2

I don’t know of an officially supported “is guest” flag, and I wouldn’t build on userAccess.hasAccess while enabled is false. The user-based billing docs only define it once an app opts in, so today’s values could change without notice.

What has worked for me is to stop asking “is this a guest?” and ask what you actually need to gate: “can this user do X here?” Jira already answers that per user and per issue or project:

GET /rest/api/3/mypermissions?projectKey=ABC&permissions=BROWSE_PROJECTS,ADD_COMMENTS,CREATE_ISSUES

Call it with requestJira from the frontend, or asUser() in a resolver, and it runs as the current user. Guests only get access to the spaces they were invited to, so a guest simply comes back with havePermission: false wherever they lack access. That tracks the site’s real configuration, including admins who change what guests can do, which a guest flag wouldn’t.

I use this pattern in a Jira/JSM app to check permissions before it changes anything, and it’s been reliable.

If you do need the literal guest status (for example, to show different UI), it’s worth asking Atlassian for a supported field. I’d +1 that request.