5 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5.5	327d49428f	feat(auth): store Subsonic API keys hashed; a new key is shown once (M462 #4983) ... users.api_token held each user's apiKey in plaintext and was looked up by equality, so a leaked row or backup handed out working keys. Migration 0063 replaces it with api_token_hash (sha256, hex), computed in place from the existing keys so every Subsonic client keeps working. The key can no longer be read back: GET /api/me/api-token is gone, and POST returns the new key once. Settings shows it right after Regenerate with a copy button and a "won't be shown again" note. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 09:42:35 -04:00
bvandeusen	5c386dc73e	fix(server,web/m7-cover-sources): forward-fix CI ... Three failures from the prior push: 1. internal/api/library.go and 3 other callers of q.GetArtistByID broke because T2 modified the query to use an explicit column list, making sqlc generate GetArtistByIDRow instead of returning dbq.Artist. dbq.Artist already has every column added by migration 0018 (artist_thumb_path / artist_fanart_path / artist_art_source / artist_art_sources_version), so the explicit column list was unnecessary work. Revert the SELECT to SELECT *, regenerate sqlc, GetArtistByIDRow disappears, all callers compile again. 2. internal/tracks/service_test.go missed the dataDir parameter added to NewService in T9. Add "" as the 4th arg to every test call site (tests don't exercise the artist-art cleanup path; the empty dataDir is fine). 3. integrations.test.ts:356's mock.calls.filter callback had a too-narrow type annotation that svelte-check rejected. Relax to any[] to match what mock.calls actually is.	2026-05-06 13:22:36 -04:00
bvandeusen	a8fd33d4ed	chore(lint): clear pre-existing CI lint debt ... Nine golangci-lint failures accumulated across M7 #352, #372, and 6d1709c that were never surfaced because test-go never ran green long enough to reach the lint step. The first push to land cleanly through vet (the M7 #363 slice) ran lint and exposed them. - errcheck: discard the error on defer Close() in collage.go, collage_test.go, and server_test.go. - gofmt -s: re-run on config.go and playlists_test.go. - goimports: move the stray "time" import from the local-module group to stdlib in server_test.go. - revive unused-parameter: rename ctx to _ on stubScanner.Scan and fakeLidarrUnmonitorer.UnmonitorTrack (test stubs); on tracks.Service's adminID, add //nolint:revive directive rather than renaming because the HTTP handler passes admin.ID (a real authed-user UUID) and the existing comment already flags it as reserved for the audit-log follow-up.	2026-05-03 18:59:58 -04:00
bvandeusenandClaude Opus 4.7	f6975cfad3	fix(tracks): rewrite RemoveTrack — direct os.Remove + optional Lidarr unmonitor ... Replaces commit 50a231f's wrong-shape Lidarr-routed delete. The previous design called lidarrquarantine.DeleteViaLidarr for Lidarr-managed tracks, which deletes the entire **album** in Lidarr (Lidarr is album-granular, no per-track delete API) — silently dropping sibling tracks the operator didn't ask to remove. New shape per spec revision 723eee9: - Always: os.Remove + DB delete + cascade through Minstrel. - When unmonitor=true AND track has mbid: call new Lidarr.UnmonitorTrack primitive so Lidarr won't replace. Failure is non-fatal — file is already gone, DB consistent; the lidarrUnmonitorFailed bool flows to the wire response so the UI can surface a follow-up "unmonitor manually" toast. Service signature changes from `(trackID, adminID) → (delAlbum, delArtist, err)` to `(trackID, adminID, unmonitor) → (delAlbum, delArtist, lidarrFailed, err)`. Adds Lidarr.UnmonitorTrack with full three-step API walk: 1. GET /api/v1/album?foreignAlbumId={mbid} → Lidarr's internal album id 2. GET /api/v1/track?albumId={id} → match track by foreignTrackId 3. PUT /api/v1/track/monitor with {trackIds:[id], monitored:false} Refactors post() into a shared bodyRequest() so put() reuses the same status-code → typed-error mapping. The album mbid is captured *before* the cascade-delete transaction — DeleteAlbumIfEmpty may remove the album row, after which a post-commit GetAlbumByID returns ErrNoRows and the unmonitor walk would have nothing to walk against. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-02 22:35:34 -04:00
bvandeusenandClaude Opus 4.7	50a231fdc1	feat(tracks): RemoveTrack service with Lidarr-aware delete + cascade ... RemoveTrack handles both Lidarr-managed (delegates to existing lidarrquarantine.DeleteViaLidarr) and non-Lidarr (direct os.Remove) file deletion, then runs the cascade album-if-empty / artist-if-empty DB cleanup in a single transaction. Lidarr errors propagate as typed errors so the API layer can map them to the existing wire codes. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-02 21:58:12 -04:00