Create tickets

This commit is contained in:
Hugh Kaznowski
2026-09-05 18:31:22 +01:00
parent 0a21582282
commit 893464b3b1
13 changed files with 112 additions and 0 deletions
@@ -0,0 +1,7 @@
# Remove "Dashboard" nav bar entry
There should not be a "Dashboard" entry in the nav bar.
## Acceptance criteria
- The nav bar no longer shows a "Dashboard" item.
- Any route/functionality it pointed to is either removed or reachable via its correct existing entry (e.g. "Dashboards").
@@ -0,0 +1,7 @@
# Make Alerts section collapsible
Alerts section should be collapsible.
## Acceptance criteria
- The Alerts section can be collapsed and expanded, consistent with how other collapsible sections behave.
- Collapsed/expanded state persists in a way consistent with the rest of the UI (e.g. across reloads if other sections do so).
+13
View File
@@ -0,0 +1,13 @@
# Investigate and design JSON log input handling
Figure out what should and can happen if the logs are JSON input. What happens if the JSON is invalid during ingestion. What useful functionality can we have.
## Notes
This is an investigation/design ticket before implementation. Needs a decision on:
- How JSON-formatted log lines are detected and parsed.
- What happens on invalid/malformed JSON during ingestion (drop, store raw, flag, error metric, etc).
- What functionality JSON structure could unlock (field extraction, filtering/querying by field, structured display in the log viewer, etc).
## Acceptance criteria
- A short design decision is written (e.g. via `repowise decision add`) covering: detection, invalid-JSON handling, and prioritized feature ideas.
- Follow-up implementation ticket(s) filed based on the decision.
@@ -0,0 +1,8 @@
# Remove duplicate "grey" theme, keep "dark"
Dark and grey are the same thing. Keep dark, remove grey.
## Acceptance criteria
- The "grey" theme option is removed from theme selection UI and settings.
- Any references/config values for "grey" are migrated or aliased to "dark" so existing saved settings don't break.
- "dark" remains as the single equivalent theme.
@@ -0,0 +1,7 @@
# Use sharp/angular tops for timeline event spikes
The event spikes in the timeline should not have rounded tops. They should be sharp angular, for clearer reading.
## Acceptance criteria
- Timeline event spikes render with sharp, angular peaks instead of rounded/curved tops.
- Change is visually verified in the browser (light and dark theme).
@@ -0,0 +1,8 @@
# Collapse sections by clicking title bar instead of a dedicated button
Instead of having collapse buttons on the main view components/categories, clicking the title bars should collapse them.
## Acceptance criteria
- Clicking a section's title bar toggles its collapsed/expanded state.
- Dedicated collapse buttons are removed (or repurposed as a visual indicator only, e.g. a chevron, without being the sole click target).
- Title bar remains usable for any other existing interactions (if any) without conflicting with the collapse click.
@@ -0,0 +1,7 @@
# Simplify Dashboards section header label
The Dashboards section should not say `Dashboards — profile "Default"`. It should just say `Dashboards`.
## Acceptance criteria
- The Dashboards section header shows just "Dashboards", with no profile name suffix.
- Profile context, if still needed elsewhere, is shown some other way (or removed if not needed).
+8
View File
@@ -0,0 +1,8 @@
# Add worked examples to docs pages
The docs pages should have examples of how to achieve something. Particularly the dashboards and panels section. But also metrics and params and the others.
## Acceptance criteria
- Dashboards and panels docs include concrete, worked examples showing how to accomplish common tasks.
- Metrics and params docs (and other doc sections) get similar example treatment.
- Examples are accurate against current functionality (verified against the actual behavior, not just written speculatively).
@@ -0,0 +1,9 @@
# Add "All dashboards" option with print-friendly stacked layout
The dashboards part should keep the click-to-select dashboards, however it should have an "All dashboards" option. In that situation, the dashboards are displayed one after another with named separators. This is important so that it is possible to print the page or print the dashboards section. Printing itself is a browser capability we don't need to implement, but the page should be laid out in a way that's compatible with it.
## Acceptance criteria
- Existing click-to-select single-dashboard view is preserved.
- New "All dashboards" option stacks all dashboards vertically, one after another, each preceded by a named separator (dashboard name/title).
- The stacked layout uses normal document flow (no fixed-height scroll containers that would clip content) so the browser's native print function can render the full stacked content across pages.
- Verified visually in browser, including a print-preview check.
+8
View File
@@ -0,0 +1,8 @@
# Make layout sections resizable
The sections should be resizable. Currently the log view is too small and can't be resized.
## Acceptance criteria
- Main layout sections (including the log view) can be resized by the user, e.g. via a drag handle between panes.
- Resized proportions are reasonably persisted (e.g. in local storage) across reloads, consistent with other UI state persistence in the app.
- Log view in particular can be enlarged.
+8
View File
@@ -0,0 +1,8 @@
# Add approximate heap/memory tracker for ingested logs
An approximate heap tracker should exist. For each log ingested, its bytes are counted. If it's ever dropped, its bytes are subtracted. The size can be displayed on the frontend as comma-separated bytes.
## Acceptance criteria
- Ingestion path increments a running byte counter by each log's approximate size when ingested.
- Eviction/drop path decrements the counter by that log's size when it's dropped.
- Current total is exposed via the API and displayed on the frontend, formatted with comma separators (e.g. "12,345,678 bytes").
@@ -0,0 +1,14 @@
# Merge "custom themes" and "configured/imported CSS" into one concept
Custom themes and configured/imported CSS are the same thing.
## Current behavior (notes)
- Imported CSS (as pasted content or file upload) is base64-encoded and stored in the settings file.
- The "name" field is not a file name — it's a human-readable name, labeled just "name" in the UI. It gets displayed alongside the other (built-in) themes.
- The built-in themes are also auto-inserted into the settings JSON.
- Imported CSS entries can be "deleted", which removes them from the settings JSON.
## Acceptance criteria
- The "custom themes" and "configured/imported CSS" features are consolidated into a single mechanism.
- Duplicate UI, settings, and code paths for the two are removed.
- Existing user configuration for either is migrated or aliased so it keeps working under the unified mechanism.
@@ -0,0 +1,8 @@
# Combine ntfy sink URL and topic into one line
The ntfy sink should not be 2 input fields stacked per line. Instead the URL input and topic input should sit on the same line, formatted like `<url-input>/<topic-input>` (not literally that string, but visually structured that way), with a clear separator between them indicating how the two values will be combined/used.
## Acceptance criteria
- The ntfy sink's URL and topic inputs are laid out on a single line instead of one per line.
- A clear visual separator (e.g. a `/`) sits between the two inputs, indicating they combine into one destination (server URL + topic).
- Existing saved URL/topic values still populate correctly into the two inputs.