Thanks for calling this out @ccharnolevsky! I've updated the parent issue with the warning state.
For now, Warning = scanner is not completing scans successfully, with a fixed threshold of 1–2 failures. Down the road, partial or degraded scan results are worth considering as an additional warning signal.
@ccharnolevsky The project-level security configuration page accessed from the security inventory should be a full page, not a drawer. Here's the design and the comment from when that decision was made.
I've been aware of this inconsistency for a while but hadn't raised it. I should have. Given the additional workflows that stem from this page, it's worth updating the UI to match — full page instead of drawer. This would solve the drawer-on-drawer problem.
Would this be a viable approach? I presume it expands the scope quite a bit.
Good eye @ccharnolevsky — I appreciate that you're keeping consistency in mind here
When a profile isn't configured, the priority is making activation obvious. That's why the apply default action lives directly on the card — hard to miss, no extra steps.
The other actions are lower priority once the scanner is on, especially disable. We still want it accessible, but it shouldn't compete for attention. Out of sight, out of mind — but there if you need it.
On the Troubleshoot Failure button: we could surface it on the card when failures are present, but my recommendation is to keep it as is. Once we introduce multiple profiles per scan type, the primary card action will be for selecting or changing a profile — a consistent action regardless of scanner status. Everything else, including troubleshooting, moves into the overflow menu. Since that's likely where we're headed anyway, it probably makes sense to lean into that pattern now.
Michael Fangman (6938f1dd) at 18 Mar 01:24
feat: add issue list prototype and fix CLAUDE.md rendering
Michael Fangman (57d1fbc8) at 17 Mar 22:35
fix: use relative base path for GitLab Pages unique domain compatib...
Michael Fangman (00d33d6b) at 17 Mar 22:20
Initial commit — Pajamas prototyping kit
Now that I've had a chance to dig into https://gitlab.com/groups/gitlab-org/-/work_items/20930+ properly, my understanding of how user-level SPP enforcement works has evolved — and some of what I shared in our earlier conversation wasn't quite right. I've noted some necessary clarifications below, followed by answers to each of the open questions.
I hope this helps! Let me know if you have follow-up questions or need further clarity on anything. The design issue has been updated with the initial design proposal. Here's the link if you want to check it out.
A user with an Ultimate group association has SPP enforced on their personal project. The enforcement source is the group/license association, but nothing in their current experience surfaces that chain. User is faced with "why is this happening to me?" when they're blocked in their IDE.
One thing worth clarifying: SPP enforcement doesn't apply only to personal projects. Once a user is enforced, it applies to any public repository they push to — personal projects, open source projects, or any other public repo.
To address the visibility gap, the design surfaces enforcement to the user in two places:
User level, owned resource, Personal Project (if SPP enforcement becomes a user-visible preference)
It's worth adjusting the framing of "preference" here — enforcement is applied to the user by their group admin, not something they opt into or configure. The Account Security page within the user settings section is a visibility surface only.
The full chain is:
spp_enforced attribute on the user account)The Security Configuration page toggle (user needs to know if/why they can't change it)
There are two Security Configuration pages in play here — group-level and project-level — with different roles.
The original feature proposal suggested adding a toggle on the project-level Security Configuration page that would allow individual projects to opt out of enforcement. I'm recommending we defer this. The audiences who need visibility into enforcement are already covered by the Account Security page and Member Security tab, and introducing a second SPP surface at the project level adds complexity that isn't justified by a clear use case yet.
The group-level Security Configuration page is where the relevant change is happening. We're proposing a new Member Security tab there, which is where group admins can enable/enforce SPP for all users within their group.
Confirm the system evaluation — is it the user's license association, project visibility, or group policy? Is it all three? Are there limitations on what details can be surfaced depending on where the pattern is applied?
The conditions are additive, not either/or.
On surfacing: the push block message is the primary point of exposure, directing users to Account Security where the responsible groups are listed.
How are conflicts resolved across user/group/project levels, and who can override?
Group admins have two override mechanisms: they can exclude a specific user (which overrides group enforcement for that individual) or exclude a specific project (which prevents scanning on pushes to that project regardless of the user's enforcement status). Both should be auditable.
The more complex case — where one group enforces and a different group excludes the same user — is still an open question I need to resolve with engineering. I'll follow up once I have clarity on that.
When enforcement is denied, what details of the source can be surfaced to user in IDE?
The message explicitly attributes enforcement to the user's account, not the project — which is the critical framing for the personal-project scenario where the group connection would otherwise be invisible. It surfaces the detected secrets and their locations, and links to Account Security where the responsible groups are listed.