feat(messaging,cli): messaging + triggers capability tokens; notify-by-email resolves to user id#1426
Merged
Conversation
…olve notify-by-email to user id
Two related platform improvements that make the `notify` flow node and
auto-firing flows usable from a plain `defineStack({ requires: [...] })`,
without hand-wiring plugin instances.
CLI / runtime — new capability tokens
• `messaging` → MessagingServicePlugin, so the `notify` node delivers to a
user's inbox channel (sys_inbox_message rows) instead of degrading to a
logged no-op.
• `triggers` → RecordChangeTriggerPlugin (+ ScheduleTriggerPlugin extra), so
autolaunched / schedule flows actually fire. The automation engine ships
the FlowTrigger wiring; these plugins are the concrete triggers. Pair
`triggers` with `job` for cron/interval schedules.
Mirrored in both the CLI CAPABILITY_PROVIDERS table (serve.ts) and the
runtime capability-loader so dev `objectstack serve` and the cloud
artifact kernel resolve them identically. CLI package.json gains the
workspace deps so the dynamic imports resolve.
Inbox channel — notify-by-email lands in the right inbox
Flows commonly address recipients by email (e.g. a `{record.assignee}`
field), but sys_inbox_message is keyed by user id. The inbox channel now
resolves an email-shaped recipient to its sys_user.id via findOne, with a
verbatim fallback when the recipient is not email-shaped, no user matches,
or the lookup fails — so a failed resolution can never drop the row.
Adds InboxChannelOptions.userObject for the lookup target. Fully covered
by new unit tests.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
| data: IDataEngine, | ||
| recipient: string, | ||
| ): Promise<string> { | ||
| if (!EMAIL_SHAPE.test(recipient)) return recipient; |
This was referenced Jun 1, 2026
xuyushun441-sys
added a commit
that referenced
this pull request
Jun 1, 2026
Activates the showcase's automation chains now that the platform supports them (capability tokens from #1426; conditional/record-change flows fixed in #1429): - requires: ['ui','automation','approvals','messaging','triggers','job'] so the notify node delivers and record-change/schedule flows auto-fire. - Register the `rest` + `slack` connectors for the connector_action node. `rest` points at the running server (SHOWCASE_SELF_URL) so its call + response are observable with no external dependency. - Two worked flows: ScheduledDigestFlow (interval schedule → notify → inbox) and TaskCompletedRestPingFlow (record-change → rest connector GET /health). - Fix BudgetApprovalFlow's decision node: branch on edge `condition` (`budget > 500000` / `<= 500000`) per the flow spec, instead of the unevaluated node-level config + true/false labels — so budgets ≤ $500k correctly skip the executive approval step. - Ambient `process` decl so `pnpm typecheck` stays green without @types/node. Verified end-to-end in the browser: schedule digest, reassign→notify→inbox (email→user-id resolved), mark-done→REST/Slack/email, budget→approval with correct decision routing and approve→resume. Co-authored-by: Jack Zhuang <277994282+os-zhuang@users.noreply.github.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Two related platform improvements that make the
notifyflow node and auto-firing flows usable from a plaindefineStack({ requires: [...] })— no hand-wired plugin instances.CLI / runtime — new capability tokens
messaging→MessagingServicePlugin, so thenotifynode delivers to a user's inbox channel (sys_inbox_messagerows) instead of degrading to a logged no-op.triggers→RecordChangeTriggerPlugin(+ScheduleTriggerPluginas an extra), so autolaunched / schedule flows actually fire. The automation engine ships theFlowTriggerwiring; these plugins are the concrete triggers. Pairtriggerswithjobfor cron/interval schedules.Mirrored in both the CLI
CAPABILITY_PROVIDERStable (serve.ts) and the runtimecapability-loaderso devobjectstack serveand the cloud artifact kernel resolve them identically.cli/package.jsongains the workspace deps so the dynamic imports resolve.Inbox channel — notify-by-email lands in the right inbox
Flows commonly address recipients by email (e.g. a
{record.assignee}field), butsys_inbox_messageis keyed by user id. The inbox channel now resolves an email-shaped recipient to itssys_user.idviafindOne, with a verbatim fallback when the recipient is not email-shaped, no user matches, or the lookup fails — so a failed resolution can never drop the row. AddsInboxChannelOptions.userObjectfor the lookup target.Test
pnpm --filter @objectstack/service-messaging test— 24 passing (incl. 5 new resolution cases: resolve, userObject override, non-email verbatim, no-match fallback, lookup-throw fallback).service-messaging+cli+runtimebuild clean.Notes / follow-up (separate work)
The Console header bell currently reads
sys_notification(ADR-0012 Layer-2 by name, but shipped as a per-user inbox), while the messaging inbox channel writessys_inbox_message(ADR-0012 Layer-5). Reconciling those two — and the showcase wiring that demonstrates these tokens end-to-end — is intentionally out of scope here and will land separately (needs an ADR decision on which object is the canonical in-app inbox).🤖 Generated with Claude Code