@protobase/cli 0.71.0 → 0.71.1

package/dist/cli/package.js

@@ -1,4 +1,4 @@
 //#region package.json
-var version = "0.71.0";
+var version = "0.71.1";
 //#endregion
 export { version };

package/dist/users/load-auth.d.ts

@@ -4,7 +4,8 @@ import { AdminAuth } from "@protobase/server";
  * The sign-in of the project in `projectDir`, built from its config's `auth` over DATABASE_URL, with only the plugins
  * it turns on. With a device or history store of the app's own (notifications/store.ts, notifications/history-store.ts),
  * deleting a user removes their devices or history from it too; the built-in tables go with the user by their foreign
- * keys.
+ * keys. With workflows, deleting a user revokes their connected accounts and parks the triggers on them, as the app
+ * does, reporting a token it left valid on stderr.
  */
 export declare const loadProjectAuth: (projectDir: string) => Promise<AdminAuth>;
 //#endregion

package/dist/users/load-auth.js

@@ -1,23 +1,30 @@
 import { loadNearestEnvFile } from "../dev/env.js";
-import { projectNotifications } from "../config/project-parts.js";
+import { projectNotifications, projectWorkflows } from "../config/project-parts.js";
 import { projectAuth } from "../config/build-project.js";
 import { loadSourceConfig } from "../config/source-config.js";
 import { openAppDatabase } from "../project/pg-db.js";
 import pg from "pg";
