- Updated task status to reflect Phase 2 completion (Server Management)
- Added completed features:
* US-2.5: Create G-Core Server
* US-2.6: Create GeViScope Server
* US-2.7: Update Server
* US-2.8: Delete Server
* Offline-first architecture with Hive
* Server sync and download functionality
* Shared BLoC state across routes
- Documented recent bug fix: "No data" display issue resolved
- Updated last modified date to 2025-12-23
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Updated all spec-kit documents to document the implemented configuration
management features (User Story 12):
Changes:
- spec.md: Added User Story 12 with implementation status and functional
requirements (FR-039 through FR-045)
- plan.md: Added Phase 2 (Configuration Management) as completed, updated
phase status and last updated date
- data-model.md: Added GCoreServer entity with schema, validation rules,
CRUD status, and critical implementation details
- tasks.md: Added Phase 13 for User Story 12 with implementation summary,
updated task counts and dependencies
- tasks-revised-mvp.md: Added configuration management completion notice
Implementation Highlights:
- G-Core Server CRUD (CREATE, READ, DELETE working; UPDATE has known bug)
- Action Mapping CRUD (all operations working)
- SetupClient integration for .set file operations
- Critical cascade deletion bug fix (delete in reverse order)
- Comprehensive test scripts and verification tools
Documentation: SERVER_CRUD_IMPLEMENTATION.md, CRITICAL_BUG_FIX_DELETE.md
🤖 Generated with Claude Code (https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Fixed critical data loss bug where deleting multiple action mappings
caused cascade deletion of unintended mappings.
Root Cause:
- When deleting mappings by ID, IDs shift after each deletion
- Deleting in ascending order (e.g., #62, #63, #64) causes:
- Delete #62 → remaining IDs shift down
- Delete #63 → actually deletes what was #64
- Delete #64 → actually deletes what was #65
- This caused loss of ~54 mappings during initial testing
Solution:
- Always delete in REVERSE order (highest ID first)
- Example: Delete #64, then #63, then #62
- Prevents ID shifting issues
Testing:
- Comprehensive CRUD test executed successfully
- Server CREATE/DELETE: ✓ Working
- Action Mapping CREATE/UPDATE/DELETE: ✓ Working
- No cascade deletion occurred
- All original mappings preserved (~60 mappings intact)
Files Changed:
- comprehensive_crud_test.py: Added reverse-order delete logic
- safe_delete_test.py: Created minimal test to verify fix
- SERVER_CRUD_IMPLEMENTATION.md: Updated with cascade deletion warning
- CRITICAL_BUG_FIX_DELETE.md: Detailed bug analysis and fix documentation
- cleanup_test_mapping.py: Cleanup utility
- verify_config_via_grpc.py: Configuration verification tool
Verified:
- Delete operations now safe for production use
- No data loss when deleting multiple mappings
- Configuration integrity maintained across CRUD operations
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
CRITICAL FIX: Changed boolean fields from int32 to bool type
- Enabled, DeactivateEcho, DeactivateLiveCheck now use proper bool type (type code 1)
- Previous int32 implementation (type code 4) caused servers to be written but not recognized by GeViSet
- Fixed field order to match working reference implementation
Server CRUD Implementation:
- Create, Read, Update, Delete operations via gRPC and REST API
- Auto-increment server ID logic to prevent conflicts
- Proper field ordering: Alias, DeactivateEcho, DeactivateLiveCheck, Enabled, Host, Password, User
Files Added/Modified:
- src/sdk-bridge/GeViScopeBridge/Services/ConfigurationServiceImplementation.cs (bool type fix, CRUD methods)
- src/sdk-bridge/Protos/configuration.proto (protocol definitions)
- src/api/routers/configuration.py (REST endpoints)
- src/api/protos/ (generated protobuf files)
- SERVER_CRUD_IMPLEMENTATION.md (comprehensive documentation)
Verified:
- Servers persist correctly in GeViSoft configuration
- Servers visible in GeViSet with correct boolean values
- Action mappings CRUD functional
- All test scripts working (server_manager.py, cleanup_to_base.py, add_claude_test_data.py)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Implement complete server CRUD operations with GeViServer persistence
- POST /api/v1/configuration/servers - Create new server
- PUT /api/v1/configuration/servers/{server_id} - Update server
- DELETE /api/v1/configuration/servers/{server_id} - Delete server
- GET /api/v1/configuration/servers - List all servers
- GET /api/v1/configuration/servers/{server_id} - Get single server
- Add write_configuration_tree method to SDK bridge client
- Converts tree to JSON and writes via import_configuration
- Enables read-modify-write pattern for configuration changes
- Fix action mappings endpoint schema mismatch
- Transform response to match ActionMappingListResponse schema
- Add total_mappings, mappings_with_parameters fields
- Include id and offset in mapping responses
- Streamline configuration router
- Remove heavy endpoints (export, import, modify)
- Optimize tree navigation with depth limiting
- Add path-based configuration access
- Update OpenAPI specification with all endpoints
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Add comprehensive spec for .set file format parsing
- Document binary structure, data types, and sections
- Add research notes from binary analysis
- Fix SetupClient password encryption (GeViAPI_EncodeString)
- Add DiagnoseSetupClient tool for testing
- Successfully tested: read/write 281KB config, byte-perfect round-trip
- Found 64 action mappings in live server configuration
Next: Full binary parser implementation for complete structure
🤖 Generated with Claude Code
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Implemented complete cross-switching system with database persistence and audit logging:
**Tests:**
- Contract tests for POST /api/v1/crossswitch (execute cross-switch)
- Contract tests for POST /api/v1/crossswitch/clear (clear monitor)
- Contract tests for GET /api/v1/crossswitch/routing (routing state)
- Contract tests for GET /api/v1/crossswitch/history (routing history)
- Integration tests for complete cross-switch workflow
- RBAC tests (operator required for execution, viewer for reading)
**Database:**
- CrossSwitchRoute model with full routing history tracking
- Fields: camera_id, monitor_id, mode, executed_at, executed_by, is_active
- Cleared route tracking: cleared_at, cleared_by
- SDK response tracking: sdk_success, sdk_error
- JSONB details field for camera/monitor names
- Comprehensive indexes for performance
**Migration:**
- 20251209_crossswitch_routes: Creates crossswitch_routes table
- Foreign keys to users table for executed_by and cleared_by
- Indexes: active routes, camera history, monitor history, user routes
**Schemas:**
- CrossSwitchRequest: camera_id, monitor_id, mode validation
- ClearMonitorRequest: monitor_id validation
- RouteInfo: Complete route information with user details
- CrossSwitchResponse, ClearMonitorResponse, RoutingStateResponse
- RouteHistoryResponse: Pagination support
**Services:**
- CrossSwitchService: Complete cross-switching logic
- execute_crossswitch(): Route camera to monitor via SDK Bridge
- clear_monitor(): Remove camera from monitor
- get_routing_state(): Get active routes
- get_routing_history(): Get historical routes with pagination
- Automatic route clearing when new camera assigned to monitor
- Cache invalidation after routing changes
- Integrated audit logging for all operations
**Router Endpoints:**
- POST /api/v1/crossswitch - Execute cross-switch (Operator+)
- POST /api/v1/crossswitch/clear - Clear monitor (Operator+)
- GET /api/v1/crossswitch/routing - Get routing state (Viewer+)
- GET /api/v1/crossswitch/history - Get routing history (Viewer+)
**RBAC:**
- Operator role or higher required for execution (crossswitch, clear)
- Viewer role can read routing state and history
- Administrator has all permissions
**Audit Logging:**
- All cross-switch operations logged to audit_logs table
- Tracks: user, IP address, camera/monitor IDs, success/failure
- SDK errors captured in both audit log and route record
**Integration:**
- Registered crossswitch router in main.py
- SDK Bridge integration for hardware control
- Redis cache invalidation on routing changes
- Database persistence of all routing history
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Implemented complete monitor discovery system with Redis caching:
**Tests:**
- Contract tests for GET /api/v1/monitors (list monitors)
- Contract tests for GET /api/v1/monitors/{id} (monitor detail)
- Tests for available/active monitor filtering
- Integration tests for monitor data consistency
- Tests for caching behavior and all authentication roles
**Schemas:**
- MonitorInfo: Monitor data model (id, name, description, status, current_camera_id)
- MonitorListResponse: List endpoint response
- MonitorDetailResponse: Detail endpoint response with extended fields
- MonitorStatusEnum: Status constants (active, idle, offline, unknown, error, maintenance)
**Services:**
- MonitorService: list_monitors(), get_monitor(), invalidate_cache()
- Additional methods: search_monitors(), get_available_monitors(), get_active_monitors()
- get_monitor_routing(): Get current routing state (monitor -> camera mapping)
- Integrated Redis caching with 60s TTL
- Automatic cache invalidation and refresh
**Router Endpoints:**
- GET /api/v1/monitors - List all monitors (cached, 60s TTL)
- GET /api/v1/monitors/{id} - Get monitor details
- POST /api/v1/monitors/refresh - Force refresh (bypass cache)
- GET /api/v1/monitors/search/{query} - Search monitors by name/description
- GET /api/v1/monitors/filter/available - Get available (idle) monitors
- GET /api/v1/monitors/filter/active - Get active monitors (displaying camera)
- GET /api/v1/monitors/routing - Get current routing state
**Authorization:**
- All monitor endpoints require at least Viewer role
- All authenticated users can read monitor data
**Integration:**
- Registered monitor router in main.py
- Monitor service communicates with SDK Bridge via gRPC
- Redis caching for performance optimization
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Implemented complete camera discovery system with Redis caching:
**Tests:**
- Contract tests for GET /api/v1/cameras (list cameras)
- Contract tests for GET /api/v1/cameras/{id} (camera detail)
- Integration tests for camera data consistency
- Tests for caching behavior and all authentication roles
**Schemas:**
- CameraInfo: Camera data model (id, name, description, has_ptz, has_video_sensor, status)
- CameraListResponse: List endpoint response
- CameraDetailResponse: Detail endpoint response with extended fields
- CameraStatusEnum: Status constants (online, offline, unknown, error, maintenance)
**Services:**
- CameraService: list_cameras(), get_camera(), invalidate_cache()
- Additional methods: search_cameras(), get_online_cameras(), get_ptz_cameras()
- Integrated Redis caching with 60s TTL
- Automatic cache invalidation and refresh
**Router Endpoints:**
- GET /api/v1/cameras - List all cameras (cached, 60s TTL)
- GET /api/v1/cameras/{id} - Get camera details
- POST /api/v1/cameras/refresh - Force refresh (bypass cache)
- GET /api/v1/cameras/search/{query} - Search cameras by name/description
- GET /api/v1/cameras/filter/online - Get online cameras only
- GET /api/v1/cameras/filter/ptz - Get PTZ cameras only
**Authorization:**
- All camera endpoints require at least Viewer role
- All authenticated users can read camera data
**Integration:**
- Registered camera router in main.py
- Camera service communicates with SDK Bridge via gRPC
- Redis caching for performance optimization
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
