Let workflows move cards by start date instead of due date
Build package / xml-lint (push) Successful in 3m32s
Build package / unit-tests (push) Successful in 4m49s
Build package / php-lint (8.5) (push) Successful in 4m52s
Build package / php-lint (8.4) (push) Successful in 4m56s
Build package / package (push) Successful in 2m28s

Each workflow now has a trigger date (due or start): the runner compares
either the card's due date or its start date against now, read straight
from Deck's Card entity. Mails and Nextcloud notifications say whether
the card was overdue or reached its start date. Cards without the chosen
date stay put.

Deck only has a start date since 1.18 and Entity getters are magic, so
DeckIntegrationService::supportsStartdate() checks the property; without
it the form rejects start-date workflows and the runner skips them
without disabling them.

WorkflowRunner::isOverdue() becomes hasPassed(), as it now covers both
dates. Existing workflows keep the due date (migration Version1005).
Bumps to 35.4.0 so the migration runs.
This commit is contained in:
Patrick Niebeling committed 2026-10-01 13:19:32 +02:00
1 parent 5bd3181f10
commit 8268f1068d
18 files changed
+286 -71

No files matched your search

+9
View File
@@ -163,6 +163,15 @@ class DeckIntegrationService {
}
}
/**
* Whether Deck's cards carry a start date (`deck_cards.startdate`, added
* in Deck 1.18). Checked on the property, not with method_exists():
* Entity getters are magic, so getStartdate() would only fail when called.
*/
public function supportsStartdate(): bool {
return class_exists(Card::class) && property_exists(Card::class, 'startdate');
}
/**
* The boards `$userId` owns — the only boards workflows may live on, and
* the boards whose workflows that user sees and manages.