-import { removeDevicesWithUsers, removeHistoryWithUsers } from "@protobase/server";
+import { releaseConnectionsWithUsers, removeDevicesWithUsers, removeHistoryWithUsers } from "@protobase/server";
 //#region src/users/load-auth.ts
 /**
 * The sign-in of the project in `projectDir`, built from its config's `auth` over DATABASE_URL, with only the plugins
 * it turns on. With a device or history store of the app's own (notifications/store.ts, notifications/history-store.ts),
 * deleting a user removes their devices or history from it too; the built-in tables go with the user by their foreign
-* keys.
+* keys. With workflows, deleting a user revokes their connected accounts and parks the triggers on them, as the app
+* does, reporting a token it left valid on stderr.
 */
 const loadProjectAuth = async (projectDir) => {
 	loadNearestEnvFile(projectDir);
 	const config = await loadSourceConfig(projectDir, { command: "tool" });
 	if (!config.auth) throw new Error("Sign-in is off (`auth: false` in the config), so the app has no users to manage");
 	if (!process.env.DATABASE_URL) throw new Error("No database: set DATABASE_URL");
-	const [auth, notifications] = await Promise.all([projectAuth(config, openAppDatabase(pg, process.env.DATABASE_URL)), projectNotifications(config)]);
+	const database = openAppDatabase(pg, process.env.DATABASE_URL);
+	const [workflows, notifications] = await Promise.all([projectWorkflows(config), projectNotifications(config)]);
+	const auth = await projectAuth(config, database, workflows);
+	if (workflows) releaseConnectionsWithUsers(auth, workflows, {
+		db: database.db,
+		report: (error) => void process.stderr.write(`${error.message}\n`)
+	});
 	if (notifications?.store) removeDevicesWithUsers(auth, notifications.store);
 	if (notifications?.historyStore) removeHistoryWithUsers(auth, notifications.historyStore);
 	return auth;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@protobase/cli",
-  "version": "0.71.0",
+  "version": "0.71.1",
   "description": "The protobase command: scaffold, doctor, dev, build and serve a Protobase project.",
   "license": "Apache-2.0",
   "repository": {
@@ -43,13 +43,13 @@
   "dependencies": {
     "@better-auth/core": "^1.7.12",
     "@hono/node-server": "^2.1.3",
-    "@protobase/config": "0.71.0",
-    "@protobase/layout": "0.71.0",
-    "@protobase/query": "0.71.0",
-    "@protobase/schema": "0.71.0",
-    "@protobase/server": "0.71.0",
-    "@protobase/ui": "0.71.0",
-    "@protobase/workflows": "0.71.0",
+    "@protobase/config": "0.71.1",
+    "@protobase/layout": "0.71.1",
+    "@protobase/query": "0.71.1",
+    "@protobase/schema": "0.71.1",
+    "@protobase/server": "0.71.1",
+    "@protobase/ui": "0.71.1",
+    "@protobase/workflows": "0.71.1",
     "@react-email/render": "^2.1.0",
     "@scalar/hono-api-reference": "^0.12.10",
     "@sentry/vite-plugin": "^11.10.0",

package/skills/protobase/references/reference/workflows.md

@@ -223,7 +223,7 @@ A save also refuses a Task that leaves out an argument its step type needs, such
 Each connected account belongs to the person who connected it, and only that person can turn on a workflow that uses it.
 :::
 
-A trigger or step type that signs in to another service, such as a mailbox, uses an account that someone connected. Each person connects their own accounts on the **Connections** section of the account page's Profile tab. Connecting takes them to the provider and back. Under each account, the section links each workflow that uses it: those the person turned on, whose enabled version binds the account, while they may still change them. The app keeps the account's tokens on the server, encrypted, and refreshes them when they expire. **Disconnect** first makes the triggers on the account wait for a new sign-in, then asks the provider to revoke the token when the connection has a revocation endpoint, and then deletes the account, so no step or trigger can use the token again, even one that was fetching it at that moment. The answer's `revocation` says what became of the token: `revoked` when the provider took it, `queued` when it did not answer or refused, and `not_revoked` when the connection has no revocation endpoint or the token could not be revoked or queued, as when it no longer decrypts with the app's secret; the section shows it. A queued token is tried again later, waiting from a minute up to an hour between tries, ten tries in all. Until then it keeps the token encrypted with the app's secret, in the workflows schema's `connection_revocations`, and drops it once the provider takes it, after the last try, or once the app's secret no longer decrypts it. A provider that never takes it keeps the token valid on its side. When stopping the triggers or deleting the account fails, disconnecting answers that error and keeps the account, and disconnecting again finishes the job. It answers `503` (`CONNECTIONS_STARTING`) and keeps the account while the workflows have not started. Its refusals come in the language the request asks for. <gap>Connection refusals from the auth endpoints cannot follow the app's `locale` setting because passing it to the auth instance, which is made before the app's options, is not implemented.</gap> The auth endpoint `/unlink-account` refuses an account that Connections lists (`403`, `CONNECTION_UNLINK_REFUSED`): disconnect it there. Connecting again makes a new account with a new id: bind it in the workflow's `connections` and turn the workflow on again. Revoking at Google ends everything the account allowed the app, the sign-in and a linked mailbox included, and the dialog says so.
+A trigger or step type that signs in to another service, such as a mailbox, uses an account that someone connected. Each person connects their own accounts on the **Connections** section of the account page's Profile tab. Connecting takes them to the provider and back. Under each account, the section links each workflow that uses it: those the person turned on, whose enabled version binds the account, while they may still change them. The app keeps the account's tokens on the server, encrypted, and refreshes them when they expire. **Disconnect** first makes the triggers on the account wait for a new sign-in, then asks the provider to revoke the token when the connection has a revocation endpoint, and then deletes the account, so no step or trigger can use the token again, even one that was fetching it at that moment. The answer's `revocation` says what became of the token: `revoked` when the provider took it, `queued` when it did not answer or refused, and `not_revoked` when the connection has no revocation endpoint or the token could not be revoked or queued, as when it no longer decrypts with the app's secret; the section shows it. A queued token is tried again later, waiting from a minute up to an hour between tries, ten tries in all. Until then it keeps the token encrypted with the app's secret, in the workflows schema's `connection_revocations`, and drops it once the provider takes it, after the last try, or once the app's secret no longer decrypts it. A provider that never takes it keeps the token valid on its side. When stopping the triggers or deleting the account fails, disconnecting answers that error and keeps the account, and disconnecting again finishes the job. It answers `503` (`CONNECTIONS_STARTING`) and keeps the account while the workflows have not started. Deleting a user, by an admin, by themselves or with `protobase users delete`, does the same for each of their connected accounts before the user goes; when it cannot, as while the workflows have not started, the user and their accounts stay, and deleting them again finishes the job. <gap>A user deletion refused while the workflows start cannot answer in the language the request asks for because passing the request to the user-deletion listeners is not implemented.</gap> Its refusals come in the language the request asks for. <gap>Connection refusals from the auth endpoints cannot follow the app's `locale` setting because passing it to the auth instance, which is made before the app's options, is not implemented.</gap> The auth endpoint `/unlink-account` refuses an account that Connections lists (`403`, `CONNECTION_UNLINK_REFUSED`): disconnect it there. Connecting again makes a new account with a new id: bind it in the workflow's `connections` and turn the workflow on again. Revoking at Google ends everything the account allowed the app, the sign-in and a linked mailbox included, and the dialog says so.
 
 A workflow names the account each of its connections uses in its definition's `connections`, by `<plugin>:<connection>` and the account's id, which the Connections section shows, as does `list_connections` [over MCP](mcp.md#workflows):