Analyze public legacy UI versus repo UI and track missing replacement features #15

Closed
opened 2026-07-29 13:36:00 +02:00 by daniels · 0 comments
Owner

Problem

Before removing legacy code, we need a tracked analysis of differences between the current public Importarr UI at https://importarr.example.invalid/ and the repo-managed replacement currently in the Importarr repository.

The current public UI is served by the legacy example-host importarr-status.py, while the repo contains a different FastAPI UI. The reinstall must not accidentally lose useful operator features.

Known current public legacy UI/API features

Observed from https://importarr.example.invalid/ and example-host scripts:

  • top summary badges: videos ready, unpacking count, ready GiB, processed totals
  • status card with systemd service/timer state, runtime, memory current/peak
  • current-file card from /run/manual-media-import/status.json
  • processed counters from /var/log/manual-media-import.log
  • warnings such as old manual queue files
  • manual batch add form backed by /var/lib/importarr/manual-batches.json
  • jobs table with ready/unpacking states, progress/size, runtime/waiting
  • history section from recent log records
  • recent log view
  • JSON endpoints:
    • /api/status
    • /api/queue
    • /api/logs?limit=100
    • /health

Repo replacement areas to compare

  • FastAPI routes and JSON shapes
  • template/static UI
  • queue/status datastore
  • worker/timer integration
  • history/log parsing
  • systemd status reporting
  • manual batch behavior

Acceptance criteria

  • Produce a checklist mapping every public legacy UI/API feature to one of:
    • implemented in repo
    • partially implemented in repo
    • missing and tracked by a dedicated issue
    • intentionally dropped with rationale
  • Create/confirm dedicated implementation issues for each missing functional area.
  • Add the checklist to repo documentation or issue comments before the legacy service is removed.
## Problem Before removing legacy code, we need a tracked analysis of differences between the current public Importarr UI at `https://importarr.example.invalid/` and the repo-managed replacement currently in the Importarr repository. The current public UI is served by the legacy example-host `importarr-status.py`, while the repo contains a different FastAPI UI. The reinstall must not accidentally lose useful operator features. ## Known current public legacy UI/API features Observed from `https://importarr.example.invalid/` and example-host scripts: - top summary badges: videos ready, unpacking count, ready GiB, processed totals - status card with systemd service/timer state, runtime, memory current/peak - current-file card from `/run/manual-media-import/status.json` - processed counters from `/var/log/manual-media-import.log` - warnings such as old manual queue files - manual batch add form backed by `/var/lib/importarr/manual-batches.json` - jobs table with ready/unpacking states, progress/size, runtime/waiting - history section from recent log records - recent log view - JSON endpoints: - `/api/status` - `/api/queue` - `/api/logs?limit=100` - `/health` ## Repo replacement areas to compare - FastAPI routes and JSON shapes - template/static UI - queue/status datastore - worker/timer integration - history/log parsing - systemd status reporting - manual batch behavior ## Acceptance criteria - Produce a checklist mapping every public legacy UI/API feature to one of: - implemented in repo - partially implemented in repo - missing and tracked by a dedicated issue - intentionally dropped with rationale - Create/confirm dedicated implementation issues for each missing functional area. - Add the checklist to repo documentation or issue comments before the legacy service is removed.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: daniels/importarr#15