Skip to content

feat(ical): allow revenue_manager to list, read and sync feeds - #318

Merged
telivity-otaip merged 2 commits into
TelivityAI:mainfrom
modernitconsultants:feat/ical-sync-without-admin
Aug 13, 2026
Merged

feat(ical): allow revenue_manager to list, read and sync feeds#318
telivity-otaip merged 2 commits into
TelivityAI:mainfrom
modernitconsultants:feat/ical-sync-without-admin

Conversation

@modernitconsultants

Copy link
Copy Markdown
Contributor

Every iCal route requires admin. A scheduler that keeps import feeds fresh — an hourly cron pulling OTA calendar exports, surely the common deployment shape — then has to hold admin credentials permanently: the broadest role in the realm for the most routine job in the system.

This widens exactly three routes to revenue_manager: feed list, feed read, feed sync. Create, update, delete and rotate-token stay admin-only — a scheduler needs to trigger and observe, not manage.

(Running this in production: our sync CronJob authenticates as a service account holding revenue_manager, and feed creation remains a deliberate admin act. The split has felt right in practice.)

Every iCal route required admin. A scheduler that keeps import feeds fresh
(hourly cron pulling OTA calendar exports) then has to hold admin
credentials permanently — the broadest role in the realm for the most
routine job in the system.

This widens exactly three routes to revenue_manager: feed list, feed read,
feed sync. Create, update, delete and rotate-token stay admin-only — a
scheduler needs to trigger and observe, not manage.
@telivity-otaip
telivity-otaip merged commit 796c993 into TelivityAI:main Aug 13, 2026
5 checks passed
telivity-otaip pushed a commit that referenced this pull request Aug 16, 2026
)

#318 relaxed listing, reading and syncing feeds to revenue_manager, but
GET /ical/feeds/:id/blocks was missed, so an integration can list the feeds
and sync them while being unable to see what they imported.

Reading the blocks is no more privileged than reading the feed beside it —
they are the busy dates a sync just fetched, not credentials. Without it any
consumer that reconciles imported availability against its own calendar has to
hold admin purely to read.

Co-authored-by: Charles Pizzato <311327716+modernitconsultants@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants