Adds two new triggers and a new action to the bundled automations plugin,
along with the host-side and validator changes needed to make them
reliable end to end.
Plugin
- New triggers TriggerTaskStarted / TriggerTaskStopped that fire on timer
start / stop. Switching from task A to task B emits taskStopped(A) and
then taskStarted(B), so a rule subscribed to either trigger gets the
full lifecycle. The trigger descriptions document this explicitly.
- New ActionRemoveTag mirroring ActionAddTag, with a shared resolveTagId
helper covering id/title lookup, missing-tag warning, and idempotent
short-circuiting.
- Import goes through a new RuleRegistry.addRules(rules[]) + addRules
message, so the host's 1 call/sec persistDataSynced rate limit no
longer rejects multi-rule imports.
- Validators in core/rule-registry.ts and utils/rule-validator.ts share a
set of `as const` arrays guarded by a TS _AssertEq exhaustiveness check
against the union types in types.ts. The arrays are duplicated rather
than exported from types.ts because that would turn types.ts into a
shared runtime chunk and break plugin.js (which the host evaluates via
`new Function`, not as an ES module).
- Import validator no longer requires a truthy rule name — the UI saves
empty-named rules, the load-path accepts them, and the import path
needed to match.
- ActionDialog gets a removeTag placeholder. Manifest's hooks list is
updated to include the hooks the plugin actually registers
(taskCreated, currentTaskChange) so the permission disclosure UI is
accurate.
Host
- plugin-hooks.effects.ts onCurrentTaskChange$ now observes
selectCurrentTask directly instead of only setCurrentTask /
unsetCurrentTask actions. This catches transitions through reducer
paths that don't dispatch those actions (loadAllData, deleteProject,
bulk task delete via the shared CRUD meta-reducer).
- The payload changes from the raw new Task to { current, previous },
matching the long-declared CurrentTaskChangePayload shape. The effect
uses pairwise on the selector and filters same-id pairs at the event
boundary (not via distinctUntilChanged on the source) so the
`previous` task always carries the latest snapshot — including
in-place updates a plugin made while the task was running. Without
this, addTag-on-start / removeTag-on-stop only worked every other
cycle because `previous` reflected the pre-mutation snapshot.
Other plugins consuming currentTaskChange (voice-reminder, api-test-plugin)
read payload.current instead of the raw Task.
* fix(plugin-bridge): enhance task update logic and validation for project movement
* fix(plugin-bridge): include changes in task update event payload
* feat(RuleEditor): add tests for rule editing functionality and enhance action handling
* test(RuleEditor): add comprehensive tests for rule editing and condition handling
* feat(RuleRegistry): enhance rule validation and add support for advanced conditions and actions
* feat(types): extend condition and action types for enhanced automation capabilities
* feat(conditions): add regex support for title conditions and enhance checks
* feat(actions): add ActionMoveToProject to move tasks between projects
* feat(ActionDialog, ActionInput): add support for moveToProject action and enhance input handling
* feat(ConditionDialog, ConditionInput): add support for titleStartsWith and weekdayIs conditions, enhance regex handling
* feat(styles): add new input-with-toggle and field-error styles for improved layout and error handling
* feat(automation): add titleStartsWith condition and enhance task event handling
* feat(automations): add delete task action
add a new `deleteTask` action to the automations plugin
- register the action in the automation runtime
- expose it in the rule editor UI
- restrict it to task-based triggers
- validate and persist rules using `deleteTask`
- add focused tests for runtime behavior, validation, persistence, and UI
* feat(automations): remove false trigger workaround
remove the temporary taskCreated fallback after confirming the
reported trigger bug was a mistaken assumption
* fix(automations): address PR review feedback
- Add regex pattern length cap (200 chars) to mitigate ReDoS risk
- Use project ID instead of title as option value to prevent duplicate name collisions
- Replace dynamic import('rxjs') with static import for firstValueFrom
- Replace any[] with proper types for projects/tags props
- Replace changes?: any with Record<string, unknown> in TaskEvent
- Use createMemo + <Show> for regexError to avoid double reactive computation
- Remove noisy/inconsistent debug logging from automation-manager
- Remove verbose intermediate log from moveToProject action
- Clean up mock: remove unused moveTaskToProject, restore PluginAPI type
- Prefer ID lookup over title in ActionMoveToProject
* fix(automations): harden regex, use IDs for conditions, add validation and tests
- Add dangerous-pattern heuristic to reject nested quantifiers (e.g. (a+)+$)
that cause catastrophic backtracking, supplementing the length cap
- Switch projectIs/hasTag condition dropdowns to store IDs instead of titles
to survive project/tag renames (with title fallback for backward compat)
- Disable ActionDialog Save button when value is empty (except deleteTask)
- Fix webhook test to actually validate payload sanitization
- Add test for HTML escaping in ActionDisplayDialog
- Add tests for regex length cap and dangerous-pattern rejection
- Add tests for ConditionWeekdayIs (7 test cases covering full names,
abbreviations, comma-separated lists, case insensitivity, edge cases)
* test(automations): build dangerous regex pattern dynamically to avoid CodeQL flag
The test intentionally uses a catastrophic-backtracking pattern to verify
our safety heuristic rejects it. Build it via string concatenation so
CodeQL's static analysis doesn't flag the test itself.
* fix(automations): addTag lookup by ID, widen ReDoS heuristic to catch {n,}
- ActionAddTag now looks up tags by ID first (with title fallback),
consistent with all other condition/action lookups
- Extend DANGEROUS_REGEX_PATTERN to also detect {n,} quantifiers
inside nested groups (e.g. (a{2,})+) which also cause backtracking
---------
Co-authored-by: Johannes Millan <johannes.millan@gmail.com>
