MotirBuilding in public
MOTIR · moooon
onMotir
You’re viewing a public project. Anyone can view it — no account needed. Sign in to submit, upvote, or comment on requests.View-only — you can’t edit work items
MOTIR-366

6.6.3 Epic-5 registry extensions — commented + transitioned triggers, add-watcher / add-comment / add-label / set-custom-field actions, Epic-5 condition rows

Done
Description

Estimate: 28m · Depends on: 6.6.2, 6.1.2, 5.1.2, 5.3.3, 5.4.2, 5.4.4, 5.4.5

The registry + engine extensions consuming the Epic-5 surfaces — the same extension pattern as 6.1.2 over 6.1.1.

Triggers: commented consumes work-item/comment.created (5.1.2's emit — a third consumer, no new emit path) and transitioned consumes work-item/transitioned (5.4.5's emit), both honoring provenance skip; both events grow the viaAutomationRuleId? field if 5.1.2/5.4.5 landed without it.

Actions: add-watcher (a member picker config) via watchersService (5.4.4 — its view-access validation applies; an ineligible user = a recorded failure); add-comment (a fixed-body config) via commentsService (5.1.2 — mention parsing applies; the comment's own event carries provenance so mention emails still send but no rule re-fires); add-label (type-to-create config) via labelsService (5.4.2 find-or-create semantics); set-custom-field (per-type value config — select option / user / number / date / text) via customFieldsService values (5.3.3 — per-type validation + revision diffs apply). Each is a TOTAL registry entry (config schema + validate + execute + editor kind); stale referents (deleted option/label/field/user) degrade to a recorded failure with the typed error, never a crash.

Conditions: the rule editor's field vocabulary grows the 6.1.2 dynamic entries (custom fields, labels, components) — the condition compiler already handles them; this subtask wires validation + the editor-kind contract.

Acceptance criteria

  • All four new actions execute through their owning services with full side-effect fidelity (watcher emails fan out per 5.4.5, mention parsing runs, revision rows land) attributed to the rule owner; provenance stamps every follow-on event (loop proof extends: comment-trigger rule + add-comment action runs once).
  • Both new triggers narrow correctly (transitioned from/to) and skip provenance events; registry totality preserved (enumeration tests cover the extensions); stale-referent configs fail typed per referent kind.
  • Epic-5 condition rows gate rules correctly (CF / label / component predicates via the 6.1.2 joins, spot-checked with EXPLAIN on the large seed).
  • pnpm test:coverage ≥90% on the extensions.

Context refs

  • 6.6.1/6.6.2 (the registries + engine extension points)
  • 5.1.2 commentsService + its event; 5.4.4 watchersService; 5.4.2 labelsService; 5.3.3 customFieldsService values; 5.4.5 work-item/transitioned
  • 6.1.2 (the dynamic condition entries + stale-referent rule)
  • The verified Jira action list in the Story 6.6 description (the top-tier justification)
Status
Done
Type
Sub-task