yolo/arr
3
0
Fork 0
Code Issues 12 Pull Requests Actions Packages Projects Releases Wiki Activity

Policy and root CRUD: API endpoints and a settings view #116

New Issue
Closed
opened 2026-08-23 12:50:29 +01:00 by naps62-yolo · 1 comment
naps62-yolo commented 2026-08-23 12:50:29 +01:00
Owner
Copy Link
Copy Source

Policies and roots are DB rows seeded by migrations and today editable only via SQL inside the container. Make both manageable through the app, API first, then a settings view in the SPA.

API (arr-api):

  • GET /api/policies, GET /api/policies/:id, POST /api/policies, PUT /api/policies/:id, DELETE /api/policies/:id.
  • POST /api/roots, PUT /api/roots/:id, DELETE /api/roots/:id alongside the existing GET /api/roots.
  • Validate payloads against the shapes arr-core already defines (required_audio, hdr_rules, size_bands keyed by resolution with floor_gib/target_gib/penalty_points_per_gib_over, resolution_pref, source_weights, score_weights incl. resolution_step). Reject unknown resolutions and malformed JSON with a 422 naming the field, not a 500.
  • Deleting a policy still referenced by a root, or a root that still owns movies/series, is a 409 with a clear error — never orphan rows.
  • Routes registered through utoipa_axum::routes like every other endpoint, sqlx compile-time-checked queries, just db-prepare refreshed.

Web (web/):

  • A settings view (own route, like library/queues) listing roots and policies.
  • Editing a policy: a form over the real fields — size bands per resolution, score weights, resolution preference order, audio/HDR rules. Numbers as numbers, not raw JSON textareas, except hdr_rules/required_audio may start as validated JSON editors if a full form is disproportionate.
  • Creating/editing/deleting roots: name, kind, audience, path, policy selector.
  • Reuse the existing view patterns and the .impeccable/design.json tokens — no new colours or spacing literals. This is a settings form, not a new design; match how library/queues views are built.

Out of scope: authentication, per-title overrides, any change to how the daemon consumes policies (it already reads rows per tick).

Read-time deck rescoring (#114) means a policy edit shows up in search decks immediately — worth a manual check at the end.

Policies and roots are DB rows seeded by migrations and today editable only via SQL inside the container. Make both manageable through the app, API first, then a settings view in the SPA. **API (`arr-api`):** - `GET /api/policies`, `GET /api/policies/:id`, `POST /api/policies`, `PUT /api/policies/:id`, `DELETE /api/policies/:id`. - `POST /api/roots`, `PUT /api/roots/:id`, `DELETE /api/roots/:id` alongside the existing `GET /api/roots`. - Validate payloads against the shapes `arr-core` already defines (required_audio, hdr_rules, size_bands keyed by resolution with floor_gib/target_gib/penalty_points_per_gib_over, resolution_pref, source_weights, score_weights incl. resolution_step). Reject unknown resolutions and malformed JSON with a 422 naming the field, not a 500. - Deleting a policy still referenced by a root, or a root that still owns movies/series, is a 409 with a clear error — never orphan rows. - Routes registered through `utoipa_axum::routes` like every other endpoint, sqlx compile-time-checked queries, `just db-prepare` refreshed. **Web (`web/`):** - A settings view (own route, like library/queues) listing roots and policies. - Editing a policy: a form over the real fields — size bands per resolution, score weights, resolution preference order, audio/HDR rules. Numbers as numbers, not raw JSON textareas, except hdr_rules/required_audio may start as validated JSON editors if a full form is disproportionate. - Creating/editing/deleting roots: name, kind, audience, path, policy selector. - Reuse the existing view patterns and the `.impeccable/design.json` tokens — no new colours or spacing literals. This is a settings form, not a new design; match how library/queues views are built. Out of scope: authentication, per-title overrides, any change to how the daemon consumes policies (it already reads rows per tick). Read-time deck rescoring (#114) means a policy edit shows up in search decks immediately — worth a manual check at the end.
naps62-yolo added the area/apidifficulty/moderatephase/5-uitype/feature labels 2026-08-23 12:50:34 +01:00
naps62-yolo commented 2026-08-23 15:15:23 +01:00
Author
Owner
Copy Link
Copy Source

Done. Policy and root CRUD in arr-api (validation naming fields with 422, 409 on referenced deletes, sqlx-checked queries via just db-prepare), settings view at /settings over the real policy fields using existing tokens. just ci green: 335 tests pass.

Merge commit: 0c87bf9

Done. Policy and root CRUD in arr-api (validation naming fields with 422, 409 on referenced deletes, sqlx-checked queries via just db-prepare), settings view at /settings over the real policy fields using existing tokens. just ci green: 335 tests pass. Merge commit: 0c87bf9
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
arr-api
 area/ci
CI and test harness
 area/compat
arr-compat
 area/core
arr-core
 area/daemon
arr-daemon
 area/db
arr-db
 area/dl
arr-dl
 area/indexer
arr-indexer
 area/infra
workspace and tooling
 area/meta
arr-meta
 area/parse
arr-parse
 area/probe
arr-probe
 area/subs
arr-subs crate: providers, extraction, translation, sync
 area/web
web/
 difficulty/easy
bounded, obvious approach, few files
 difficulty/hard
subtle correctness or cross-cutting
 difficulty/moderate
multiple files, judgement, an interface to design
 difficulty/trivial
one file, mechanical, no design decisions
 phase/1-skeleton
workspace, CI, config, database, empty API and SPA
 phase/2-logic
parsing and policy engine, pure, no network
 phase/3-sourcing
TMDB and Prowlarr, read-only
 phase/4-movies
movies end to end
 phase/5-ui
search, buckets, library views, queues
 phase/6-tv
seasons, episodes, tracking, derived status
 phase/7-people
owner tags and notifications
 phase/8-compat
Jellyseerr shim
 phase/9-subtitles
build order: subtitles, DESIGN.md §15
 type/bug
type/chore
type/feature
type/test
No Label area/api difficulty/moderate phase/5-ui type/feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
hermes (Hermes (agent)) naps62 (Miguel Palhas) naps62-yolo (naps62-yolo (agent))
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yolo/arr#116
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?