By creating this pull request, I grant the project maintainers an unlimited,
perpetual license to use, modify, and redistribute these contributions under any terms they
choose, including both the AGPLv3 and the Fossorial Commercial license terms. I
represent that I have the right to grant this license for all contributed content.
Description
When a blueprint references a role that doesn't exist yet, create it automatically instead of failing or silently dropping the association.
Proxy resource blueprints (sso-roles) previously threw Role not found, blocking the entire blueprint apply. Now auto-creates the role.
Client resource blueprints (roles) previously ran a WHERE IN query and silently ignored any role names that didn't match. Now auto-creates missing roles before associating them.
Auto-created roles receive the three default permissions: getOrg, getResource, listResources.
Blueprints are the declarative source of truth for resource configuration. Requiring roles to be pre-created through the UI before they can be referenced in a blueprint breaks the declarative workflow and adds a manual step that's easy to forget. This is especially relevant when integrating with an external IdP where SSO group-to-role mappings should just work on first apply.
How to test?
Apply a blueprint with sso-roles referencing a role that does not exist. Verify the role is created with default permissions and the resource association succeeds.
Apply a blueprint with roles (client resource) referencing a role that does not exist, for both new and existing resources. Verify the same.
Apply a blueprint referencing a role that already exists. Verify no duplicate is created and the existing role is associated normally.
Verify auto-created roles appear in the admin UI with the correct permissions.
AI disclosure
This PR was authored with assistance from Claude Code (claude-opus-4-6). The contributor reviewed, tested, and validated all changes.
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.
## 📋 Pull Request Information
**Original PR:** https://github.com/fosrl/pangolin/pull/2980
**Author:** [@rinseaid](https://github.com/rinseaid)
**Created:** 5/3/2026
**Status:** 🔄 Open
**Base:** `main` ← **Head:** `blueprint-auto-create-roles`
---
### 📝 Commits (1)
- [`4786fc3`](https://github.com/fosrl/pangolin/commit/4786fc3a315654bd65bdc6fd494e544d7b8d1ca8) Auto-create roles referenced in blueprints
### 📊 Changes
**2 files changed** (+64 additions, -8 deletions)
<details>
<summary>View changed files</summary>
📝 `server/lib/blueprints/clientResources.ts` (+48 -6)
📝 `server/lib/blueprints/proxyResources.ts` (+16 -2)
</details>
### 📄 Description
By creating this pull request, I grant the project maintainers an unlimited,
perpetual license to use, modify, and redistribute these contributions under any terms they
choose, including both the AGPLv3 and the Fossorial Commercial license terms. I
represent that I have the right to grant this license for all contributed content.
## Description
When a blueprint references a role that doesn't exist yet, create it automatically instead of failing or silently dropping the association.
- Proxy resource blueprints (`sso-roles`) previously threw `Role not found`, blocking the entire blueprint apply. Now auto-creates the role.
- Client resource blueprints (`roles`) previously ran a `WHERE IN` query and silently ignored any role names that didn't match. Now auto-creates missing roles before associating them.
- Auto-created roles receive the three default permissions: `getOrg`, `getResource`, `listResources`.
Blueprints are the declarative source of truth for resource configuration. Requiring roles to be pre-created through the UI before they can be referenced in a blueprint breaks the declarative workflow and adds a manual step that's easy to forget. This is especially relevant when integrating with an external IdP where SSO group-to-role mappings should just work on first apply.
## How to test?
- Apply a blueprint with `sso-roles` referencing a role that does not exist. Verify the role is created with default permissions and the resource association succeeds.
- Apply a blueprint with `roles` (client resource) referencing a role that does not exist, for both new and existing resources. Verify the same.
- Apply a blueprint referencing a role that already exists. Verify no duplicate is created and the existing role is associated normally.
- Verify auto-created roles appear in the admin UI with the correct permissions.
## AI disclosure
This PR was authored with assistance from Claude Code (claude-opus-4-6). The contributor reviewed, tested, and validated all changes.
---
<sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
📋 Pull Request Information
Original PR: https://github.com/fosrl/pangolin/pull/2980
Author: @rinseaid
Created: 5/3/2026
Status: 🔄 Open
Base:
main← Head:blueprint-auto-create-roles📝 Commits (1)
4786fc3Auto-create roles referenced in blueprints📊 Changes
2 files changed (+64 additions, -8 deletions)
View changed files
📝
server/lib/blueprints/clientResources.ts(+48 -6)📝
server/lib/blueprints/proxyResources.ts(+16 -2)📄 Description
By creating this pull request, I grant the project maintainers an unlimited,
perpetual license to use, modify, and redistribute these contributions under any terms they
choose, including both the AGPLv3 and the Fossorial Commercial license terms. I
represent that I have the right to grant this license for all contributed content.
Description
When a blueprint references a role that doesn't exist yet, create it automatically instead of failing or silently dropping the association.
sso-roles) previously threwRole not found, blocking the entire blueprint apply. Now auto-creates the role.roles) previously ran aWHERE INquery and silently ignored any role names that didn't match. Now auto-creates missing roles before associating them.getOrg,getResource,listResources.Blueprints are the declarative source of truth for resource configuration. Requiring roles to be pre-created through the UI before they can be referenced in a blueprint breaks the declarative workflow and adds a manual step that's easy to forget. This is especially relevant when integrating with an external IdP where SSO group-to-role mappings should just work on first apply.
How to test?
sso-rolesreferencing a role that does not exist. Verify the role is created with default permissions and the resource association succeeds.roles(client resource) referencing a role that does not exist, for both new and existing resources. Verify the same.AI disclosure
This PR was authored with assistance from Claude Code (claude-opus-4-6). The contributor reviewed, tested, and validated all changes.
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.