NOISSUE - Expose assigment gaurdrail#12
Conversation
Signed-off-by: Arvindh <arvindh91@gmail.com>
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
atom-docs | 389b2df | Commit Preview URL Branch Preview URL |
Jun 18 2026, 12:05 PM |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 389b2dfc6f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| FROM permission_blocks pb | ||
| JOIN permission_block_actions pba ON pba.permission_block_id = pb.id | ||
| JOIN actions a ON a.id = pba.action_id |
There was a problem hiding this comment.
Do not guardrail deny permission blocks
When create_direct_policy or replace_role_permission_block_links calls this new helper, it joins every permission block action without checking pb.effect. For a DENY permission block, such as effect='deny' for a device managing resources, the guardrail validation treats it as a granted action and rejects it against the seeded device/manage/resource deny rule, preventing callers from adding explicit deny policies. Filter to allow blocks or carry the effect through before building Assignment.
Useful? React with 👍 / 👎.
What type of PR is this?
What does this do?
Which issue(s) does this PR fix/relate to?
Have you included tests for your changes?
Did you document any new/modified features?
Notes