refactor: Add UI functionality for deleting connections and pagination

[cersho]

... for runs

• Implemented integration tests for deleting connections from the UI, ensuring successful deletion and confirmation messages.
• Added pagination support for runs in the UI, allowing users to navigate between pages of run records.
• Enhanced the HTML templates with new styles for action buttons and menus, improving the user experience.
• Introduced confirmation dialogs for destructive actions like deleting connections and notifications, ensuring user awareness of irreversible actions.
• Updated JavaScript functions to handle new UI interactions and maintain state across different forms and dialogs.

---

Summary by cubic

Adds pagination to the Runs page and a safe delete flow for connections. Also adds edit/update actions with confirmation dialogs and action menus across the UI, and fixes SMTP edit behavior to keep passwords when blank.

• New Features

  • Runs pagination with Prev/Next and “Page N”; new repo method ListRecentRunsPage(offset, limit) and page-aware polling/selection.
  • Delete connections from the UI via POST /connections/{id}/delete with a confirm dialog and success flash.
  • Edit/update flows and action menus:
    • Connections /connections/{id}/update
    • Remotes update/delete
    • Notifications update and test
    • Schedules update (respects scheduler), enable/disable, delete
    • Health checks “archive” action
  • Reusable confirmation modal for destructive actions (connections, remotes, notifications, schedules, health checks).
  • Integration tests for deleting a connection, runs pagination.

• Bug Fixes

  • Editing SMTP notifications no longer clears the password when the field is left blank; UI clarifies this and a test covers the behavior.

^{Written for commit b6dd14f. Summary will update on new commits.}

[cubic-dev-ai]

2 issues found across 4 files

Confidence score: 3/5

• There is a concrete user-impacting regression in internal/ui/handler.go: when editing SMTP settings with a blank form password, the patch still sends SMTPPassword and clears stored credentials.
• internal/ui/templates/app.html appears inconsistent with backend validation: the password looks optional in the edit UI, but submissions without re-entering it can fail when an SMTP username is present.
• Given the severity/confidence (6/10 and 5/10, both high confidence), this carries moderate merge risk until SMTP edit behavior is aligned between handler and template.
• Pay close attention to internal/ui/handler.go, internal/ui/templates/app.html - prevent unintended password clearing and keep UI expectations consistent with validation rules.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="internal/ui/templates/app.html">

<violation number="1" location="internal/ui/templates/app.html:1246">
P2: SMTP edit clears the password but UI leaves it optional; submitting without retyping password fails validation when SMTP username is set.</violation>
</file>

<file name="internal/ui/handler.go">

<violation number="1" location="internal/ui/handler.go:1110">
P2: Do not send `SMTPPassword` in the patch when the form password is blank; it currently clears existing credentials during edits.</violation>
</file>

Architecture diagram

sequenceDiagram
    participant Client as Browser (UI)
    participant Server as UI Handler (Go)
    participant Repo as Repository (GORM)
    participant DB as Database (SQLite/PG)

    Note over Client, DB: NEW: Paginated Runs Flow
    Client->>Server: GET /runs?page=N
    Server->>Server: parsePositiveInt(page)
    Server->>Repo: NEW: ListRecentRunsPage(offset, limit)
    Repo->>DB: SELECT ... LIMIT {pageSize + 1} OFFSET {offset}
    DB-->>Repo: Run records
    Repo-->>Server: []BackupRun
    Server->>Server: Determine hasNext (len > pageSize)
    Server-->>Client: Render runs_section (with Prev/Next buttons)

    Note over Client, DB: NEW: Destructive Action Flow (e.g., Delete Connection)
    Client->>Client: User clicks "Delete"
    Client->>Client: NEW: Show #confirm-dialog (JS)
    
    alt User cancels
        Client->>Client: Close dialog
    else User confirms
        Client->>Server: NEW: POST /connections/{id}/delete
        Server->>Repo: DeleteConnection(ctx, id)
        Repo->>DB: DELETE FROM connections WHERE id = ?
        DB-->>Repo: Success
        Repo-->>Server: nil
        Server-->>Client: Render connections_section + Flash Message
    end

    Note over Client, DB: NEW: Resource Update Flow
    Client->>Client: NEW: setEditMode(trigger) - populate form
    Client->>Server: NEW: POST /{resource}/{id}/update
    Server->>Server: Validate & map form data
    Server->>Repo: Update{Resource}(ctx, id, data)
    Repo->>DB: UPDATE ... WHERE id = ?
    Repo-->>Server: Updated model
    Server-->>Client: Render updated section + Flash Message

Loading

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}