Feature: "All containers" toggle for admins sitewide; add additional docker build failsafe's. #374
Feature: "All containers" toggle for admins sitewide; add additional docker build failsafe's. #374cmyers-mieweb wants to merge 4 commits into
Conversation
Issue: #112 Expose an admin-only API and UI to list every container on a site and add owner metadata. Server: add apiAdmin, include owner in serialized containers, introduce CONTAINER_INCLUDE and buildContainerListWhere to centralize eager-loading and filtering, reuse includes for list/show routes, and add GET /sites/{siteId}/containers/all (with username/nodeId/hostname filters). Client: add route /containers/all and scope prop to ContainersListPage, query keys and listAllContainers API call, owner type, admin toggle to switch between "Mine" and "All", and show owner column when viewing all. OpenAPI: document owner property, nodeId query param, and new /containers/all path. Compose: make the node service the single owner of npm installs (use --ignore-scripts + patch-package) and make the client wait for node to finish to avoid concurrent install races. images/proxmox-ve: handle partially-created LXC configs by checking for lingering create locks and missing arch, tearing down remnants and recreating to avoid wedging boots.
Allow listing containers by owner via a `user` query param and propagate that across API, client, and docs. Server: add resolveUsernameFilter to enforce admin-only access for `user='*'` or other owners, apply the username constraint to the existing /containers endpoint, and remove the legacy /containers/all route; update OpenAPI to document the new `user` query and 403 response. Client: update query keys and listContainers to send the `user` param, change routing to use ?user=* for the "All" view, and make ContainersListPage read the user query param so the view is bookmarkable. Dev environment: adjust compose.yml to use node:24-trixie and run npm installs/builds in the client service (simplify install steps and watch behavior). images/proxmox-ve: clarify create-manager.sh comments and simplify the partial-create detection logic to rely on the create lock. These changes make owner-scoped listing explicit, bookmarkable, and consistently enforced.
|
It's not a blocker to this PR, but can we see why the job for the preview container failed and get another issue opened. https://github.com/mieweb/opensource-server/actions/runs/28060284274/job/83073005593?pr=374 |
| * @param {{ user: string, isAdmin: boolean }} session - req.session | ||
| * @returns {string|undefined} username to filter by, or undefined for "all" | ||
| */ | ||
| function resolveUsernameFilter(requestedUser, session) { |
There was a problem hiding this comment.
I think this function should work differently. I'm thinking of the permissions like a venn-diagram. The two circles are "Requested User" and "Containers you have access to". For an admin (who has access to all containers) they always get the middle bit. For a non-admin, who only has access to their own containers, the venn-diagram should be a circle, but if they request a user other than themselves they get nothing instead. What I'm trying to get at is I don't want this to be a hard 403 failure for someone who's non admin. Consider
| Is Admin | Requested User | Returned Containers |
|---|---|---|
| N | Own | Own |
| N | All | Own |
| N | Someone else | None |
| Y | Own | Own |
| Y | All | All |
| Y | Someone else | Theirs |
There was a problem hiding this comment.
The low-level idea here is to leave the door open for a more complex permission model in the future. There's a universe where we want a non-admin gets access to containers they don't own but still let them filter by username using this same mechanism.
There was a problem hiding this comment.
resolveUsernameFilter now returns the requester's own username for non-admins requesting user=* (instead of 403). Admins still get all owners, however requesting a specific other owner still 403s.
There was a problem hiding this comment.
once this merges I'll work on "group" functionality and container sharing between individuals and created groups
| Owner filter. Omitted/empty returns the requesting user's own | ||
| containers (default). `*` returns every owner on the site and a | ||
| specific username returns that owner's containers; both are | ||
| admin-only and yield 403 for non-admins (except requesting yourself). |
There was a problem hiding this comment.
Per my other comment, rather than returning 403, I want the returned list to be the logical intersection of containers I have access to and containers I requested. See that comment for more details.
2 participants
Issue: #374
This pull request introduces an "All Containers" admin view to the container management system, allowing admins to see every container on a site, including the owner of each container. It also refactors the Docker Compose setup to prevent race conditions during dependency installation, and extends the API, client types, and OpenAPI schema to support the new functionality.
Admin "All Containers" View and API Enhancements:
/sites/{siteId}/containers/allAPI endpoint (admin-only) that returns all containers for a site, including theownerfield, with support for filtering bynodeId,hostname, andusername. [1] [2] [3] [4]ownerfield on containers, and the new query parameters. [1] [2] [3]ownerfield and to support flexible filtering for both user and admin list endpoints. [1] [2] [3] [4]Frontend: Containers List Page and API Integration:
ContainersListPageto support an "all"/"mine" toggle (visible to admins), display the container owner in the "All" view, and handle new query parameters for filtering. [1] [2] [3] [4] [5] [6] [7] [8]ownerfield and the newlistAllContainersAPI. [1] [2] [3]Docker Compose Dependency Installation Improvements:
nodeservice runsnpm ci(with--ignore-scriptsand manual patching), preventing race conditions and ensuring reliable dependency setup for both server and client. Theclientservice now waits fornodeto finish before building. [1] [2] [3]