@xeplr/actions 1.1.24 → 1.3.0

package/README.md

@@ -87,7 +87,7 @@ var moved = await actions.runAction(actions.builtins.dbMove, {
 |---|---|
 | `name` | Required. |
 | `description` | Text for pickers. |
-| `inputSchema` | `[{ name, type, required, default, description, order, ... }]`, validated by `@xeplr/schema-handler` `applySchema`. Built-ins also use `group`, `showWhen`, `system`, `options`, `optionsFrom`, `dependsOn` — hints for a form; validation treats every field the same. |
+| `inputSchema` | `[{ name, type, required, default, description, order, ... }]`, validated by `@xeplr/schema-handler` `applySchema`. Built-ins also use `group`, `showWhen`, `system`, `options`, `optionsFrom`, `dependsOn`, `label`, `hidden` (left out of a form unless a value is already set), `suggestFrom` / `suggestWith` (a host option source that suggests values, asked with the named sibling inputs; `db-procedure`'s parameters ask `procedureParams` with the connection, database and procedure) and `control` (`'parameters'`: `[{ name, value }]` shown as rows, a value fixed or bound to the run's window: `{window.from}` / `{window.to}`, see `@xeplr/jobs`) — hints for a form; validation treats every field the same. |
 | `outputSchema` | Optional documentation of the return value. |
 | `requires` | Module names checked with `require.resolve` at `register()`. |
 | `execute({ input, system, metaStore })` | Returns (or resolves to) the output. |
@@ -159,7 +159,7 @@ For `mode: 'table'` the source's declared column types (`getTableSchema`) are pa
 | `mysql` | `CALL name(?, ?)` — positional; names are ignored (and logged as such) |
 | `postgres` | `SELECT * FROM fn(param => …)` when `returnsRows` (default `true`), `CALL proc(param => …)` when `false` |
 
-`params` is `[{ name, value }]` or bare values; values are always bound. `''` becomes `null`, integer- and decimal-looking strings become numbers, and an object value is an error naming the parameter. A schema-qualified name (`dbo.usp_x`) is quoted per part. `window: { from, to, fromParam, toParam }` appends the two bounds as parameters after `params` (null edges passed as `NULL`); a window without `fromParam`/`toParam` is refused. `maxRows` fails the run when more rows come back. If `system.log` is supplied it gets the statement, parameter count and window bounds — not the other parameter values.
+`params` is `[{ name, value }]` or bare values; values are always bound. `''` becomes `null`, integer- and decimal-looking strings become numbers, and an object value is an error naming the parameter. A schema-qualified name (`dbo.usp_x`) is quoted per part. `window: { from, to, fromParam, toParam }` appends the two bounds as parameters after `params` (null edges passed as `NULL`); a window without `fromParam`/`toParam` is refused. From a job, the usual way to pass dates is as ordinary parameters bound to the run's window, `{ "name": "startDate", "value": "{window.from}" }` (`@xeplr/jobs` fills them in); `params` carries `control: 'parameters'` and `window` is `hidden`, so a form shows rows instead of JSON. `maxRows` fails the run when more rows come back. If `system.log` is supplied it gets the statement, parameter count and window bounds — not the other parameter values.
 
 ### Email
 

package/lib/builtins/db/procedure.js

@@ -89,13 +89,24 @@ module.exports = {
     // Half-open, from <= x < to. The next run starts at exactly this run's
     // `to`, so a procedure treating `to` as inclusive double-counts the
     // boundary row every time.
-    { name: 'window',      type: 'object', order: 6, group: 'Incremental',
+    // `hidden`: a form leaves it out unless a job already holds one. A job's
+    // dates now reach a procedure as ordinary parameters bound to the run's
+    // window — see `params` — which needs no names typed into JSON here.
+    { name: 'window',      type: 'object', order: 6, group: 'Incremental', hidden: true,
       description: '{ from, to, fromParam, toParam } — the period this run covers, passed as the ' +
                    'named parameters fromParam/toParam. Filled automatically for a job with ' +
                    'incrementalMode "period"; name the two parameters and leave from/to empty. ' +
                    'A window without fromParam/toParam is refused rather than silently dropped.' },
 
-    { name: 'params',      type: 'array', order: 7,
+    // `control: 'parameters'`: a form shows these as rows — a name and where
+    // its value comes from (a fixed value, or the start / end of the run's
+    // window, which a job binds as "{window.from}" / "{window.to}").
+    // `suggestFrom`: where a form finds the procedure's own parameter names
+    // (a host option source), asked with the values of `suggestWith` — the
+    // connection, database and procedure chosen above.
+    { name: 'params',      type: 'array', order: 7, control: 'parameters', label: 'Parameters',
+      suggestFrom: 'procedureParams',
+      suggestWith: { connectionId: 'connectionInfoId', dbInfoId: 'dbInfoId', procedure: 'procedure' },
       description: 'Parameters, as [{ name, value }] or bare values. Named entries are matched by ' +
                    'name on postgres and mssql; MySQL has no named-argument syntax, so there they ' +
                    'are positional and must be in the order the procedure declares them.' },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@xeplr/actions",
-  "version": "1.1.24",
+  "version": "1.3.0",
   "description": "Named-action registry with typed inputs and safe invocation — plus built-in actions for HTTP, DB, files, email, spawn",
   "main": "index.js",
   "files": [