bobbanandClaude Sonnet 5
1ff1c6550c
IP Addresses (IPAM) now reads the same excluded-ranges setting the Consistency page manages, so "not interesting" addresses - a Docker bridge network repeating on every host, say - can be hidden there too. Adds a "Hide excluded addresses" toggle (on by default, with a live count), an inline ranges editor matching Consistency's, an "excluded" badge on rows shown anyway, and a per-row "Exclude..." shortcut that suggests a /24 (or /64 for IPv6) around that address. Editing ranges from either page updates both, since it's one shared setting. Also adds Operations > Admin Links: a single page summarizing every admin bookmark added across all servers (Dockge, Webmin, Cockpit, etc, previously only visible per-server on each server's own detail page), sortable and searchable, with the same add/edit/delete capability - adding one here just asks which server it belongs to. Verified both with real HTTP-level tests: a genuine Express app, a scratch SQLite DB, and forged sessions, covering the exclusion matching, the shared-setting round trip, the links aggregation and join, and role enforcement - the real dev DB was confirmed untouched throughout. Both packages build clean. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
89 lines
4.1 KiB
Markdown
89 lines
4.1 KiB
Markdown
# Roles & menu access
|
|
|
|
Homelab Manager has three roles, ranked lowest to highest: **viewer**,
|
|
**operator**, **admin**. The first person to sign in becomes admin;
|
|
everyone after that starts as viewer until an admin changes their role
|
|
under **Administration → Users**.
|
|
|
|
A role can do everything the roles below it can, plus what's listed for
|
|
it — operator includes everything viewer has, admin includes everything
|
|
operator has.
|
|
|
|
## Sidebar menu, by role
|
|
|
|
✅ = the menu item appears for that role · ❌ = it's hidden entirely (not
|
|
just disabled) — a group that would end up with zero visible items
|
|
disappears too, and a group left with exactly one just shows as that
|
|
page's own top-level link.
|
|
|
|
| Menu item | Path | Viewer | Operator | Admin |
|
|
|---|---|:---:|:---:|:---:|
|
|
| Dashboard | `/` | ✅ | ✅ | ✅ |
|
|
| **Infrastructure** | | | | |
|
|
| Servers | `/servers` | ✅ | ✅ | ✅ |
|
|
| Proxmox | `/proxmox` | ✅ | ✅ | ✅ |
|
|
| Synology | `/synology` | ✅ | ✅ | ✅ |
|
|
| Proxmox Backup | `/pbs` | ✅ | ✅ | ✅ |
|
|
| Docker | `/docker` | ✅ | ✅ | ✅ |
|
|
| Tailscale | `/tailscale` | ✅ | ✅ | ✅ |
|
|
| **Network** | | | | |
|
|
| DNS | `/dns` | ✅ | ✅ | ✅ |
|
|
| Domains | `/domains` | ✅ | ✅ | ✅ |
|
|
| IP Addresses | `/ipam` | ✅ | ✅ | ✅ |
|
|
| Ports | `/ports` | ✅ | ✅ | ✅ |
|
|
| Consistency | `/consistency` | ✅ | ✅ | ✅ |
|
|
| **Automation** | | | | |
|
|
| Semaphore | `/semaphore` | ✅ | ✅ | ✅ |
|
|
| Gitea | `/gitea` | ✅ | ✅ | ✅ |
|
|
| Secrets | `/secrets` | ✅ | ✅ | ✅ |
|
|
| **Operations** | | | | |
|
|
| Maintenance | `/maintenance` | ✅ | ✅ | ✅ |
|
|
| Uptime Kuma | `/uptime-kuma` | ✅ | ✅ | ✅ |
|
|
| osTicket | `/osticket` | ✅ | ✅ | ✅ |
|
|
| Admin Links | `/admin-links` | ✅ | ✅ | ✅ |
|
|
| Generator | `/generator` | ✅ | ✅ | ✅ |
|
|
| **Administration** | | | | |
|
|
| Integrations | `/integrations` | ✅ | ✅ | ✅ |
|
|
| Users | `/users` | ❌ | ❌ | ✅ |
|
|
| Sessions | `/sessions` | ❌ | ❌ | ✅ |
|
|
| Audit Log | `/audit-log` | ❌ | ✅ | ✅ |
|
|
| Diagnostic Log | `/diag-log` | ❌ | ❌ | ✅ |
|
|
| Settings | `/settings` | ❌ | ❌ | ✅ |
|
|
| Privacy (footer link, not in a group) | `/privacy` | ✅ | ✅ | ✅ |
|
|
|
|
So in practice: **every page is visible to every role except the five
|
|
under Administration** — Users, Sessions, and Diagnostic Log need admin;
|
|
Audit Log needs operator or admin; Settings needs admin.
|
|
|
|
## Being able to see a page isn't the same as being able to change things
|
|
|
|
Almost every page above is visible to viewers, but most of the buttons
|
|
on them aren't — a viewer can look at everything but can't act on
|
|
anything. Operators can use the page's normal working actions (starting
|
|
a container, syncing DNS, adding a secret, opening a maintenance
|
|
window…). Some actions on otherwise-viewer-visible pages are held back
|
|
even further, to admin only:
|
|
|
|
- **Integrations & DNS providers**: any operator can use an integration
|
|
once it's configured (start/stop a guest, run a template, sync DNS
|
|
records, etc.), but adding, editing, testing, or deleting an
|
|
integration or DNS provider is admin-only.
|
|
- **Servers**: registering a new server, rotating its agent token, and
|
|
editing/deleting a server are admin-only; tagging a server and
|
|
linking/unlinking it to a Proxmox guest just need operator.
|
|
- **Tags**: creating, renaming, recoloring, or deleting a tag is
|
|
admin-only (applying an existing tag to a server needs operator).
|
|
- **Ports**: everyone can see both the agent-reported and manual tables;
|
|
adding, editing, or deleting a manual port opening needs operator.
|
|
- **Admin Links**: everyone can see and open every server's admin
|
|
bookmarks, from that server's own page or the summary page; adding,
|
|
editing, or removing one needs operator, from either place.
|
|
- Everything under **Settings** (notification channels, badge colors,
|
|
display prefs, log retention, backup/restore) is admin-only, matching
|
|
the page itself being admin-only.
|
|
|
|
If you need the exact role for one specific button rather than this
|
|
summary, check the corresponding route in `server/src/routes/` — each
|
|
one that needs more than "signed in" calls `requireRole("operator")` or
|
|
`requireRole("admin")` right where that action is defined.
|