Skip to content

feat(admin): edit an allocation and a credential from the panel - #14

Merged
nickolasdeluca merged 2 commits into
mainfrom
feat/edit-allocations
Aug 26, 2026
Merged

nickolasdeluca merged 2 commits into
mainfrom
feat/edit-allocations

Conversation

@nickolasdeluca

Copy link
Copy Markdown
Owner

What

An allocation row and a credential row can now be edited in place from the admin panel.

  • Allocations — change the bound machine and the bandwidth override.
  • Credentials — rename the machine and change its bandwidth.

The edit swaps the row's action group for its fields, the same way a destructive action swaps it for a confirmation: the row stays visible and no modal covers the table.

Why

Both rows could only be toggled or destroyed. Changing which machine holds a name, or what bandwidth it gets, meant releasing the allocation and reserving it again. PATCH /api/reservations/{id} and PATCH /api/clients/{id} already accepted exactly these fields — only the panel had no way to send one.

Also

Store.UpdateClient did not trim or validate the name, so a rename to whitespace blanked the credential's only label; CreateClient has always refused that. It now returns client name is required, a message serverError already translates.

Limits kept

  • The pinned subdomain and TCP port stay immutable — release and reserve to change them.
  • Reservation bandwidth still participates in the min() resolved at registration, so a connected machine keeps its current limit until it reconnects. The status line says so.

Testing

  • go test ./... — 351 tests, all passing, including a new store test for the blank rename.
  • Exercised against make demo: PATCH on a reservation (client + bandwidth), a credential rename, and a blank name rejected with 400.

CreateClient trims the name and refuses an empty one; UpdateClient did
neither, so a rename to whitespace blanked the credential's only label.
The unique index is on (account_id, name), so a second blanked name would
then fail with a conflict nobody could explain.
Both rows could only be toggled or destroyed: changing which machine holds
a name, or what bandwidth it gets, meant releasing the allocation and
reserving it again. The API already took the PATCH; only the panel had no
way to send one.

The edit swaps the row's action group for its fields, the same way a
destructive action swaps it for a confirmation, so the row stays visible
and no modal covers the table it edits.

The pinned subdomain and port stay immutable, and bandwidth still resolves
at registration, so a connected machine keeps its current limit until it
reconnects -- the status line says so rather than leaving an operator to
wonder why nothing moved.
@nickolasdeluca
nickolasdeluca merged commit dbcc67f into main Aug 26, 2026
2 checks passed
@nickolasdeluca
nickolasdeluca deleted the feat/edit-allocations branch August 26, 2026 18:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant