After applying a shared policy to a public resource, it seems its access rules are always at the bottom if you try to add a custom rule for said resource.
In other words, it's impossible to add a custom rule that goes below the shared policy rules?
I'm not sure if it's a bug or meant to work this way, but this a bit of a bummer if your shared policy rules are all "Block access" type rules, which you'd probably always want at the top and not at the bottom priority wise.
Environment
OS Type & Version: Docker Compose on Debian Trixie
Pangolin Version: 1.19.1
Edition: Enterprise
To Reproduce
Create a shared policy
Create any access rule in it
Apply the policy to a public resource
Inside the public resource, go to the Access Rules tab
The shared policy access rule shows up as greyed out (normal behavior)
Add a custom rule of your choice via the "+ Add Rule" button
Your new rule will appear at the top with a priority of 1
Change its priority number to a number bigger than the last rule of the shared policy (ie 99)
You get a "Invalid priority. Enter a whole number of 1 or higher."
Impossible to move the custom rule below the shared policy rules.
Expected Behavior
Custom access rules on public resources should be able to go below shared policy rules.
Originally created by @ceptonit on GitHub (Jun 12, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/3254
### Describe the Bug
After applying a shared policy to a public resource, it seems its access rules are always at the bottom if you try to add a custom rule for said resource.
In other words, it's impossible to add a custom rule that goes below the shared policy rules?
I'm not sure if it's a bug or meant to work this way, but this a bit of a bummer if your shared policy rules are all "Block access" type rules, which you'd probably always want at the top and not at the bottom priority wise.
### Environment
- OS Type & Version: Docker Compose on Debian Trixie
- Pangolin Version: 1.19.1
- Edition: Enterprise
### To Reproduce
1. Create a shared policy
2. Create any access rule in it
3. Apply the policy to a public resource
4. Inside the public resource, go to the Access Rules tab
5. The shared policy access rule shows up as greyed out (normal behavior)
6. Add a custom rule of your choice via the "+ Add Rule" button
7. Your new rule will appear at the top with a priority of 1
8. Change its priority number to a number bigger than the last rule of the shared policy (ie 99)
9. You get a "Invalid priority. Enter a whole number of 1 or higher."
10. Impossible to move the custom rule below the shared policy rules.
### Expected Behavior
Custom access rules on public resources should be able to go below shared policy rules.
I want to be able to add site-specific rules in between the shared rules.
Therefore I added 3 shared rules with priorities 10, 20 and 99.
Adding a specific rule via Docker label like
adds the rule regardless of the priority (or more likely: the shared rules' priorities) at the top.
Also the given priority in the shared rules are not reflected on the site configuration.
Share policy configuration:
Site configuration using the shared policy and having the mentioned "11" priority:
<!-- gh-comment-id:4707917944 -->
@woernsn commented on GitHub (Jun 15, 2026):
I'm seeing the same.
I want to be able to add site-specific rules in between the shared rules.
Therefore I added 3 shared rules with priorities 10, 20 and 99.
Adding a specific rule via Docker label like
```
pangolin.public-resources.my-app.rules[0].priority=11
```
adds the rule regardless of the priority (or more likely: the shared rules' priorities) at the top.
Also the given priority in the shared rules are not reflected on the site configuration.
Share policy configuration:
<img width="1558" height="537" alt="Image" src="https://github.com/user-attachments/assets/8eac4d25-4866-423c-9c51-6620fbc91fc2" />
Site configuration using the shared policy and having the mentioned "11" priority:
<img width="1551" height="667" alt="Image" src="https://github.com/user-attachments/assets/8e0b06fc-2634-45b9-a3c2-97e8d111e7cb" />
@oschwartz10612 commented on GitHub (Jun 16, 2026):
Right now this is expected behavior. The the rules on the resource
specifically "override" the policy rules and always go on top. We could
look into adding this as a feature (to interlace the rules).
I want to be able to add site-specific rules in between the shared rules.
Therefore I added 3 shared rules with priorities 10, 20 and 99.
Adding a specific rule via Docker label like
<!-- gh-comment-id:4724548122 -->
@oschwartz10612 commented on GitHub (Jun 16, 2026):
Right now this is expected behavior. The the rules on the resource
specifically "override" the policy rules and always go on top. We could
look into adding this as a feature (to interlace the rules).
On 6/15/26 05:28, Werner Kapferer wrote:
> *woernsn* left a comment (fosrl/pangolin#3254)
> <https://github.com/fosrl/pangolin/issues/3254#issuecomment-4707917944>
>
> I'm seeing the same.
>
> I want to be able to add site-specific rules in between the shared rules.
> Therefore I added 3 shared rules with priorities 10, 20 and 99.
> Adding a specific rule via Docker label like
>
> |pangolin.public-resources.my-app.rules[0].priority=11 |
>
> adds the rule regardless of the priority (or more likely: the shared
> rules' priorities) at the top.
>
> Also the given priority in the shared rules are not reflected on the
> site configuration.
>
> Share policy configuration:
> image.png (view on web)
> <https://github.com/user-attachments/assets/8eac4d25-4866-423c-9c51-6620fbc91fc2>
>
> Site configuration using the shared policy and having the mentioned
> "11" priority:
>
> image.png (view on web)
> <https://github.com/user-attachments/assets/8e0b06fc-2634-45b9-a3c2-97e8d111e7cb>
>
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/fosrl/pangolin/issues/3254?email_source=notifications&email_token=ABGEUGFGYEMHJ3PKPJH6GQ3477TVVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZQG44TCNZZGQ2KM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-4707917944>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABGEUGBVZ43GSCRPB73D4ZD477TVVAVCNFSNUABFKJSXA33TNF2G64TZHM4DMMZYGM2TIMRXHNEXG43VMU5TINRUHEYDCMJQGI22C5QC>.
> You are receiving this because you are subscribed to this
> thread.Message ID: ***@***.***>
>
Right now this is expected behavior. The the rules on the resource
specifically "override" the policy rules and always go on top. We could
look into adding this as a feature (to interlace the rules). …
Thanks for answering so fast!
I don't know if this would also be requested for others but for me it's a must-have to be able to use shared policies for a few of my sites.
Would there be other side effects if the given priorities of the shared policies are simply taken as-is for the sites?
For the current behavior, one could simply set the shared policy priorities to > 20 and therefore always add site-specific rules with priorities < 20 on top.
<!-- gh-comment-id:4726000804 -->
@woernsn commented on GitHub (Jun 17, 2026):
> Right now this is expected behavior. The the rules on the resource
> specifically "override" the policy rules and always go on top. We could
> look into adding this as a feature (to interlace the rules).
> […](#)
Thanks for answering so fast!
I don't know if this would also be requested for others but for me it's a must-have to be able to use shared policies for a few of my sites.
Would there be other side effects if the given priorities of the shared policies are simply taken as-is for the sites?
For the current behavior, one could simply set the shared policy priorities to > 20 and therefore always add site-specific rules with priorities < 20 on top.
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.
Originally created by @ceptonit on GitHub (Jun 12, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/3254
Describe the Bug
After applying a shared policy to a public resource, it seems its access rules are always at the bottom if you try to add a custom rule for said resource.
In other words, it's impossible to add a custom rule that goes below the shared policy rules?
I'm not sure if it's a bug or meant to work this way, but this a bit of a bummer if your shared policy rules are all "Block access" type rules, which you'd probably always want at the top and not at the bottom priority wise.
Environment
To Reproduce
Expected Behavior
Custom access rules on public resources should be able to go below shared policy rules.
@woernsn commented on GitHub (Jun 15, 2026):
I'm seeing the same.
I want to be able to add site-specific rules in between the shared rules.
Therefore I added 3 shared rules with priorities 10, 20 and 99.
Adding a specific rule via Docker label like
adds the rule regardless of the priority (or more likely: the shared rules' priorities) at the top.
Also the given priority in the shared rules are not reflected on the site configuration.
Share policy configuration:
Site configuration using the shared policy and having the mentioned "11" priority:
@oschwartz10612 commented on GitHub (Jun 16, 2026):
Right now this is expected behavior. The the rules on the resource
specifically "override" the policy rules and always go on top. We could
look into adding this as a feature (to interlace the rules).
On 6/15/26 05:28, Werner Kapferer wrote:
@woernsn commented on GitHub (Jun 17, 2026):
Thanks for answering so fast!
I don't know if this would also be requested for others but for me it's a must-have to be able to use shared policies for a few of my sites.
Would there be other side effects if the given priorities of the shared policies are simply taken as-is for the sites?
For the current behavior, one could simply set the shared policy priorities to > 20 and therefore always add site-specific rules with priorities < 20 on top.