mirror of
https://github.com/fosrl/pangolin.git
synced 2026-07-15 21:31:24 -05:00
[GH-ISSUE #1361] [API] post_resource__resourceId__roles issue: Organization not found #29706
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Esa-mimbias on GitHub (Aug 27, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/1361
Hi,
Still using API extensively to configure Pangolin "as code".
I met another issue when trying to set a role to a resource
in my example, my resource is number 57 (
I try to add
memberrole (default role, number 2) for my ord namedprodPOSTing using curl fails:
docsswagger execute fails consistantly:in Pangolin debug logs,
seems OK (and indeed, it works)
I tried to check code around
6c9b445be6/server/routers/resource/setResourceRoles.ts (L75)but I'm not proficient enough in TS :(It would really help me.
@binu-baiju commented on GitHub (Aug 27, 2025):
Hi, I’d like to work on this issue. Could you assign it to me? I’ll start by checking setResourceRoles.ts to see why the org isn’t being resolved. @Esa-mimbias
@Pallavikumarimdb commented on GitHub (Aug 27, 2025):
Hi @Esa-mimbias , Since you’re sending the correct payload, the "Organization not found" error is likely because resource 57 is not linked to the same organization as your API key or user.
In Pangolin, the org is determined from your authentication context (req.userOrg or req.apiKeyOrg), not from the request body. Even if you include "orgId": "prod" in your payload, it will be ignored.
Could you double-check if resource 57 is attached to your org (prod)? For example, does it have the same orgId as resource 41 (which works)? If not, that explains the failure.
@Esa-mimbias commented on GitHub (Aug 27, 2025):
OK thank you for the explanation.
the script I wrote to configure Pangolin via API has different tasks :
the first two tasks were done with a server-level root API key, I didn't thought about switching to an organization-level API key for the third task
I updated my script to switch to org API key after first task (GET informations), and it works fine.
Thanks again
(for now it's crude bash script, I may rewrite it in Python and share it)
@oschwartz10612 commented on GitHub (Aug 31, 2025):
I agree I think there actually is an issue here.
I dont think you should have to switch API keys to add a role to a
resource. The issue is indeed that the orgId is coming out of the api
key or user which causes the issue in
server/routers/resource/setResourceRoles.ts:77
To fix this I think we could just pull the orgId from the resource. Ill
fix this in the next release.