-
Type:
Suggestion
-
Resolution: Unresolved
-
Component/s: Request type - Other, Request type - Permissions & Security
-
None
Current State:
When an agent attempts to move an issue from one JSM project to another, the Move Issue dialog requires the agent to have Browse Projects permission on the destination project in order to see and select that project's Request Types.
However, the JSM Customer Portal exposes the same Request Types to customers who do not have an agent license or Browse Projects permission — they can view and submit against Request Types purely through portal-level access (Customer Permissions in project settings).
This creates an inconsistency:
- A portal customer (no agent license, no Browse Projects) can see and use the destination project's Request Types.
- An internal agent with Create Issues permission on the destination project cannot see those same Request Types during the Move Issue operation unless Browse Projects is also granted.
The only workaround is to grant Browse Projects + an Issue Security Scheme to restrict issue visibility — which violates the principle of least privilege and creates unnecessary administrative overhead.
Proposed Future State:
The Move Issue operation should be able to resolve and display destination project Request Types without requiring full Browse Projects permission. Possible approaches:
- Allow a narrower permission (e.g., "Move Issues" or the future "View Projects" from the BPP split) to be sufficient for Request Type visibility in the Move dialog.
- Decouple Request Type enumeration from Browse Projects, similar to how the portal already exposes them via Customer Permissions.
Alternative (e.g. Third Party Plugin):
- Automation rule workaround: Create a Jira Automation rule triggered by a custom field (e.g., "Destination Project") that performs the move on behalf of the agent. Agents never need access to the destination project. Limitation: less flexible, requires rule maintenance per destination project.
- Browse Projects + Issue Security Scheme: Grant Browse Projects via a custom role, then apply an Issue Security Scheme to hide existing issues. Limitation: administrative complexity, requires ensuring all issues have the security level applied.
- No known third-party plugin that cleanly solves this specific gap.