@colixsystems/widget-sdk 0.141.0 → 0.142.1

package/README.md

@@ -70,7 +70,30 @@ See the design reference for the full architecture: [`docs/architecture/widget-m
 
 ## Status
 
-`v0.141.0` — pre-publish. The package surface (types, function names, export paths) is the v1 contract; runtime behaviour for some hooks is stubbed (each hook documents what's wired and what isn't). It is **not yet published to npm**.
+`v0.142.0` — pre-publish. The package surface (types, function names, export paths) is the v1 contract; runtime behaviour for some hooks is stubbed (each hook documents what's wired and what isn't). It is **not yet published to npm**.
+
+### What's new in 0.142.1
+
+**A native file upload no longer crashes the app (sc-7906).** Making the part a `File` let the upload through, and then the app died on any real file: Expo's `fetch` builds a multipart body by reading the WHOLE file into the JS heap — `convertFormDataAsync` awaits `part.bytes()` and concatenates — so a send costs about three times the file's size on the JS thread. The native host now streams the file off disk through expo-file-system's upload task instead. `<FilePicker>`, `useCamera()` and `useImageEditor()` are unchanged for a widget author — the picked file stays where the picker put it, so `asset.uri` still renders, and the name the user chose travels to the backend as an explicit `file_name` field.
+
+### What's new in 0.142.0 (contract 1.110.0)
+
+**An action script can finally tell WHO started the run — `triggeredBy` joins `CONTRACT.actionScriptGlobals` (sc-7885).** The identity was already captured (the run history has recorded an `actorId` since REQ-ACTION-RUNLOG) but never reached the sandbox, so a script could do the work and not attribute it: no "X submitted this" notification back to the submitter, no audit row naming the actor. Authors worked around it by writing the user id into a record first and switching to a `record_*` trigger — plumbing in the app's data model, and not available to a plain button press at all.
+
+```js
+if (triggeredBy && triggeredBy.type === "app_user") {
+  await notifications.notifyUser(triggeredBy.id, {
+    title: "Request received",
+    body: "Thanks " + triggeredBy.name + ", we have started on it.",
+  });
+}
+```
+
+- The shape is `{ type, id, name, email, role }`, frozen, or **`null` when nothing initiated the run** — a `schedule` tick or a `record_*` event. `null` is the normal case for the automation triggers, so guard before reading it.
+- **`type` is load-bearing, not decoration.** It is `"app_user"` on an `app` button press and an `http_post` webhook, and `"studio_user"` on an operator's Run now. One id column, two directories behind it: check `type` before handing the id to `notifications.notifyUser` or a USER column, or a studio user's id will silently resolve to nobody. `role` carries the app-user vocabulary (`USER` / `INTEGRATION`) and is `null` for a studio user, whose workspace role is a different axis entirely. `email` is likewise `null` for a studio user: nothing in a script can address an operator, so shipping their real address to an installed third-party Action would be PII with no consumer.
+- **It grants nothing.** The script still runs as the Action's bound integration identity, exactly as before; `triggeredBy` describes the caller and does not widen the data the script can reach. Resolution is host-side and tenant-scoped, so a stale or foreign id resolves to `null` rather than leaking a row across workspaces.
+- Actions never render, so this has **no effect on Player ↔ export parity** (CLAUDE.md §8).
+- Also in this release: **`properties` was added to `CONTRACT.actionScriptGlobals`**, which the `@colixsystems/action-sdk` copy of the list had carried since 1.50.0 while this one had not — the two hand-mirrored lists had drifted. A parity test now pins them together. `CONTRACT.version` → `1.110.0`. Additive for every existing manifest and script.
 
 ### What's new in 0.141.0 (contract 1.109.0)
 
@@ -507,7 +530,7 @@ When you take the `useCanWrite`-only route, omit the USER column for a guest (`i
 
 **Dismissing the picker resolves `null`, not an error.** Backing out is the most common outcome, so it is deliberately not a rejection — your happy path needs no `try/catch`. A genuine failure (permission refused, no host broker) rejects with a structured `CameraError` (new named export) carrying a stable `.code` (`PERMISSION_DENIED` / `UNSUPPORTED` / `INTERNAL`).
 
-**One upload path on both hosts.** The resolved asset is normalised to `{ uri, name, mimeType, width, height, size, file }`, where `uri` is directly displayable (`<Image source={{ uri }} />`) and `file` is already the right upload part for the platform — a Blob on both hosts: a browser `File` on web, expo-file-system's `File` on native. (It must be a Blob: Expo's fetch implements the web FormData spec and rejects React Native's legacy `{ uri, name, type }` part.) So the same three lines work everywhere:
+**One upload path on both hosts.** The resolved asset is normalised to `{ uri, name, mimeType, width, height, size, file }`, where `uri` is directly displayable (`<Image source={{ uri }} />`) and `file` is already the right upload part for the platform — a browser `File` on web, expo-file-system's `File` on native. (Never React Native's legacy `{ uri, name, type }` part: the native host streams the file off disk, and Expo's fetch rejects that part outright anyway. Do not branch on the part's type — an expo-file-system `File` is NOT `instanceof Blob` at runtime.) So the same three lines work everywhere:
 
 ```js
 const fd = new FormData();

package/dist/contract.cjs

@@ -1990,12 +1990,23 @@ const ACTION_TRIGGER_TYPES = [
 // Globals the action script runs against (the runner's surface) — distinct
 // from the React/SDK widget surface, so the component import/banned-API
 // linter does NOT scan action scripts.
+// sc-7877 deliberately does NOT add `directory` here. That global is
+// reachable only by a MARKETPLACE action whose install consented to a
+// `directory:` scope; a widget-declared action has no install, so
+// resolveForActionRow grants it nothing and the global is never defined.
 const ACTION_SCRIPT_GLOBALS = [
   "datastore",
   "secrets",
+  // Was missing here while action-sdk listed it — the two hand-mirrored lists
+  // had drifted. action-script-globals-parity.test.cjs now pins them together.
+  "properties",
   "fetch",
   "connectors",
   "notifications",
+  // Conditionally defined — only when the install consented to a `directory:`
+  // scope. Added to the WIDGET-sdk copy here: sc-7891 put it in the action-sdk
+  // list alone, the same drift this commit's parity test now catches.
+  "directory",
   "console",
   "record",
   // sc-5366 — `{ body }` on a run fired by the inbound `http_post` trigger,
@@ -2004,6 +2015,8 @@ const ACTION_SCRIPT_GLOBALS = [
   "tenantId",
   "triggerType",
   "triggerTableId",
+  // sc-7885 — who initiated the run; null on `schedule` / `record_*`.
+  "triggeredBy",
 ];
 // Mirrors action.service.js SCRIPT_MAX_BYTES.
 const ACTION_SCRIPT_MAX_BYTES = 200 * 1024;
@@ -3970,7 +3983,16 @@ const CONTRACT = deepFreeze({
   //    and the sc-7352 backfill deletes the stored key (a bottom-tabs app's
   //    strip becomes the sidebar's quick bar) BEFORE this ships.
   //    `menuItemCap` / `quickBarCap` keep their signatures.
-  version: "1.109.0",
+  // 1.110.0: additive (sc-7885) — `triggeredBy` joins `actionScriptGlobals`:
+  //    WHO initiated this run, as `{ type, id, name, email, role }`, or `null`
+  //    on `schedule` / `record_*` where nothing did. `type` is `"app_user"` (an
+  //    `app` button press or an `http_post` webhook) or `"studio_user"` (an
+  //    operator's Run now) — load-bearing, because those are two different
+  //    directories behind one id. The script still runs as the Action's bound
+  //    integration identity; this describes the caller, it does not grant
+  //    anything. The same commit adds `properties` to this list, which the
+  //    action-sdk copy had carried since 1.50.0 while this one had not.
+  version: "1.110.0",
   sharedTranslationKeys: SHARED_TRANSLATION_KEYS,
   hooks: HOOKS,
   primitives: PRIMITIVES,

package/dist/contract.js

@@ -1993,9 +1993,16 @@ const ACTION_TRIGGER_TYPES = [
 const ACTION_SCRIPT_GLOBALS = [
   "datastore",
   "secrets",
+  // Was missing here while action-sdk listed it — the two hand-mirrored lists
+  // had drifted. action-script-globals-parity.test.cjs now pins them together.
+  "properties",
   "fetch",
   "connectors",
   "notifications",
+  // Conditionally defined — only when the install consented to a `directory:`
+  // scope. Added to the WIDGET-sdk copy here: sc-7891 put it in the action-sdk
+  // list alone, the same drift this commit's parity test now catches.
+  "directory",
   "console",
   "record",
   // sc-5366 — `{ body }` on a run fired by the inbound `http_post` trigger,
@@ -2004,6 +2011,8 @@ const ACTION_SCRIPT_GLOBALS = [
   "tenantId",
   "triggerType",
   "triggerTableId",
+  // sc-7885 — who initiated the run; null on `schedule` / `record_*`.
+  "triggeredBy",
 ];
 // Mirrors action.service.js SCRIPT_MAX_BYTES.
 const ACTION_SCRIPT_MAX_BYTES = 200 * 1024;
@@ -3970,7 +3979,16 @@ const CONTRACT = deepFreeze({
   //    and the sc-7352 backfill deletes the stored key (a bottom-tabs app's
   //    strip becomes the sidebar's quick bar) BEFORE this ships.
   //    `menuItemCap` / `quickBarCap` keep their signatures.
-  version: "1.109.0",
+  // 1.110.0: additive (sc-7885) — `triggeredBy` joins `actionScriptGlobals`:
+  //    WHO initiated this run, as `{ type, id, name, email, role }`, or `null`
+  //    on `schedule` / `record_*` where nothing did. `type` is `"app_user"` (an
+  //    `app` button press or an `http_post` webhook) or `"studio_user"` (an
+  //    operator's Run now) — load-bearing, because those are two different
+  //    directories behind one id. The script still runs as the Action's bound
+  //    integration identity; this describes the caller, it does not grant
+  //    anything. The same commit adds `properties` to this list, which the
+  //    action-sdk copy had carried since 1.50.0 while this one had not.
+  version: "1.110.0",
   sharedTranslationKeys: SHARED_TRANSLATION_KEYS,
   hooks: HOOKS,
   primitives: PRIMITIVES,

package/dist/filepicker.native.js

@@ -10,11 +10,11 @@
 //
 // `onPick` receives the same shape on both platforms:
 //   - web → the browser's `File` object (a `Blob` with name + type).
-//   - native → expo-file-system's `File` — ALSO a `Blob`, and carrying the
-//     same `uri` / `name` / `type` / `size` the old React Native
-//     `{ uri, name, type, size }` part did, so a widget reading those is
-//     unaffected. It must be a Blob: Expo's fetch implements the WEB
-//     FormData spec and rejects the RN triple outright ("Unsupported
+//   - native → expo-file-system's `File`, carrying the same `uri` / `name` /
+//     `type` / `size` the old React Native `{ uri, name, type, size }` part
+//     did, so a widget reading those is unaffected. It must be a file on
+//     disk: the host uploads it by streaming it off disk (sc-7906), and
+//     Expo's fetch rejects the RN triple outright anyway ("Unsupported
 //     FormDataPart implementation"), which failed every native upload.
 //     `useFilestoreUpload` appends whichever verbatim into the multipart body.
 
@@ -49,10 +49,9 @@ function _mapAccept(accept) {
 // keeping it as a fallback would only defer the failure.
 function _asset(picked) {
   const file = new FsFile(picked.uri);
-  // Both are read off the PART when the multipart is serialised (the third
-  // `append` argument is ignored for a non-Blob), and both are derived from
-  // the cache URI — which may be renamed, percent-encoded, or extensionless.
-  // The picker's own values are the ones the user and the backend expect.
+  // The File derives both from the cache URI, which may be renamed,
+  // percent-encoded or extensionless. The upload sends the part's `name` as
+  // the stored name (sc-7906), so the picker's values are the ones that win.
   _shadow(file, "name", picked.name || "upload");
   _shadow(file, "type", picked.mimeType || "application/octet-stream");
   return file;

package/dist/hooks.js

@@ -3571,14 +3571,13 @@ export function useFilestoreFile(fileId) {
  * same way the read hooks do (tenant for PROJECT, app user for PERSONAL)
  * and posts a multipart FormData to `ctx.filestore.files.upload`.
  *
- * `upload(file, { folderId?, fileName? })` takes a BLOB on both hosts — a
- * browser `File` on the web Player, expo-file-system's `File` (also a Blob)
- * on the Expo export, as `<FilePicker>`, `useCamera()` and `useImageEditor()`
- * all hand back. It must be a Blob: Expo's fetch implements the web FormData
- * spec and rejects React Native's legacy `{ uri, name, type }` part with
- * "Unsupported FormDataPart implementation", which failed every native
- * upload. `fileName` overrides the stored name, which otherwise comes from
- * the Blob's own `.name`.
+ * `upload(file, { folderId?, fileName? })` takes a browser `File` on the web
+ * Player and expo-file-system's `File` on the Expo export, as `<FilePicker>`,
+ * `useCamera()` and `useImageEditor()` all hand back. Never React Native's
+ * legacy `{ uri, name, type }` part: the native host streams the file off
+ * disk (sc-7906), and Expo's fetch rejects that part outright anyway with
+ * "Unsupported FormDataPart implementation". `fileName` overrides the stored
+ * name, which otherwise comes from the part's own `.name`.
  *
  * The destination can refuse the add two ways (sc-6977). BRANCH ON
  * `err.status`: 403 means the caller may know why — most often a public space

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@colixsystems/widget-sdk",
-  "version": "0.141.0",
+  "version": "0.142.1",
   "description": "Common widget interface for AppStudio. Implements WidgetManifest, WidgetContext, property schema, and helper hooks.",
   "homepage": "https://github.com/Colix-AB/AppStudio",
   "type": "module",