Yuliia Pominchuk 7237095654 feat(core): Store catalog consent and personal schedules ... Two tables behind running a catalog workflow on your own schedule. They are split because the keys differ: consent is one grant per (workflow, person), while one person may want several schedules for the same workflow. The subscription hangs off the grant by composite foreign key, so withdrawing consent takes the schedules with it. The scheduler side needed widening to hold them. A job was identified by `(workflowId, nodeId)`, which is what provisioning diffs and deprovisioning deletes by, and a per-person schedule has no node — several people hold their own schedules for the same workflow. `scheduled_job` gains a nullable, opaque `ownerId` that the scheduler only ever pairs with `taskType` and never interprets, so a feature can own jobs without the scheduler learning about the feature. An owner-scoped job deliberately records no `workflowId`: that column is a foreign key onto `workflow_published_version`, so it means "belongs to a published trigger", which these do not. The type makes passing one impossible. It also means nothing in the database removes these jobs when their owner goes, so callers must deprovision explicitly. The column is added with a raw `ALTER TABLE`: on SQLite the schema builder rebuilds the table, and `scheduled_task` cascades from it, so the rebuild would delete every queued occurrence on the instance. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>		2026-08-05 12:14:48 +02:00
..
postgres-schema	feat(core): Store catalog consent and personal schedules	2026-08-05 12:14:48 +02:00
sqlite-schema	feat(core): Store catalog consent and personal schedules	2026-08-05 12:14:48 +02:00