recurrence

The entry's series, or 404 when it has none. A rule a client can set and never read back is one it cannot show, so the series is read here as well as written.

Puts a series on the entry, or changes the one it has - the same call for both, because a rule is one thing an entry either carries or does not. Only a TASK may carry one: a series applies to the whole subtree, so a work package or an activity is refused with capability_not_supported. The rule is RFC 5545 and needs its IANA zone: daylight saving is resolved through the zone and never through an offset, which is what keeps 09:00 at 09:00 across a transition. A rule the library cannot parse, a rule without a zone, and a rule whose expansion inside its own horizon exceeds the bound in /meta/capabilities are each refused with a field error rather than stored and discovered by the scheduler. Nothing is materialised here: this call stores the rule, and the occurrences are created as the series comes due.

Takes the series off the entry. Occurrences that were already materialised stay exactly where they are: they are ordinary entries the moment they exist, and deleting somebody's next three weeks because they stopped a series would be a deletion nobody asked for. Idempotent - an entry with no series succeeds and announces nothing.

Skips the next occurrence the series has not produced yet: the one after the last one materialised, or - for a series that has produced none - the first one after the entry's own due date. Nothing that already exists is touched, because a materialised occurrence is an ordinary entry and skipping it would be deleting somebody's work. Idempotent under its Idempotency-Key, and repeatable without one: calling it twice skips two occurrences, which is what "skip the next one" means said twice. The answer is the rule with its bookkeeping moved on.