Plugin idea: more calendar providers #1254

New issue

Open

opened 2026-11-13 10:51:53 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-11-13 10:51:53 +00:00

Owner

Idea

Interviews, reminders and deadlines reach a calendar through the DAV plugin today (CalDAV). Other ways people keep a calendar: Google Calendar, Microsoft 365 / Outlook, Apple through CalDAV, Proton, a plain ICS subscription (the calendar feed of #1098). Each is a sync plugin writing and reading events for the person's own calendars only.

What to settle

Which providers allow it without an app review that the project cannot pass (Google and Microsoft OAuth have conditions); an ICS feed and CalDAV need none and come first.
What is synchronised (interview appointments, reminders, deadlines), in which direction, and how a change on either side is merged without duplicating (SyncLink, #1165).
Credentials are kept as other plugins keep them (plugins/secrets.py), never in the plugin.

Wanted

A comparison of the providers (what each needs, what it risks), and a reference plugin for the one that needs least, on the existing sync kind.

Rules that apply to every plugin

Off until the person enables it; a plugin that calls a service names the host and the data it sends in its manifest and on the consent screen (plugins/consent.py); nothing is fetched on page load.
Core keeps no import of it: the application runs with it absent, and data it created stays readable as plain data when it is removed.
The plugin surface (plugins/api.py, the published postulo.plugins.testing check) gets a contract test for any new kind; the plugin ships its own translation catalogues (the plugin locale rule); strings go through Weblate only.
Its own repository if it is not bundled (see the plugin repositories and #1170's shared CI).

Filed as an idea after a discussion on plugin kinds, with #1252 (reference data and lookups as plugins). Not started; the maintainer decides if and when.

## Idea Interviews, reminders and deadlines reach a calendar through the DAV plugin today (CalDAV). Other ways people keep a calendar: **Google Calendar**, **Microsoft 365 / Outlook**, **Apple through CalDAV**, **Proton**, a plain **ICS subscription** (the calendar feed of #1098). Each is a `sync` plugin writing and reading events for the person's own calendars only. ## What to settle - Which providers allow it without an app review that the project cannot pass (Google and Microsoft OAuth have conditions); an ICS feed and CalDAV need none and come first. - What is synchronised (interview appointments, reminders, deadlines), in which direction, and how a change on either side is merged without duplicating (`SyncLink`, #1165). - Credentials are kept as other plugins keep them (`plugins/secrets.py`), never in the plugin. ## Wanted A comparison of the providers (what each needs, what it risks), and a reference plugin for the one that needs least, on the existing `sync` kind. ## Rules that apply to every plugin - Off until the person enables it; a plugin that calls a service names the host and the data it sends in its manifest and on the consent screen (`plugins/consent.py`); nothing is fetched on page load. - Core keeps no import of it: the application runs with it absent, and data it created stays readable as plain data when it is removed. - The plugin surface (`plugins/api.py`, the published `postulo.plugins.testing` check) gets a contract test for any new kind; the plugin ships its own translation catalogues (the plugin locale rule); strings go through Weblate only. - Its own repository if it is not bundled (see the plugin repositories and #1170's shared CI). Filed as an idea after a discussion on plugin kinds, with #1252 (reference data and lookups as plugins). **Not started; the maintainer decides if and when.**

tiagoagueda added the

enhancement

label

2026-11-13 10:51:53 +00:00