314 Commits

Author SHA1 Message Date
kikootwo bba4af7398 Fix indexerIds serialization in ProwlarrService
Update axios paramsSerializer and request logic to send indexerIds as repeated query parameters (indexerIds=1&indexerIds=2) instead of a comma-separated string. This ensures compatibility with Prowlarr's expected API format.
2026-01-28 11:41:57 -05:00
kikootwo 1cefa437b7 Add ASIN/ISBN fields to library and improve matching
Introduces `asin` and `isbn` fields to the PlexLibrary schema and database, with migration and indexing for fast lookups. Updates scan and recently-added processors to persist ASIN/ISBN from both Plex and Audiobookshelf backends. Enhances matching logic to prioritize exact ASIN matches using the new fields, improving match accuracy for Audiobookshelf users. Also includes minor improvements: fixes cover art handling for cached thumbnails, adds download URL validation in Prowlarr and qBittorrent integrations, and updates documentation to reflect these changes.
2026-01-28 11:41:57 -05:00
Claude a3381cba31 Fix qBittorrent service not reloading config after settings change
Root cause: Singleton caching issue
The qBittorrent service uses a singleton pattern with a configLoaded flag.
Once initialized, it NEVER re-reads the database config, even when the
user changes settings via the admin settings page.

Flow showing the bug:
1. Wizard saves download_dir to database ✓
2. First torrent: service reads config, creates singleton, sets configLoaded=true ✓
3. User changes download_dir in settings page ✓ (database updated)
4. Next torrent: getQBittorrentService() returns CACHED singleton ✗
5. Cached singleton has OLD download_dir value in this.defaultSavePath ✗
6. Category check shows "already has correct save path: /old/path" ✗
7. Download goes to wrong location ✗

The singleton check (line 745):
  if (!qbittorrentService || !configLoaded) {
    // Only runs if service doesn't exist or config failed
  }
Once both exist, this block is SKIPPED forever!

Fix:
1. Added invalidateQBittorrentService() function
   - Resets qbittorrentService = null
   - Resets configLoaded = false
   - Forces reload from database on next use

2. Call invalidation from settings APIs:
   - After updating paths (download_dir, media_dir)
   - After updating download client (URL, credentials)

3. Next torrent addition:
   - getQBittorrentService() sees null singleton
   - Re-reads config from database
   - Creates new service with current download_dir
   - Category updated with correct path

Benefits:
- Settings changes take effect immediately
- No app restart needed
- Category save path always matches current config
- Download client credentials always current

Updated documentation to explain singleton invalidation pattern.
2026-01-28 11:41:57 -05:00
Claude 0222bca9f7 Fix category save path not updating - check before create/edit
Root cause: We were blindly calling createCategory (409 if exists) then
editCategory (409 for unknown reason), but editCategory was failing and
the category kept its old save path, causing downloads to wrong location.

The 409 from editCategory doesn't mean 'already has this path', it means
the operation failed. Without checking first, we don't know why.

New approach:
1. GET /torrents/categories first to check current state
2. If category doesn't exist: create it with correct save path
3. If category exists with wrong path: edit to update save path
4. If category exists with correct path: skip (no API call needed)

Benefits:
- Avoids unnecessary 409 errors
- Only calls editCategory when actually needed
- Logs show exactly what's happening (create/update/skip)
- Handles both savePath and save_path response formats (v4.4.0+ compat)
- Better error logging with full response details

This ensures category save path is ACTUALLY updated when user changes
download_dir setting, fixing downloads going to wrong location.

References:
- qBittorrent API docs: https://github.com/qbittorrent/qBittorrent/wiki/WebUI-API-(qBittorrent-4.1)
- Issue #15969: save_path vs savePath inconsistency in API v2.8.4+
2026-01-28 11:41:57 -05:00
Claude 0fa10941e1 Handle 409 from editCategory as non-error
qBittorrent's /torrents/editCategory endpoint returns 409 (Conflict) when
the category already has the specified save path (no change needed).

This is expected behavior when:
- User hasn't changed download_dir setting since last torrent
- Category already has correct save path

Previously logged as warning with full error stack trace, making it look
like an error when it's actually normal operation.

Changes:
- Check for 409 status code from editCategory
- Log friendly message: 'Category already has save path: /path'
- Only log unexpected errors with console.warn

Now both createCategory and editCategory handle 409 gracefully:
- createCategory 409 = category exists
- editCategory 409 = category already has this path
Both are expected, not errors.
2026-01-28 11:41:57 -05:00
Claude 74010a1ebd Improve logging for qBittorrent category creation
The 409 (Conflict) status code from qBittorrent's createCategory endpoint
means 'category already exists', which is expected behavior, not an error.

Previously, the full error object was logged with console.log(), making it
look like an error in the logs when it's actually normal operation.

Changes:
- Check for 409 status code specifically
- Log friendly message: 'Category already exists' for 409
- Only log unexpected errors with console.warn
- Cleaner logs that don't alarm users

The flow still works correctly:
1. Try createCategory (succeeds if new, 409 if exists)
2. Always editCategory to update save path to match current config
3. Both operations complete successfully
2026-01-28 11:41:56 -05:00
Claude 5188fe1727 Fix qBittorrent category save path not updating when config changes
Previously, when a user changed the download_dir setting after initial
setup, the qBittorrent category "readmeabook" would retain the old save
path. This could cause torrents to download to the wrong location,
depending on qBittorrent's Automatic Torrent Management (ATM) settings.

