alexei.dolgolyov/notify-bridge
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 31 Wiki Activity

feat: entity relationship refactor — notification trackers, command system, chat actions

Browse Source 
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>
This commit is contained in:
Admin
2026-03-21 01:27:20 +03:00
parent 0dcca2fbe6
commit 1d445f3980
34 changed files with 2777 additions and 582 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CLAUDE.md
+14 -8
View File
@@ -42,19 +42,25 @@ Default test account: username `admin`, password `admin1`.
- **Environment vars**: `NOTIFY_BRIDGE_DATA_DIR`, `NOTIFY_BRIDGE_SECRET_KEY`, `NOTIFY_BRIDGE_DATABASE_URL`
- Core package includes `jinja2` dependency (template rendering lives in core, not server).
## Entity Relationships (Phase 6)
## Entity Relationships
```
ServiceProvider → type: "immich", config: JSON (url, api_key, external_domain)
Tracker → provider_id, tracking_config_id, target_ids: JSON list, collection_ids: JSON list
TrackingConfig → provider_type (must match provider), event flags, scheduling
TemplateConfig → provider_type (must match provider), Jinja2 slots per event type
NotificationTarget → template_config_id, type: "telegram"/"webhook", config: JSON
ServiceProvider → type: "immich" (inferred capabilities: notifications, commands)
NotificationTracker → provider_id, collection_ids, scan_interval, batch_duration, enabled
NotificationTrackerTarget → notification_tracker_id, target_id, tracking_config_id, template_config_id, quiet_hours, enabled
TrackingConfig → provider_type, event flags, scheduling rules
TemplateConfig → provider_type, Jinja2 template slots per event type
NotificationTarget → type: "telegram"/"webhook", config JSON, chat_action (telegram only)
CommandConfig → provider_type, enabled_commands, locale, response_mode, default_count, rate_limits
CommandTracker → provider_id, command_config_id, enabled
CommandTrackerListener → command_tracker_id, listener_type ("telegram_bot"), listener_id
TelegramBot → token, update_mode, bot_username (used as notification target backend + commands listener)
```
- TrackingConfig owned by Tracker (what to watch), TemplateConfig owned by Target (how to format)
- NotificationTrackerTarget links a tracker to a target with per-link tracking/template config and quiet hours
- CommandTrackerListener links a command tracker to a listener (e.g. TelegramBot) for slash-command handling
- `user_id=0` on TemplateConfig = system default (EN/RU seeded on first startup)
- DB: SQLite + async SQLAlchemy via sqlmodel, auto-created on startup
- DB: SQLite + async SQLAlchemy via sqlmodel, auto-created on startup with migrations
- API: All CRUD routes under `/api/`, auth via JWT Bearer, `NOTIFY_BRIDGE_` env prefix
## Template System Sync Rules