feat: custom fields

[frcooper]

🚀 Pull Request

📝 Description

Adds library-scoped Custom Fields (STRING/NUMBER/DATE) and surfaces them in:

• Library Metadata Settings (create/delete custom fields)
• Book Metadata Editor (edit per-book values)
• File Naming Patterns via {custom:<name>} placeholders

Relates to #2081 #2128
Docs PR: booklore-app/booklore-docs#21

🛠️ Changes Implemented

• Added database schema to store custom field definitions and per-book values
• Added API endpoints for managing library custom fields and saving values
• Added UI management for library custom fields
• Added metadata editor support for custom field editing by type
• Added file-naming placeholder support for custom fields

🧪 Testing Strategy

• Backend: run ./gradlew test in booklore-api
• Manual: create/delete a custom field; edit a book’s custom field value; verify {custom:<name>} placeholder output
• Not run: browser-automation UI tests (e.g., ng test)

✅ Additional Automated Tests Added

• JUnit: service-layer coverage for library custom-field validation/ownership and per-book value parsing/persistence
• JUnit: mapper coverage for BookMetadataMapper.mapCustomFields() (defaults vs stored values; NUMBER/DATE formatting)
• JUnit: path placeholder coverage for {custom:<name>} in PathPatternResolver
• JUnit: BookMetadataUpdater scenarios where only custom fields changed (including when metadata is otherwise locked)

📸 Visual Changes (if applicable)

⚠️ Required Pre-Submission Checklist

• Code adheres to project style guidelines and conventions
• Branch synchronized with latest develop branch
• Automated unit/integration tests added/updated to cover changes
• All tests pass locally (./gradlew test for backend)
• Manual testing completed in local development environment
• Flyway migration versioning follows correct sequence (if database schema modified)
• Documentation pull request submitted to booklore-docs

💬 Additional Context (optional)

If reviewers want to sanity-check placeholder behavior quickly, create a custom field named e.g. Editor and reference it as {custom:Editor} in a file naming pattern.

---

🔒 Custom Field Locking

This PR now also includes per-book per-custom-field locking, matching the behavior/UX of the existing metadata locking:

• Backend: persisting locked state per book/custom-field value (book_custom_field_value.locked) and exposing it via customFieldLocks in the book metadata payload.
• Semantics: when a custom field is locked, incoming updates/deletes to that custom field’s value are ignored, but lock toggles are still persisted.
• UI: custom fields show lock/unlock buttons in the metadata editor, and locked custom-field inputs are disabled. Custom fields are also included in “Lock All / Unlock All”.

(Commit: 48bff66c – “Add per-custom-field locking (backend+UI)”)

✅ Locking Test Coverage

Expanded JUnit coverage for lock edge-cases (locked fields ignore deletes, lock-only updates create/persist lock rows, mapper defaults locked=null to false).

(Commit: 6722147f – “Expand JUnit coverage for custom-field locking”)

[balazs-szucs]

Hi, thanks for your work. This looks good at a high level. However, I have a few notes that would make the review process easier:

• Could you add JUnit tests for this? As far as I can tell, you updated the current tests but missed adding a new one for this specific behavior.
• Could you include screenshots of the frontend changes?
• Could you please detail your testing process? Beyond running the standard build commands (gradlew and npm build), did you perform any manual testing?

Thanks! Looking forward to testing this 😄

[frcooper]

@balazs-szucs screenshots and such are coming. all testing so far has been automated.

[frcooper]

@balazs-szucs pr updated with screen shots showing custom metadata creation and editing. (Need to add the ability to lock fields still. Noticed that was missing.)

[frcooper]

Replacing this with another PR that includes exposing the custom fields in the UI. Will replace the docs PR as well.