quang.pham
07/12/2026, 3:23 PMX IA
07/17/2026, 5:55 PMSubject: get_user_permissions() returns empty for users with multiple groups, and ignores group-derived grants when a user also has a direct role assignment
Environment:
- Project: default / Environment: dev
- PDP: Cloud PDP (<https://cloudpdp.api.permit.io>)
- SDK: permit-sdk-python 2.8.3, Python 3.10.7
Issue 1 — multiple groups on one user breaks all permission retrieval
User x-i-a_test-multi-group is a member of two groups (developer, data_user). Each group individually grants working permissions when assigned alone (verified via x-i-a_test-developer, group developer only, and x-i-a_test-data-user, group data_user). But with both groups on the same user, get_user_permissions() returns {} for every resource instance touched by either group — not just a conflict on overlapping resources.
Example:
user: x-i-a_test-multi-group (groups: developer, data_user)
resource: scope_artifactregistry:x-i-a_artifactregistry_france
expected: [repositories_delete_artifacts, repositories_download_artifacts, repositories_upload_artifacts]
actual: []
5 of 5 checks failed for this user across all its resource instances.
Issue 2 — direct role assignment on a user causes their group-derived grant to be dropped
User x-i-a_test-data-user has both a group (data_user) and a direct role assignment (run.builder on scope: france) in the same membership entry. The direct role's permissions (france scope) resolve correctly, but the permission granted purely through the data_user group (on a different scope, project_a) comes back empty:
user: x-i-a_test-data-user
resource: scope_storage:x-i-a_storage_project_a
expected: [buckets_get, buckets_list] <- granted via group "data_user"
actual: []
By contrast, x-i-a_test-direct-role (role only, no group) resolves correctly, confirming the role path itself works — it's specifically the presence of a group and a role together on one user that suppresses the group's grant.
Ask: Is this expected PDP behavior (e.g. groups + roles or multi-group not being additive/merged), a caching/propagation issue, or a bug in permission resolution? Happy to share full config (group->role assignments, membership.yml) and a repro script (config/auth/validate_permit.py) that reproduces both against our environment on request.jason.chaw
07/20/2026, 5:02 AMMohit
07/21/2026, 12:02 PMWee Hong, Vernon KOH
07/28/2026, 11:34 AMvadiga974
07/30/2026, 5:57 PMVikas Rajvanshy
07/31/2026, 4:26 AMHuy
08/14/2026, 7:33 AMjonathon.adler
08/17/2026, 8:38 PMwesley.wu
08/19/2026, 1:15 AMJoop
08/20/2026, 2:19 PMHuy
08/22/2026, 9:47 AM/check requests on the PDP so that the permission check only proceeds once the PDP has the latest data? @Ask InkeepAdnan Arif Sait
08/28/2026, 6:53 AMantonello
08/28/2026, 10:37 AMVijaysree Kalvakolanu
09/09/2026, 7:43 AMJiten Singh
09/09/2026, 3:23 PMShay Shany
09/09/2026, 3:33 PMVijaysree Kalvakolanu
09/10/2026, 10:43 AMantonio.zhu
09/11/2026, 1:29 PMLuiz da Silva
09/17/2026, 7:38 PMcurl -sS -H "Authorization: Bearer $env:PERMIT_PROD_KEY" "<https://api.permit.io/v2/facts/default/production/role_assignments/detailed?user=12354&tenant=default&per_page=100>"
It returns something like:
{
"id": "004242fee3b54d94a5f1caadd52b2ff4",
"role": {
"id": "865927aa193e40ebbb2a1bfec64de774",
"key": "SchedulingExecutive",
"name": "SchedulingExecutive",
"permissions": [
"Company:read-company",
...
]
},
"user": {
"id": "0b7823e7c956452285e90375d7550e02",
"key": "12354",
"email": null,
"first_name": ...,
"last_name": ...,
"attributes": null
},
"tenant": {
"id": "463ab023370c43b6b383d2cced12afb4",
"key": "default",
"name": "Default Tenant",
"attributes": null
},
"resource_instance": {
"id": "00904ff7cbdc402aaf372e9ef1c444de",
"key": "194",
"resource": "Community",
"attributes": { ... }
},
"organization_id": "75ba10ce33df4af49b3d3f28251ad325",
"project_id": "06a201217bf34db08ced08463a3c1e68",
"environment_id": "c2806df4431a49d49390e0d61fe1ee3e",
"created_at": "2026-01-23T15:45:51+00:00"
}
Notice how the permissions given start with Company:, which all come from Company#SchedulingExecutive, but have been applied to Community#194 as if they were Community#SchedulingExecutive because with the Node.js SDK we used to refer to it simply as SchedulingExecutive and expected the API to pick-up the correct resource type on Permit's side.
Now, the problem is we're trying to fix these mismatches, both through the web UI panel or through the SDK/API; neither works (generally just a 404 or generic error message). Is this a known regression? If so, has it been patched at some point? And how to recover from it for existing users without having to recreate all?
Thanks!Jazmine Reyes
09/21/2026, 2:48 AManyio and aiohttp. Is there a plan to fix this? Our internal security compliance policy strictly prohibits us from deploying applications that contain third-party dependencies with unresolved vulnerabilities. Thank you.Slackbot
09/30/2026, 9:44 PMSlackbot
10/01/2026, 1:00 AMiali
10/19/2026, 5:25 PMImran Bohoran
10/23/2026, 2:55 PMwesley.wu
10/28/2026, 12:59 AMFailed to send request to OPA: Failed to send request to OPA: error sending request for url (<http://localhost:8181/v1/data/permit/root>)
also see a couple of these at the same time we see the above
Health check failed: opa: Failed to connect to OPA … <http://localhost:8181/health>
these tasks are well provisioned, not seeing it anywhere close to being starved for resources. any idea what the cause might be? we see the spikes (which correlate to spikes in traffic from about 5 req/s to about 100 req/s) and then the latency returns to baseline after the burst in load passes. are there limits to what OPA can handle or best practice for how to handle these bursts?
i found this similar thread above but not sure if there was any resolutiondavid
11/03/2026, 4:16 PMSebastian Lauwers
11/04/2026, 9:47 AMdavid
11/04/2026, 10:51 AM