Root cause:
- ensureCategory() only created the category if it didn't exist
- createCategory API is idempotent but doesn't update existing categories
- If download_dir changed from /downloads to /downloads/RMAB, category
  would still have savePath=/downloads

qBittorrent behavior:
- If ATM enabled: category savePath overrides per-torrent savepath
- If ATM disabled: per-torrent savepath takes precedence

Fix:
- ensureCategory() now calls both createCategory AND editCategory
- createCategory: ensures category exists (idempotent)
- editCategory: updates save path to match current download_dir config
- This guarantees category path is always synced with database config

Benefits:
- Users can change download_dir setting and it takes effect immediately
- Works regardless of ATM settings in qBittorrent
- No manual qBittorrent category management needed

Updated documentation/phase3/qbittorrent.md to explain category
management and save path synchronization.
2026-01-28 11:41:56 -05:00
Claude ef98dcf438 Fix file copy location to respect configured media directory
Previously, files were always being copied to /media/audiobooks regardless
of the configured media directory in settings. This was caused by:

1. FileOrganizer singleton reading from MEDIA_DIR env var (never set)
   instead of database config 'media_dir'
2. Hardcoded /media/audiobooks fallback being used when env var not found
3. Three locations passing hardcoded paths to addOrganizeJob (unused)

Changes:
- Modified getFileOrganizer() to read media_dir from database config
- Made targetPath parameter optional in addOrganizeJob (not used by processor)
- Removed hardcoded /media/audiobooks paths from all addOrganizeJob calls
- Updated organize-files processor to await getFileOrganizer()
- Updated documentation to reflect configuration behavior

Files now correctly copy to the directory configured in setup wizard or
settings page, with /media/audiobooks only as fallback if not configured.

Fixes: User-reported issue where configured media directory was ignored
2026-01-28 11:41:56 -05:00
Claude a59bbedd00 Fix critical bug: searches now respect enabled indexers
**Problem:** Prowlarr searches were querying ALL indexers instead of only
the ones enabled in user settings, causing torrents to be selected from
disabled/untrusted indexers.

**Root Cause:** The prowlarr.search() method didn't filter by indexer IDs,
and callers weren't passing enabled indexer IDs to the search.

**Changes:**
1. Added indexerIds parameter to SearchFilters interface
2. Updated prowlarr.service.ts search() to filter by indexerIds
3. Updated search-indexers.processor.ts to fetch and pass enabled indexer IDs
4. Updated interactive-search route to fetch and pass enabled indexer IDs
5. Added validation: search fails if no indexers are configured/enabled
6. Updated documentation to reflect indexer filtering behavior

**Impact:**
- Manual search: Only searches enabled indexers
- Interactive search: Only searches enabled indexers
- RSS monitoring: Already correctly filtered (no changes needed)

**Testing:** TypeScript type checking passed with no errors
2026-01-28 11:41:56 -05:00
kikootwo 477a30c2eb Update .gitignore and mask 'secret' in settings API
Added /cache, /redis, and /pgdata to .gitignore to prevent committing local data directories. Updated the admin settings API to also mask values for keys containing 'secret' in addition to other sensitive keys.
2026-01-28 11:41:56 -05:00
Claude 7c63de8fb1 Fix OIDC admin approval chicken-and-egg problem
Allow first user to bypass admin approval requirement when using
'admin_approval' access control method. The first user is auto-approved
and becomes admin, avoiding the situation where there's no admin to
approve the first user.

**Before:** First user gets stuck in pending_approval state
**After:** First user bypasses approval and becomes admin automatically

Subsequent users still require admin approval as expected.
2026-01-28 11:41:56 -05:00
Claude 7107700834 Display OIDC access denied errors on login page
Extract error messages from URL query parameters and display them
in the existing error box on the login page, then clean up the URL.

This fixes the UX issue where OIDC access denied errors were only
visible in the URL bar as query parameters.
2026-01-28 11:41:56 -05:00
Claude 5a9b6b4b46 Add comprehensive OIDC access control and admin role mapping
Implements full OIDC configuration UI and backend support for access control and admin permissions.

**Access Control Features:**
- Open access (anyone can log in)
- Group/claim based access (require specific group membership)
- Allowed list (whitelist specific emails/usernames)
- Admin approval (manual approval required for new users)

**Admin Role Mapping:**
- Automatic admin role assignment based on OIDC claims
- Configurable claim name and value (default: groups claim)
- First user always becomes admin
- Dynamic role updates on each login

**Setup Wizard:**
- Updated OIDCConfigStep with comprehensive OIDC settings
- Access control method selector with conditional fields
- Admin role mapping configuration with examples
- Improved UX with clear sections and helpful descriptions

**Admin Settings:**
- Expanded OIDC section with all new configuration options
- Proper JSON array handling for allowed emails/usernames
- Visual organization matching setup wizard

**Backend:**
- Updated setup complete API to persist new OIDC fields
- Updated OIDC settings API for all new configuration
- Updated settings GET endpoint to return new fields with defaults
- Proper comma-separated to JSON array conversion

**Documentation:**
- Comprehensive OIDC section in auth.md
- Configuration examples and use cases
- Clear distinction between access control and admin roles
- Default values documented

All changes tested and ready for production use.
2026-01-28 11:41:56 -05:00
kikootwo a3ba192fbd Initial commit 2026-01-28 11:41:24 -05:00