[codex] Add SPA system settings management#25
Conversation
|
Caution Review failedPull request was closed or merged during review 📝 WalkthroughWalkthroughThe PR introduces a comprehensive System Settings feature enabling staff/superusers to manage runtime configuration through both backend API endpoints and a frontend UI. Changes include validation refactoring in the check module, new DRF API endpoints with serializers and permission checks, a data-driven frontend schema, a new Settings System view component, E2E tests, and updates to navigation and routing logic. Changes
Sequence DiagramsequenceDiagram
actor User as Staff/Admin User
participant Client as Frontend (Vue)
participant API as Django REST API
participant DB as Database (SysConfig)
participant Validators as Validation Module
User->>Client: Navigate to /settings/system
Client->>API: GET /v1/system-settings/
API->>DB: load_system_settings()
DB-->>API: SysConfig values
API->>API: build_system_settings_options()
API-->>Client: SystemSettingsPayload (settings + options)
Client->>Client: Render form with schema-driven fields
User->>Client: Edit field values
Client->>Client: Update reactive settings state
User->>Client: Click "Save Settings"
Client->>API: PUT /v1/system-settings/ {settings}
API->>API: SystemSettingsSerializer.validate()
API->>DB: save_system_settings(validated)
DB-->>API: SysConfig updated
API-->>Client: 200 OK (updated payload)
Client->>Client: Show "Settings saved" feedback
User->>Client: Click "Test Storage Connection"
Client->>API: POST /v1/system-settings/tests/storage/ {payload}
API->>Validators: validate_file_storage_payload(payload)
Validators-->>API: dict with validation result
API-->>Client: 200 OK {detail: "test succeeded"}
Client->>Client: Show test result feedback
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
| # Log detailed error information | ||
| logging.error("Storage connectivity test failed") | ||
| # logging.error(f"Storage connectivity test failed: {message}") | ||
| logging.debug("Storage connectivity test error: %s", message) |
| result = validate_go_inception_payload(serializer.validated_data) | ||
| if result["status"] != 0: | ||
| return Response( | ||
| {"errors": result["msg"]}, status=status.HTTP_400_BAD_REQUEST |
| ) | ||
| if result["status"] != 0: | ||
| return Response( | ||
| {"errors": result["msg"]}, status=status.HTTP_400_BAD_REQUEST |
What changed
This PR adds a new staff/admin-only SPA system settings surface for Datamingle.
It includes:
/settings/systemSPA page with grouped runtime settings sectionsWhy it changed
The legacy bootstrap frontend already had a system settings surface, but the SPA did not. This fills that gap so staff/admins can manage Datamingle runtime settings without dropping back to the old UI.
User and developer impact
Root cause
The missing SPA equivalent of the old system settings page left runtime configuration management outside the main app flow. During e2e validation, Playwright also exposed a load-state race where initial settings fetches could overwrite typed values before save. This PR fixes that by keeping controls disabled while the page is loading or saving.
Validation
black --check .npm run lintnpm run builddocker exec datamingle-app python manage.py test sql_api.tests.TestSystemSettings common.tests.CheckTestE2E_START_FRONTEND=1 npm run e2e:test -- tests/e2e/system-settings.spec.tsSummary by CodeRabbit