alexei.dolgolyov
1d445f3980
Rework entity schema: rename Tracker→NotificationTracker, add CommandConfig/ CommandTracker/CommandTrackerListener entities for decoupled command handling. Commands now resolve through CommandTracker→CommandConfig instead of TelegramBot.commands_config. Smart ref-counted bot polling based on active listeners. Add chat_action to telegram targets. Full frontend CRUD pages for command configs and command trackers. Idempotent SQLite migrations. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
54 lines
2.6 KiB
Markdown
54 lines
2.6 KiB
Markdown
# Feature Context: Entity Relationship Refactor
|
|
|
|
## Current State
|
|
Starting — no changes made yet. Branch created from master with all telegram-commands work merged.
|
|
|
|
## Key Design Decisions
|
|
- Provider capabilities (notifications, commands) inferred from provider type config, not explicit DB flags
|
|
- Tracker renamed to NotificationTracker; TrackerTarget renamed to NotificationTrackerTarget
|
|
- New entities: CommandConfig, CommandTracker, CommandTrackerListener
|
|
- CommandConfig is provider_type-scoped, shareable across multiple CommandTrackers
|
|
- CommandTrackerListener is a junction table (command_tracker_id, listener_type, listener_id) for extensibility
|
|
- TelegramBot is dual-purpose: notification target backend + commands listener
|
|
- TelegramBot polling/webhook lifecycle tied to CommandTrackerListener ref-counting
|
|
- Telegram targets gain chat_action field
|
|
- commands_config moves from TelegramBot to CommandConfig entity
|
|
|
|
## Entity Schema (Target State)
|
|
```
|
|
ServiceProvider (type: "immich" → infers has_notifications=true, has_commands=true)
|
|
│
|
|
├─ NotificationTracker (renamed from Tracker)
|
|
│ └─ NotificationTrackerTarget (renamed from TrackerTarget)
|
|
│ ├─ NotificationTarget (+ chat_action for telegram type)
|
|
│ ├─ TrackingConfig (unchanged)
|
|
│ └─ TemplateConfig (unchanged)
|
|
│
|
|
└─ CommandTracker (new)
|
|
├─ CommandConfig (new, shared, provider_type-scoped)
|
|
└─ CommandTrackerListener (junction → listener_type + listener_id)
|
|
└─ TelegramBot as "telegram_bot" listener type
|
|
|
|
TelegramBot
|
|
├─ Used by NotificationTarget (sending messages)
|
|
└─ Used by CommandTrackerListener (receiving commands)
|
|
└─ Smart ref-counting: start polling/webhook when first listener added, stop when last removed
|
|
```
|
|
|
|
## Temporary Workarounds
|
|
None yet.
|
|
|
|
## Cross-Phase Dependencies
|
|
- Phase 2 depends on Phase 1 (renamed models)
|
|
- Phase 3 depends on Phase 1 (new models for CommandConfig, CommandTracker, CommandTrackerListener)
|
|
- Phase 4 depends on Phase 3 (command entities exist in DB/API)
|
|
- Phase 5 depends on Phase 2 (renamed API endpoints)
|
|
- Phase 6 depends on Phase 3 (command entity APIs)
|
|
- Phase 7 depends on all prior phases
|
|
|
|
## Implementation Notes
|
|
- SQLite + async SQLAlchemy via sqlmodel — table renames done via idempotent ALTER TABLE / CREATE TABLE
|
|
- No formal test suite — verification via server startup + health check + frontend build
|
|
- Migration must handle existing data: rename tables, migrate TelegramBot.commands_config → CommandConfig rows
|
|
- Incremental strategy: each phase leaves the codebase fully working
|