I85PREP
⌘ K
ACP-120 study materials
ACP-120 study resources

The Shared Permission Scheme and the Vendors

ACP-120 · Put your knowledge to work in context.

All case studies

The Shared Permission Scheme and the Vendors

Meridian Software runs 14 company-managed projects that all share the single Standard Permission Scheme. A new project, VEND (Vendor Portal), must give 8 external contractors in the group vendors-ext access to log, view, and comment on their own issues only. Contractors must never see internal triage comments, must not be assignable, must not appear in the assignee picker of any other project, and must not be able to transition issues. The internal support team of 30 sits in the group jira-internal. Legal has confirmed that the other 13 projects must not change behaviour in any way, and that no contractor may discover an issue reported by another vendor. Budget for marketplace apps is zero, and VEND must stay on its current project type.

1. Do you edit the existing permission scheme or create a new one? Justify the decision using blast radius, and list the exact grants the `vendors-ext` group needs.

Read the worked answer

Create a new permission scheme. Editing the shared one is the wrong move even though it is faster.

  • Standard Permission Scheme is the only scheme for 14 projects. Every grant you add or remove there takes effect in all 14 immediately. Adding a grant for vendors-ext would give contractors a foothold in 13 projects they must not touch.
  • Copy it (Project settings → Permissions → Actions → Copy), name it Vendor Portal Permission Scheme, then use Actions → Use a different scheme on VEND only. Afterwards, confirm the other 13 projects still list Standard.

Grants for vendors-ext in the copied scheme:

Permission Grant? Why
Browse Projects yes without it they see nothing at all
Create Issues yes they log their own tickets
Add Comments yes they must be able to reply
Assignable User no this permission is exactly what removes them from the assignee picker
Transition Issues / Resolve Issues no the manager asked for transitions to be blocked
Modify Reporter / Delete Issues / Set Issue Security no privilege escalation, and Set Issue Security would let them hide issues from you

Also strip from the copy any group or role grant the vendors should not inherit, and re-check the jira-internal grants survived the copy. A permission scheme is project-wide, so this solves access but not yet the own-issues-only requirement.

2. Permission schemes cannot express 'only their own issues'. How do you enforce that for the 8 contractors, and what do you reject?

Read the worked answer

Permission schemes are project-scoped, so per-issue restriction requires issue-level security.

Options considered:

  1. A JQL filter or dashboard gadget - hides nothing. Anyone with Browse Projects who knows or guesses a key can open the issue. Rejected.
  2. One project per vendor - works, but multiplies schemes eightfold, still does not hide internal issues, and blows the no-apps constraint on admin effort. Rejected.
  3. Issue-level security - the only native per-issue gate in company-managed projects. Chosen.

Design:

  • Create an issue security scheme with two levels: Vendor Visible (grant: project role Vendors) and Internal Only (grant: group jira-internal). Make Internal Only the default level so new issues are private until classified.
  • Add a project role Vendors to VEND and put the 8 contractors in it. Use a role, not the group, for the security level: roles are per-project, so the same people cannot leak visibility into another project that reuses the name.
  • Automation: when an issue is created by a member of vendors-ext, set the security level to Vendor Visible. Setting levels manually requires the Set Issue Security permission - do not give that to vendors.
  • Issue security filters on top of Browse Projects; it does not replace it. Vendors still need the Browse grant.

State the constraint out loud: issue-level security does not exist in team-managed projects. If VEND is ever converted, this design collapses.

3. The support manager wants internal triage discussion kept on the same issue but invisible to vendors. What is the only workable mechanism, and how do you mitigate its weakness?

Read the worked answer

Comment visibility is the only native mechanism; there is no per-user field-level security in Jira.

  • Screens hide fields per issue type and project, not per person. A custom field called Internal notes would be visible to every vendor who can see the issue. Rule that option out explicitly rather than letting the manager assume it works.
  • Company-managed projects let the author restrict a comment to a group or project role. Restrict internal comments to group jira-internal.

Weaknesses to disclose:

  • It is opt-in per comment. Nothing forces staff to tick the restriction, and Jira will not retrofit it. The leak is human, not technical.
  • Mitigation: a recurring automation rule or saved-filter review that surfaces comments authored by jira-internal members with no visibility restriction, posted to a Slack channel for cleanup. JQL has no comment-visibility predicate, so use the REST API via a scripted rule or accept a manual weekly review. Do not promise automatic remediation.
  • Good news: notifications respect the restriction. A vendor who cannot see a comment receives no comment body in email.
  • If internal discussion grows heavy, the durable answer is a second internal-only project linked to the vendor issue, so the conversation never shares a security boundary with the customer.