7a420ef97514504f92f758ed4ae92e090270a9d8
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
da33e2c126 |
docs: update Carousel Dashboard plan and resolve verification checklist discrepancies
Updated Carousel Dashboard documentation to reflect finalized architecture decisions and resolve discrepancies between plan and verification checklist. ## CAROUSEL_DASHBOARD_PLAN.md Changes ### Added Phase 4.5: Collections Preview Endpoint - Documented why preview endpoint is required (web UI + mobile apps) - Explained why client-side preview is a bad idea (download entire library, code duplication, maintenance nightmare) - Added full PreviewCollection handler implementation - Added Bruno test specification ### Enhanced Phase 7: Router Registration & Config Setup - Renamed from "Router Registration" to "Router Registration & Config Setup" - Added Step 1: Update router.go Config struct with line numbers - Added Step 2: Update main.go initialization with line numbers - Added Step 3: Update test_helpers.go with line numbers - Added explanation: Why both DashboardService AND DashboardHandler? ### Updated Phase 10.5.4: Collections Preview Endpoint - Referenced Phase 4.5 (endpoint already implemented earlier) - Clarified needed for web UI AND mobile apps - Noted no additional work needed ### Added Phase 10.6: Implementation Checklist - 30+ checklist items with file paths and verification commands - Organized by layer (Database, Service, Handler, Router, Templates, TypeScript, Tests, Docs) - Added Build & Verification section - Added Timeline Estimate (20-26 hours) - Added Post-Implementation Tasks ## CAROUSEL_DASHBOARD_VERIFICATION_CHECKLIST.md Changes ### Added Clarification Section (at top) - Explained all discrepancies between plan and checklist - Preview endpoint IS in plan (Phase 4.5) - Custom Section Builder IS in plan (Phase 10.5.2 and 10.5.3) - Service method names - Plan is correct - Config struct - Documented with exact line numbers - DashboardService vs DashboardHandler - Explained why both needed ### Updated Service Method Names (Section 3.2) Changed to match plan's actual implementation: - GetDashboardSections (not GetSectionItems) - filterHiddenCollections (not filterHiddenSections) - reorderCollections (not reorderSections) - sortByPriority (new method) - getUserCollectionItems (not getCollectionSections) - getCollectionItemsByQueryType (renamed) ### Enhanced Config Verification (Section 6.4) Added exact line numbers for all 3 files: - internal/router/router.go lines 58-59 - cmd/server/main.go lines 123-124, 172-173 - cmd/server/tests/test_helpers.go lines 419-420, 458-459 ### Updated Preview Endpoint Section (Section 6.3) Added clear explanation of why endpoint is REQUIRED and why NOT client-side. ### Clarified Custom Section Builder (Sections 8.5, 9.4) Both now explicitly state "IS in the plan (Phase 10.5)" ## docs/developer/api/dashboard.md Changes Updated API documentation to match new unified collections architecture: - Terminology: "smart sections" → "system collections" - Field: `type: string` → `is_system: boolean` - Field: `id` → `media_item_id` for books - Request: `hidden_sections` → `hidden_collections` - Request: `section_order` → `collection_order` - Removed: "in-progress" and "unread" smart sections - Added: Update Dashboard Preferences endpoint - Added: Restore System Collection endpoint - Updated: Example responses with new field names and types - Updated: Error responses table ## Impact These changes clarify: 1. Preview endpoint is required for both web UI custom section builder and mobile apps 2. Custom Section Builder IS a major feature in the plan (not missing) 3. Service method names use "collections" terminology consistently 4. Config struct updates are clearly documented with exact line numbers (3 files only) 5. Why both DashboardService AND DashboardHandler are needed in Config All documentation now accurately reflects the finalized Carousel Dashboard architecture. |
||
|
|
d981fdf517 |
docs(dashboard): update Carousel plan with API endpoint and user preferences
Major architectural improvements: 1. Add generic /api/dashboard/sections JSON endpoint - Created internal/handlers/dashboard.go (new file) - Created internal/router/dashboard.go (new file) - Single source of truth for web UI, mobile apps, plugins - Follows existing handler/router pattern 2. Update DashboardService to apply user preferences - GetSectionItems() now accepts sectionOrder and hiddenSections - filterHiddenSections() removes user's hidden sections - reorderSections() applies user's custom order - Ensures consistent behavior across all clients 3. Separate concerns properly - API handlers in internal/handlers/dashboard.go - SSR routes remain in internal/router/frontend.go - Both use same DashboardService (single source of truth) 4. Reorganize implementation phases - Phase 1-3: Database, service, queries - Phase 4-6: Handler, router, frontend routes - Phase 7-9: Templates and settings - Phase 10-11: TypeScript modules - Phase 12-13: Documentation and testing 5. Add documentation - docs/developer/api/dashboard.md (API reference) - docs/user/dashboard.md (user guide) 6. Bruno tests already exist - bruno/dashboard/ has 5 comprehensive test files - Three-context testing (no user, user, admin) - No additional tests needed Benefits: - Uniform dashboard across web, mobile, plugins - Single source of truth (no duplicate logic) - User preferences respected by all clients - Follows established project patterns - Comprehensive test coverage Timeline: Updated to reflect 13 phases (19-25 days total with TypeScript) |