Add optional groups for monitors within a status page - #732
Open
Kukks wants to merge 5 commits into
Open
Conversation
Status pages can now visually group their monitors under named sections
(like Uptime Kuma). Each pages_monitors row gets a nullable group_name
column; UI renders ungrouped monitors first (no header — preserving the
pre-groups layout) then one bordered section per group with the group
name as an h2 header.
API: POST /api/v4/pages and PATCH /api/v4/pages/{path} now accept
either the existing monitors: string[] form, or a richer
monitors: Array<{ tag, group?, position? }> form. Responses also include
a group field per monitor. Old clients are unaffected.
Admin dashboard UI is not updated in this PR — groups can be set via
the public API. Adding admin controls is a sensible follow-up.
Migration is additive (nullable column); existing pages render
identically (single group with name=null).
The Page Monitors editor now renders monitors as group sections with HTML5 drag-and-drop between groups, an inline 'Add group' control, and arrow buttons that reorder within a section. The Ungrouped section is always shown as a drop target so monitors can be returned to the flat list. Backend: AddMonitorToPage takes an optional group_name; a new UpdatePageMonitorGroup controller (and matching repository helper + dbimpl binding + /manage/api action) sets/clears a single monitor's group, called optimistically on each drop. Empty groups created via 'Add group' are local-only until a monitor is dragged in.
Firefox (and Chrome in some cases) cancels a drag silently if no data is set on the dragstart event. We weren't calling dataTransfer.setData(), so the row's draggable attribute was effectively a no-op there. Three changes: 1. dragstart now writes the tag as text/plain and sets effectAllowed=move. 2. dragover always calls preventDefault (not gated on the draggedTag state) so a drop can still complete if reactive state hasn't flushed. 3. drop falls back to reading the tag from dataTransfer when draggedTag is null for any reason.
HTML5 native drag-and-drop doesn't fire from touch events on mobile browsers, so the previous UX broke for any admin on a phone or tablet. Swap to a per-row 'Move to' dropdown that works identically on touch and desktop, matching the existing arrow-button + remove-button pattern on each row. - Each monitor row gets a folder-input icon button; clicking it opens a menu listing the other groups + Ungrouped (or 'No groups yet' guidance when none exist). - Add group input no longer references project-specific names; the placeholder is just 'Group name'. - Drag handlers, draggable attribute, drop targets, and visual drop-target feedback are all removed. Section divs stay for structure and the rest of the UX (arrow reorder, remove, add) is unchanged.
Every /manage/api action must be allow-listed in allPerms.ts; missing entries 400 with 'Unknown action' before the dispatcher branch is reached. The Move-to-group menu was hitting this — clicking a group optimistically updated the UI then reverted on the failed save. Tested locally end-to-end with playwright: clicking a group in the Move-to menu now returns 200, the change persists across reload, and the public page renders the new group header.
|
@rajnandan1 the group notion is really great, is it possible to validate this PR ? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds optional groups for monitors within a status page, matching the way Uptime Kuma groups monitors under named sections on a single page.
Each
pages_monitorsrow gets a nullablegroup_namecolumn. The public page renders ungrouped monitors first (no header — identical to the pre-groups layout) then one bordered section per group with the group name as anh2header.Live
Running on this PR at https://status.arklabs.xyz:
The 3 sibling pages (
/mainnet,/mutinynet,/signet) are deliberately ungrouped to show backward-compat: a page with nogroup_nameon any monitor renders exactly as it did before this PR.API
POST /api/v4/pagesandPATCH /api/v4/pages/{path}now accept either of:or
Responses also include a
groupfield per monitor. Old clients are unaffected.Admin UI
Manage → Pages → [page] now renders monitors as group sections with:
Optimistic updates on each move via a new
updatePageMonitorGroup/manage/apiaction; the existingreorderPageMonitorsaction is reused with a flat tag order.Backward compatibility
group_nameis nullable with no default.name=null, no header).monitors: string[]; admin still callsaddMonitorToPagethe same way (new monitors default to ungrouped).Out of scope
Docker
Combined image (this PR + #731):
docker pull kukks/kener:rss-and-groups