6 Commits

Include renames

Author	SHA1	Message	Date
gnilebein	28b4edc811	revert 0e66319a06 ... revert Let each workflow watch the due date or the start date Deck 1.18 added a start date to cards (Card::$startdate), so a workflow no longer has to mean "overdue". Each rule now carries a date_field ('due' | 'start'), chosen in the settings form next to board and stacks. Existing rules keep the due date: the new column's default supplies it for every stored row, so there is no backfill step, and Workflow::getDateFieldOrDue() covers entities that were never near the database as well as hand-edited values. The controller is the one place that rejects an unknown value instead of normalising it - a client asking for a rule it would not get should hear about it. The probe for the field is property_exists(), not method_exists(): Deck's entities declare no getter as real code - getStartdate(), getDuedate(), even getId() all go through Entity::__call(), which method_exists() ignores by definition. A method_exists() guard would have been false on every Deck version and would have turned every start-date rule into a silent no-op. assertDeckAvailable() now also refuses Deck older than 1.18.0. That floor cannot live in appinfo/info.xml - neither the server's nor the app store's schema has an app-to-app dependency element - but <nextcloud min-version="34"> already implies it, since 1.18.x is the only Deck release line published for Nextcloud 34. isOverdue() becomes hasPassed(): one function for both dates, since the comparison and the argument against Deck's day-truncating getDaysUntilDue() are identical for either. Also carries a pending NcSelect icon-alignment fix that was already in the working tree. Bump to 34.1.0.	2026-08-26 07:10:55 +02:00
Patrick Niebeling	0e66319a06	Let each workflow watch the due date or the start date ... Deck 1.18 added a start date to cards (Card::$startdate), so a workflow no longer has to mean "overdue". Each rule now carries a date_field ('due' | 'start'), chosen in the settings form next to board and stacks. Existing rules keep the due date: the new column's default supplies it for every stored row, so there is no backfill step, and Workflow::getDateFieldOrDue() covers entities that were never near the database as well as hand-edited values. The controller is the one place that rejects an unknown value instead of normalising it - a client asking for a rule it would not get should hear about it. The probe for the field is property_exists(), not method_exists(): Deck's entities declare no getter as real code - getStartdate(), getDuedate(), even getId() all go through Entity::__call(), which method_exists() ignores by definition. A method_exists() guard would have been false on every Deck version and would have turned every start-date rule into a silent no-op. assertDeckAvailable() now also refuses Deck older than 1.18.0. That floor cannot live in appinfo/info.xml - neither the server's nor the app store's schema has an app-to-app dependency element - but <nextcloud min-version="34"> already implies it, since 1.18.x is the only Deck release line published for Nextcloud 34. isOverdue() becomes hasPassed(): one function for both dates, since the comparison and the argument against Deck's day-truncating getDaysUntilDue() are identical for either. Also carries a pending NcSelect icon-alignment fix that was already in the working tree. Bump to 34.1.0.	2026-08-25 15:28:30 +02:00
Patrick Niebeling	131ef2e938	Surface dead filters, and name board and stacks in the moved-card mail ... A filter whose entries have all been deleted from the board was the one failure mode of this app that was completely invisible: the workflow kept running, kept updating last_run and matched nothing, forever. It happens with deleted labels and just as easily when a filtered user loses board access, because Deck's BoardService::deleteAcl() calls assignedUsersMapper->deleteByParticipantOnBoard() and wipes that user's card assignments. Two low-stakes signals, no new column and no migration: - WorkflowRunner::warnAboutDeadFilters() logs a warning on every run. - workflowIssues in PersonalSettings.vue marks the row red. Deliberately no mail and no `enabled = false`. One deleted label out of three is harmless, and even a fully dead filter can be one board edit away from being live again. Both obey the rule the disable path already follows: only positive knowledge. DeckIntegrationService::findFilterOptions() therefore throws instead of degrading to [], unlike listLabels()/listParticipants(), where an empty list only means an empty dropdown. That also fixes an existing false positive of the same family: loadStacksFor() stored [] when the request failed, so a single failed fetch reported "Quell-Stapel und Ziel-Stapel nicht mehr vorhanden" for an untouched board. Failed requests now store null and are read as "unknown". The comparison itself lives in WorkflowRunner::findDeadFilters(), static and side-effect free like cardMatchesFilters(), with unit tests -- notably that an empty filter is never dead, which would otherwise flag every unfiltered workflow. Separately, the moved-card mail now names the board and both stacks. DeckIntegrationService::describeTargets() resolves the titles at most once per workflow run, and only when a card actually moved and the workflow wants a mail; unreadable titles degrade to #<id> rather than costing the user their notification.	2026-08-13 23:02:13 +02:00
Patrick Niebeling	0eff367268	Handle workflows whose board or stack was deleted ... Deleting a board or stack left the workflow row pointing at nothing: Deck keeps the orphaned cards readable until its DeleteCron purges them, so the run kept failing on the move every few minutes, silently and forever. - The controller now rejects boards and stacks that do not exist (or are not the user's) on create and update, so no new broken row can be stored. - The settings list marks affected workflows in red instead of showing a row that looks healthy. - The background job disables such a workflow and mails its owner once. The mail ignores the notifyEmail flag: that one is about moved cards, this is a notice that the automation stopped. It stays a one-off because a disabled workflow is no longer picked up. The check deliberately goes through StackService::findAll() rather than BoardService::getUserBoards(): Deck injects the current user into BoardService as a string frozen at construction, so in the job -- one process, many users, a cached BoardService -- it would answer for the wrong user or for none, and every workflow on the instance would have been disabled. findStackIds() returns null only for a genuinely missing or forbidden board and throws for anything else, so a Deck outage skips the workflow instead of killing it.	2026-08-13 15:47:55 +02:00
Patrick Niebeling	68d88e952b	Include the card description in the notification mail ... The mail named the card and the workflow but not what the card is about, which meant opening Deck to know whether the move mattered. The description is escaped explicitly: addBodyText() only calls htmlspecialchars() when it has to derive the plain-text part itself, and we pass both parts to get line breaks in the HTML body -- so escaping user input is on us. Long descriptions are cut at 2000 characters. Deck stores the description as Markdown; it is sent unrendered rather than pulling in a parser for one mail.	2026-08-13 15:01:53 +02:00
Patrick NiebelingandClaude Sonnet 5	300acde27e	Add Deck workflow automation Nextcloud app ... Ports the standalone due-date cron script into a proper Nextcloud 34 app with a personal-settings UI, per-user workflow configuration (source/target stack, assigned-user and label filters, email notification), a TimedJob background runner, and Gitea CI pipelines. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-13 10:13:05 +02:00