Summary

When a Forge app uses the jira:workflowPostFunction module, no project context is provided in either the frontend (view.getContext()) or the resolver context (invokeRemote) for company-managed projects. Additionally, the Forge Invocation Token (FIT) used in requestRemote calls lacks project context for both company-managed and team-managed projects. This makes it impossible for apps to scope data to a specific project.

Current Behaviour

• invokeRemote: company-managed projects: For company-managed projects, the extension context always contains:
  • "workflowScope": "GLOBAL"
  • "scopedProjectId": null
  • "projectId": null

This occurs even when the workflow is accessed via Project Settings → Workflows → Edit, where project context would reasonably be expected.

• requestRemote: both project types: The Forge Invocation Token (FIT) does not include any project context for either company-managed or team-managed projects.

Expected Behaviour

• invokeRemote: When a user navigates to the workflow editor from Project Settings → Workflows, the extension context should include the originating project's context, similar to what is already provided for team-managed projects:
  • ✅ "workflowScope": "PROJECT"
  • ✅ "scopedProjectId": "10299"

• requestRemote: The FIT should include project context so that remote backends can scope responses to the correct project.

Current Workaround

When accessed from Project Settings → Workflows, the project key can be derived by parsing the returnUrl from extension.location (available in the frontend context). Extract it on the frontend and pass it to the resolver via invoke().

[!IMPORTANT]
Note: This only works when accessed from Project Settings — returns null from global admin (Settings → Issues → Workflows).

Note: This workaround applies to invokeRemote only. There is no equivalent workaround for requestRemote as the project context cannot be injected into the FIT.