mirror of
https://github.com/fosrl/pangolin.git
synced 2026-05-08 05:39:49 -05:00
[GH-ISSUE #825] [FEATURE REQUEST] Multiple quality-of-life feature requests #10415
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/pangolin#10415
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 @kmanwar89 on GitHub (Jun 2, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/825
Hi,
I'd like to request if the following features can be evaluated for their feasibility for implementation into Pangolin. I feel these features would add significant value and improve the product by adopting a security-first mindset.
Ability to define rule "templates" to apply to multiple resources - I currently have 50+ resources in Pangolin, and it's a good bit of work to add the same rules to each resource (allow my WAN IP range, allow Tailscale IP range, allow my VPS IP, block all others). I'd like to see if the ability to "apply rule to selected" could be implemented as this would save time immensely. Alternatively, a "rules template" that could be selected and applied to a resource as it was created would accomplish the same effect.
Edit user details after creation - currently, a Pangolin admin is not presented the option to edit optional details about a user (First/Last name, email) once the user is created. As an admin, I should be able to edit a user's details, generate a password reset or one-time login code, etc. to help a user who gets locked out regain access to their resources.
Implement a configurable session timeout - this is a security issue, and means that if a bad actor gets access to Pangolin, it will never timeout. A configurable session timeout is a standard security feature and should be implemented to prevent unlimited access to the admin interface in case of a credentials breach/exposure.
List, or allow a user to select, resources assigned to them. Currently, if a user logs into Pangolin as a non-admin account, they are presented with a count of sites, users, and resources, but cannot "do" anything with this information. I think there would be value in allowing a user to see which resources they can access. If the "sites" count for a user always lists 0, then perhaps there is value in removing that from the UI as it's not something a user can interact with or provides them anything worthwhile.
Again, thank you for this awesome project. I wish I were more of a developer and could contribute PR's, but alas, I can just try to raise the issues and hope the rationale/justification is valid. Thanks again!
@kmanwar89 commented on GitHub (Jun 12, 2025):
Hi @oschwartz10612 or @miloschwartz , I'd love your thoughts on this FR. The lack of a session timeout is particularly concerning as a bad actor would have unlimited access to a session if the credentials were somehow exposed or breached. Since Pangolin can't itself be protected by PocketID, this presents a security issue. Is the session timeout possibly something that could be implemented? Thank you for your time on this project, it really doesn't go unappreciated!
@oschwartz10612 commented on GitHub (Jun 13, 2025):
Hi! In a similar vein to #906 this is an awesome write up of great UI / usability improvements we should absolutely do! I am going to mark this as help wanted in case anyone wants to take up some of these ideas in the UI because I think they would be pretty straight forward and good first issues.
Otherwise we will try to tackle these ASAP!
@kmanwar89 commented on GitHub (Jun 14, 2025):
Thank you! I do wish I were more of a developer to contribute, but I hope the community can help the product grow!
@adrianeastles commented on GitHub (Jun 26, 2025):
Hi everyone,
Based on the feedback from point 4, I wanted to have this enhancement as it would make my life super simple. The screenshots attached shows how it greatly improves how non-admin users can view their resources that's been granted via the current mechanisms. My goal here is to provide them with much more actionable information right when they log in.
You'll see that when a member is logged in, a new menu called "Account" is now shown, with a dedicated submenu for "Resources". This allows users to quickly find the information most relevant to them.
I've also simplified the main dashboard, removing what I believe was unnecessary information for regular members. Don't worry, if any of that unnecessary information proves useful, I have ideas on where I can reintroduce it. However, a member generally doesn't need to know things like the total user count or the number of sites.
Member Section
What was Added:
New Page: /[orgId]/account/my-resources - A dedicated page where organization members can view all resources they have access to
Card-based Layout: Modern, responsive grid displaying each resource with clear visual indicators
Status Indicators: Color-coded shields showing resource protection levels (enabled/disabled, protected/unprotected)
Interactive Elements: Direct links to access enabled resources, with links and buttons to navigate to the resource.
New Navigation Item: Added "Resources" section under Account in the navigation menu. Seamlessly integrated into existing Layout component with proper navigation hierarchy.
Enhanced organization landing page card to show resource count and provide quick access
Enabled/Disabled States: Clear visual distinction between available and unavailable resources
Empty State: User-friendly messaging when no resources are assigned
@miloschwartz commented on GitHub (Jun 26, 2025):
@adrianeastles Thanks, this looks good!
Can you open a PR so we can keep track of it in there? My initial thought is maybe we should remove the Overview since it's a placeholder and show the Account tab when the user first lands on the page?
@miloschwartz commented on GitHub (Sep 27, 2025):
Thanks for all these requests. Closing this issue because there are many duplicate requests for 2 and 3. 1 is schedule in our roadmap, and 4 is complete.