Contractors, comments, and a filter on the open internet

Role membership cannot restrict anything. Effective permission is the union of every grant the user's groups and roles match, so adding contractors to Viewers only added visibility - it did not take anything away. The comment and transition rights come from grants in VANT's permission scheme, almost certainly 'Add Comments' and 'Transition Issues' held by Any logged in user or by a group every user sits in (jira-users). Contractors are logged-in users, so they inherit them.

Before editing: check whether VANT's permission scheme is shared with other projects. If it is, clone it for VANT or coordinate the change, otherwise you silently change access elsewhere.

Then:

• Re-point Add Comments, Transition Issues and Edit Issues to project roles - Developers and Administrators.
• Leave Browse Projects broad if issue security is doing the confidentiality work, but never grant anything to Any logged in user in a project holding sensitive issues.
• Verify with the permission helper on a real contractor account and a real developer account, not on your admin account.
• Fix the second layer too: workflow conditions can independently gate transitions. Address both, or contractors will keep seeing transitions that fail with an error instead of disappearing.
• Note that portal-only customers are outside this model - their access comes from the service project's customer permissions, not these grants.

Issue security constrains visibility; it never grants it. It is a separate scheme from permissions, and every failure mode below looks identical from the outside:

1. Is an issue security scheme associated with VANT? A scheme that exists but is not associated does nothing at all.
2. Does the issue actually carry a level? Look at the Level field on the issue. If it is None, everyone who can browse sees it. Levels are not applied retroactively - setting a default level affects new issues only, so existing incidents must be bulk-updated.
3. Who is inside the level? If the level's members include a group the contractors belong to - jira-users is the classic mistake - they see the issue. Build levels from project roles plus the special Reporter and Current assignee members, never from a broad group.

Fix: create level 'Security staff only' with members = role Administrators + a security-team group; set it as the default level for the Security Incident issue type (or set it on create via automation); bulk-update existing incidents; test as a contractor.

Also: if you later narrow Browse Projects to a group, the issue security scheme becomes redundant but harmless. Keep one mechanism documented so the two do not get maintained in parallel.

The condition and the onboarding are using two different access models. The transition's condition tests membership of the global group jira-developers (a leftover from another project's scheme), while onboarding adds people to vant-devs, which maps to the Developers project role. Neither implies the other: a role is a container whose members may be groups or individuals, and the condition is testing group membership directly.

Fixes:

• (a) Change the condition to 'User is in project role Developers'. Preferred: the rule then lives in one place, and anyone added via the group, individually, or through another group's mapping works.
• (b) Add vant-devs to the global jira-developers group as well. Works, but duplicates the rule in two places and will drift.

Also rule out neighbours of the same symptom: a validator on the same transition (a required field not on the transition screen) makes the button appear and then do nothing, and a missing Transition Issues grant looks identical to a failing condition. Administer Projects is not a factor - it has no effect on transitions.

Write the rule down: grant project actions in exactly one place, either the permission scheme or role-based workflow conditions, never both a group condition and a role grant.