NotionSync 0.0.2

Queue processing from a URL

Until now the Notion sync queue could only be processed from the command line:

./cli notionsync:process-queue

That left out hosting providers which do not allow running processes from the CLI, where the plugin queued changes but never got to send them to Notion. This release adds an equivalent HTTP trigger, following the same pattern as Kanboard's own cronjob URL (CronjobController).

Usage

Both forms are equivalent and call the same action:

https://domain.tld/notionsync/cron?token=TOKEN
https://domain.tld/?controller=NotionCronjobController&action=run&plugin=NotionSync&token=TOKEN

The first one requires URL rewriting to be enabled (ENABLE_URL_REWRITE); the second one always works.

TOKEN is Kanboard's global webhook token, the one shown under Settings → Webhooks. There is no new credential to generate or manage.

Both URLs, already filled in with the instance's real token, are shown under Settings → NotionSync, ready to copy.

Any HTTP client can trigger them, whether it is the cron feature of your hosting panel or an external service:

*/5 * * * * wget -q -O - "https://domain.tld/notionsync/cron?token=TOKEN" >/dev/null 2>&1

Optional parameters

Parameter	Default	Description
limit	20	Jobs per run (maximum 500)
delay	350	Pause in milliseconds between calls to Notion

The default limit is 20 rather than the 50 used by the CLI: the console has no time cap, but an HTTP request does, and max_execution_time is typically 30 s on exactly the hosts that force you to use this route. With 20 jobs and a 350 ms pause the accumulated wait is 7 s, leaving room for the calls to Notion. The controller also tries to lift the cap with set_time_limit() where the host allows it.

A request cut short by the time limit breaks nothing: every job is committed to the database as soon as it finishes, so whatever was already synced stays synced and the rest is picked up by the next run.

Response

The response is text/plain with the command output, including the Processed | Synced | Failed line, because a cronjob triggered by URL has no stdout to look at and that text is all the triggering service records in its log.

• 200 — the endpoint ran. A failed job does not return an HTTP error, so that a transient Notion issue does not trip your monitor's alerts: the next run already covers the retry.
• 403 — the token does not match, is missing, or the instance has no webhook_token configured.

Security

• The route is exposed as public only for the run action, never the whole controller.
• The token is compared with hash_equals(), same as in the core.
• If the instance has no webhook_token, the URL returns 403 instead of being left open.

Upgrading from 0.0.1

Replace the plugins/NotionSync folder and you are done. There is no database migration, and the console command is unchanged: anyone already running the CLI cronjob does not need to touch anything.

Other changes

• New Queue processing section on the plugin settings screen, with the crontab example and both URLs.
• New translations for es_ES and es_VE.
• README expanded with the URL cronjob documentation.

Compatibility: Kanboard >= 1.2.0