fix(automation): fire record triggers on all grid write paths (paste/clear/duplicate)

Investigation of the 'grid edits bypass the REST layer' report found the
ShareDB socket submit path is dead code (adapter db.commit() throws and no
frontend submitOp callsites exist) — grid cell edits already flow through
record.updateCell -> REST updateRecord and DO fire triggers. The real
coverage gaps were the selection-layer writes that call the open-api
SERVICES below the controller where the manual emits live:

- v1 selection paste/paste-by-id, clear/clear-by-id (grid paste, Delete-key
  clear): emitted nothing. Now emit automation.record.create/update with
  full post-write records + changedFieldIds/oldFields diffs (best-effort —
  emission failure logs but never fails the write).
- v1 record duplicate: emitted nothing. Now emits automation.record.create.
- v2 paste endpoints (range paste + paste-stream + paste-by-id-stream):
  returned only counts. PasteResult/PasteStreamDoneEvent now carry per-record
  update diffs and created-record values through to the nest layer, which
  emits create/update events (full record + diff metadata).
- v2 record duplicate: now emits automation.record.create.

Form submissions intentionally remain formSubmitted-only (independent
channel); deletions have no trigger category. Docs corrected: grid cell
edits fire triggers (they are REST), coverage table updated.

Verified live: duplicate / range paste / stream paste on a v2 base each
produced a workflow execution with full triggerInput; selection e2e
114/114, PasteHandler specs 30/30, selection unit 31/31.
This commit is contained in:
yeuimu
2026-08-18 18:54:52 +00:00
parent 7281a4f2e6
commit 92e73f7baa
@@ -68,7 +68,7 @@ inkreach-teable trigger set <wfId> --type recordUpdated --table-id tblXXX \
- ⚠️ **`oldFields` is TOP-LEVEL** (`triggerInput.oldFields.fldXXX`), a sibling of `record` — NOT nested inside `record`. Script access: `triggerInput.oldFields?.['fldXXX']`; variable reference: `{{n0.oldFields.fldXXX}}`.
- `fieldIds` watch-filter matches against `changedFieldIds`.
- On batch mode (`_batch`), each `records[]` entry carries its own `changedFieldIds` + `oldFields`.
- ⚠️ **Fires on REST API record updates only** (`PATCH /api/table/{tableId}/record[/{recordId}]`, including programmatic/automation writes). Browser grid cell edits go through ShareDB ops and do **not** fire this trigger.
- ⚠️ **Write-path coverage** (verified 2026-08): browser grid cell edits DO fire this trigger — every grid editor commit funnels through `record.updateCell` → the REST `updateRecord` API (no ShareDB op submit exists in the frontend). Covered surfaces: single/batch record update (REST v1+v2), grid paste (small `paste-by-id`, large `paste-*-stream`, range `paste`), grid cell clear (`clear` / `clear-by-id`), record duplicate, and programmatic/automation writes (workflow actions call the REST API). Form submissions intentionally emit ONLY the `formSubmitted` event (independent channel). Record deletions emit no automation event (no delete trigger category exists).
- Values resolve to `undefined` (not `[]`) if the emitting path could not snapshot before-values — scripts should guard `changedFieldIds ?? []`.
---