busya/ss-tools
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
Files
master
ss-tools/specs/002-app-settings/tasks.md

5.8 KiB
Raw Permalink Blame History

description
description
Task list for implementing the web application settings mechanism

Tasks: Web Application Settings Mechanism

Input: Design documents from specs/002-app-settings/ Prerequisites: plan.md (required), spec.md (required for user stories)

Organization: Tasks are grouped by user story to enable independent implementation and testing of each story.

Format: [ID] [P?] [Story] Description

  • [P]: Can run in parallel (different files, no dependencies)
  • [Story]: Which user story this task belongs to (e.g., US1, US2, US3)
  • Include exact file paths in descriptions

Phase 1: Setup (Shared Infrastructure)

Purpose: Project initialization and basic structure

  • T001 Create project structure for settings management in backend/src/core/ and backend/src/api/routes/
  • T002 [P] Initialize frontend/src/pages/Settings.svelte placeholder

Phase 2: Foundational (Blocking Prerequisites)

Purpose: Core infrastructure that MUST be complete before ANY user story can be implemented

⚠️ CRITICAL: No user story work can begin until this phase is complete

  • T003 Implement configuration models in backend/src/core/config_models.py
  • T004 Implement ConfigManager for JSON persistence in backend/src/core/config_manager.py
  • T005 [P] Update backend/src/dependencies.py to provide ConfigManager singleton
  • T006 [P] Setup API routing for settings in backend/src/api/routes/settings.py and register in backend/src/app.py

Checkpoint: Foundation ready - user story implementation can now begin in parallel

Phase 3: User Story 1 - Manage Superset Environments (Priority: P1) 🎯 MVP

Goal: Add, edit, and remove Superset environment configurations (URL, credentials, name) so that the application can interact with multiple Superset instances.

Independent Test: Add a new environment, verify it appears in the list, and then delete it.

Implementation for User Story 1

  • T007 [P] [US1] Implement environment CRUD logic in backend/src/core/config_manager.py
  • T008 [US1] Implement environment API endpoints in backend/src/api/routes/settings.py
  • T009 [P] [US1] Add environment API methods to frontend/src/lib/api.js
  • T010 [US1] Implement environment list and form UI in frontend/src/pages/Settings.svelte
  • T011 [US1] Implement connection test logic in backend/src/api/routes/settings.py

Checkpoint: At this point, User Story 1 should be fully functional and testable independently

Phase 4: User Story 2 - Configure Backup Storage (Priority: P1)

Goal: Configure the file path or storage location for backups so that I can control where system backups are stored.

Independent Test: Set a backup path and verify that the system validates the path's existence or accessibility.

Implementation for User Story 2

  • T012 [P] [US2] Implement global settings update logic in backend/src/core/config_manager.py
  • T013 [US2] Implement global settings API endpoints in backend/src/api/routes/settings.py
  • T014 [P] [US2] Add global settings API methods to frontend/src/lib/api.js
  • T015 [US2] Implement backup storage configuration UI in frontend/src/pages/Settings.svelte
  • T016 [US2] Add path validation and write permission checks in backend/src/api/routes/settings.py

Checkpoint: At this point, User Stories 1 AND 2 should both work independently

Phase 5: Polish & Cross-Cutting Concerns

Purpose: Improvements that affect multiple user stories

  • T017 Refactor superset_tool/utils/init_clients.py to use ConfigManager for environment details
  • T018 Update existing plugins (Backup, Migration) to fetch settings from ConfigManager
  • T019 [P] Add password masking in backend/src/api/routes/settings.py and UI
  • T020 [P] Add "Settings" link to navigation in frontend/src/App.svelte
  • T021 [P] Documentation updates for settings mechanism in docs/
  • T022 [US1] Enforce INV-002 (at least one environment) in backend/src/core/config_manager.py and UI

Dependencies & Execution Order

Phase Dependencies

  • Setup (Phase 1): No dependencies - can start immediately
  • Foundational (Phase 2): Depends on Setup completion - BLOCKS all user stories
  • User Stories (Phase 3+): All depend on Foundational phase completion
    • User stories can then proceed in parallel (if staffed)
    • Or sequentially in priority order (P1 → P2 → P3)
  • Polish (Final Phase): Depends on all desired user stories being complete

User Story Dependencies

  • User Story 1 (P1): Can start after Foundational (Phase 2) - No dependencies on other stories
  • User Story 2 (P1): Can start after Foundational (Phase 2) - Independent of US1

Parallel Opportunities

  • All Setup tasks marked [P] can run in parallel
  • All Foundational tasks marked [P] can run in parallel (within Phase 2)
  • Once Foundational phase completes, all user stories can start in parallel
  • Models and API methods within a story marked [P] can run in parallel

Parallel Example: User Story 1

# Launch backend and frontend tasks for User Story 1 together:
Task: "Implement environment CRUD logic in backend/src/core/config_manager.py"
Task: "Add environment API methods to frontend/src/lib/api.js"

Implementation Strategy

MVP First (User Story 1 Only)

  1. Complete Phase 1: Setup
  2. Complete Phase 2: Foundational (CRITICAL - blocks all stories)
  3. Complete Phase 3: User Story 1
  4. STOP and VALIDATE: Test User Story 1 independently
  5. Deploy/demo if ready

Incremental Delivery

  1. Complete Setup + Foundational → Foundation ready
  2. Add User Story 1 → Test independently → Deploy/Demo (MVP!)
  3. Add User Story 2 → Test independently → Deploy/Demo
  4. Each story adds value without breaking previous stories