@flowdular/sdk 0.2.4 → 0.3.0

package/modules/auth/migrations/0029_reports_exports_access_scopes.down.sql

@@ -0,0 +1,22 @@
+-- Documentation only; Flowdular never executes a down script. Reversing 0029
+-- means taking the five scopes back from every owner membership and from the
+-- built-in owner role row. It cannot distinguish a grant this migration made
+-- from one a workspace made by assigning a role that names the scope. Nothing
+-- 0023, 0024, 0025 or 0027 granted is rewritten here, and no member membership
+-- and no member role row is touched, because this migration granted them none.
+ALTER TABLE auth_membership_scopes NO FORCE ROW LEVEL SECURITY;
+DELETE FROM auth_membership_scopes
+WHERE scope IN ('reports.workspace.read', 'exports.lists.read', 'exports.lists.manage', 'access.review.read', 'access.review.manage')
+  AND (account_id, tenant_id) IN (
+        SELECT account_id, tenant_id FROM auth_memberships WHERE role = 'owner');
+ALTER TABLE auth_membership_scopes FORCE ROW LEVEL SECURITY;
+ALTER TABLE auth_roles NO FORCE ROW LEVEL SECURITY;
+UPDATE auth_roles
+SET scopes_json = COALESCE(
+      (SELECT json_agg(entry.scope ORDER BY entry.position)::text
+         FROM json_array_elements_text(auth_roles.scopes_json::json)
+              WITH ORDINALITY AS entry(scope, position)
+        WHERE entry.scope NOT IN ('reports.workspace.read', 'exports.lists.read', 'exports.lists.manage', 'access.review.read', 'access.review.manage')),
+      '[]')
+WHERE builtin = 1 AND key = 'owner';
+ALTER TABLE auth_roles FORCE ROW LEVEL SECURITY;

package/modules/auth/migrations/0029_reports_exports_access_scopes.up.sql

@@ -0,0 +1,56 @@
+-- reports.core, exports.core and access.core declare five permissions between
+-- them, and owners hold every permission an enabled module declares. All three
+-- were already enabled when the owner defaults gained them, so auth sync-scopes
+-- does not reach an existing workspace: it grants a module's scopes when the
+-- module is enabled and to the workspaces that exist at that moment. The seed
+-- lists in acl/scopes.ts reach a workspace created from now on and no earlier
+-- one. This grants the five to every owner membership and appends them to the
+-- built-in owner role row.
+--
+-- Members receive none of them. D-REPORTS-AUDIENCE keeps the workspace report
+-- with owners because it composes spend, usage and volume across modules;
+-- D-OWNERS-ONLY keeps both access review permissions with owners because the
+-- review names every scope, token and provider of the workspace; and
+-- D-EXPORTS-PERMISSIONS states what starting an export and opening a file
+-- require of the live principal rather than granting a role anything, so the
+-- two export permissions stay owner defaults and a workspace that wants a
+-- member to export assigns a role carrying them.
+--
+-- Row security is forced on both tables, and a migration role that is not a
+-- superuser is subject to it like any other, so a plain statement would reach
+-- no row on a real deployment. The force flag is lifted for the owner and put
+-- back inside the same transaction; a role that does not own these tables fails
+-- here loudly instead of leaving the grants missing. Nothing else runs against
+-- them while the migration lock is held.
+ALTER TABLE auth_membership_scopes NO FORCE ROW LEVEL SECURITY;
+INSERT INTO auth_membership_scopes (account_id, tenant_id, scope)
+SELECT account_id, tenant_id, scope
+FROM auth_memberships
+CROSS JOIN unnest(ARRAY['reports.workspace.read', 'exports.lists.read', 'exports.lists.manage', 'access.review.read', 'access.review.manage']) AS granted(scope)
+WHERE auth_memberships.role = 'owner'
+ON CONFLICT DO NOTHING;
+ALTER TABLE auth_membership_scopes FORCE ROW LEVEL SECURITY;
+-- A role row grants too: assigning a role replaces the membership scopes with
+-- the list it carries, so a scope missing from the built-in owner row would be
+-- taken away again at the next assignment. The scopes already held keep their
+-- order and the missing ones are appended in the order acl/scopes.ts declares
+-- them, which is the order a freshly seeded workspace writes.
+ALTER TABLE auth_roles NO FORCE ROW LEVEL SECURITY;
+UPDATE auth_roles
+SET scopes_json = (
+      SELECT json_agg(entry.scope ORDER BY entry.origin, entry.position)::text
+        FROM (
+               SELECT 0 AS origin, held.position, held.scope
+                 FROM json_array_elements_text(auth_roles.scopes_json::json)
+                      WITH ORDINALITY AS held(scope, position)
+               UNION ALL
+               SELECT 1 AS origin, added.position, added.scope
+                 FROM unnest(ARRAY['reports.workspace.read', 'exports.lists.read', 'exports.lists.manage', 'access.review.read', 'access.review.manage'])
+                      WITH ORDINALITY AS added(scope, position)
+                WHERE added.scope NOT IN (
+                        SELECT existing.scope
+                          FROM json_array_elements_text(auth_roles.scopes_json::json) AS existing(scope))
+             ) AS entry
+    )
+WHERE builtin = 1 AND key = 'owner';
+ALTER TABLE auth_roles FORCE ROW LEVEL SECURITY;

package/modules/auth/migrations/0030_auth_membership_keyset_index.down.sql

@@ -0,0 +1,4 @@
+-- Documentation only; Flowdular never executes a down script. Reversing 0030
+-- means dropping the index, which costs the paged member read its range scan
+-- and nothing else: no row, no policy and no grant depends on it.
+DROP INDEX IF EXISTS auth_memberships_tenant_keyset_idx;

package/modules/auth/migrations/0030_auth_membership_keyset_index.up.sql

@@ -0,0 +1,10 @@
+-- The paged member read walks one workspace by keyset:
+-- WHERE tenant_id = $1 AND account_id > $2 ORDER BY account_id LIMIT $3. The
+-- primary key of auth_memberships is (account_id, tenant_id), which leads with
+-- the account, so that walk is a scan over every workspace's rows after the
+-- cursor with the workspace applied as a filter. This index leads with the
+-- workspace, which turns each page into an index range scan of exactly the
+-- rows it returns and makes the walk linear in the members it carries rather
+-- than in the deployment.
+CREATE INDEX IF NOT EXISTS auth_memberships_tenant_keyset_idx
+  ON auth_memberships (tenant_id, account_id);

package/modules/auth/migrations/0031_membership_scope_backfills_under_rls.down.sql

@@ -0,0 +1,4 @@
+-- Documentation only; Flowdular never executes a down script. This migration
+-- granted nothing 0019 to 0029 did not already intend, so reversing it means
+-- reversing those: their down scripts take the scopes back from the
+-- memberships and the built-in role rows. Nothing is rewritten here.

package/modules/auth/migrations/0031_membership_scope_backfills_under_rls.up.sql

@@ -0,0 +1,31 @@
+-- The scope backfills 0019, 0022, 0023, 0024, 0025, 0027 and 0029 grant the
+-- permissions a module declares to the memberships that existed when the
+-- module was enabled. Each lifted the force flag on auth_membership_scopes and
+-- on auth_roles, but selected the memberships from auth_memberships, which
+-- forces row security as well (0001). A migrator that is not a superuser is
+-- subject to that policy and holds no tenant setting, so on a PostgreSQL
+-- deployment every one of those selects matched nothing and no membership
+-- gained a scope; PGlite runs as a superuser and did not notice. The built-in
+-- role rows those migrations rewrote were read from auth_roles under its own
+-- lifted flag and are correct.
+--
+-- Applied migrations are immutable, so this repeats the seven membership
+-- grants with the force flag lifted on the source table as well, inside the
+-- same transaction, on the same conflict rule. A scope a workspace granted
+-- since, by assigning a role that names it, is left in place.
+ALTER TABLE auth_memberships NO FORCE ROW LEVEL SECURITY;
+ALTER TABLE auth_membership_scopes NO FORCE ROW LEVEL SECURITY;
+INSERT INTO auth_membership_scopes (account_id, tenant_id, scope)
+SELECT account_id, tenant_id, scope
+FROM auth_memberships
+CROSS JOIN unnest(ARRAY['auth.providers.read', 'auth.providers.manage', 'directory.tokens.read', 'directory.tokens.manage', 'directory.provisioning.read', 'audit.registry.read', 'audit.retention.manage', 'approvals.requests.read', 'approvals.requests.decide', 'approvals.requests.manage', 'documents.files.read', 'documents.files.manage', 'metering.usage.read', 'import.jobs.read', 'import.jobs.manage', 'search.records.read', 'connectors.instances.read', 'connectors.instances.manage', 'audit.holds.manage', 'workflows.definitions.read', 'workflows.definitions.manage', 'workflows.definitions.publish', 'workflows.runs.read', 'workflows.runs.execute', 'workflows.runs.cancel', 'automations.schedules.read', 'automations.schedules.manage', 'automations.triggers.read', 'automations.triggers.manage', 'profile.self.manage', 'reports.workspace.read', 'exports.lists.read', 'exports.lists.manage', 'access.review.read', 'access.review.manage']) AS granted(scope)
+WHERE auth_memberships.role = 'owner'
+ON CONFLICT DO NOTHING;
+INSERT INTO auth_membership_scopes (account_id, tenant_id, scope)
+SELECT account_id, tenant_id, scope
+FROM auth_memberships
+CROSS JOIN unnest(ARRAY['notifications.inbox.read', 'notifications.inbox.manage', 'notifications.webhooks.read', 'documents.files.read', 'documents.files.manage', 'search.records.read', 'connectors.instances.read', 'approvals.requests.read', 'approvals.requests.decide', 'profile.self.manage']) AS granted(scope)
+WHERE auth_memberships.role = 'member'
+ON CONFLICT DO NOTHING;
+ALTER TABLE auth_membership_scopes FORCE ROW LEVEL SECURITY;
+ALTER TABLE auth_memberships FORCE ROW LEVEL SECURITY;

package/modules/auth/migrations/0032_audit_actor_service.down.sql

@@ -0,0 +1,9 @@
+-- Documentation only; Flowdular never executes a down script. Reversing this
+-- means rewriting every service row the way 0014 recorded it before the check
+-- can narrow again:
+-- UPDATE auth_audit SET actor_kind = 'user', configured_by_json = NULL
+--   WHERE actor_kind = 'service';
+-- ALTER TABLE auth_audit DROP CONSTRAINT IF EXISTS auth_audit_actor_kind_check;
+-- ALTER TABLE auth_audit ADD CONSTRAINT auth_audit_actor_kind_check
+--   CHECK (actor_kind IN ('user', 'agent'));
+-- ALTER TABLE auth_audit DROP COLUMN IF EXISTS configured_by_json;

package/modules/auth/migrations/0032_audit_actor_service.up.sql

@@ -0,0 +1,10 @@
+-- The kernel actor model has three kinds: a user, an agent run and a service
+-- configured by a user. 0014 admitted the first two, so an operator command
+-- and an identity provider were recorded as users. This admits the service
+-- kind and stores the configuring user beside it, the way the record history
+-- tables do; null where the row is no service, or where the configuring user
+-- is not stored, as an identity provider's is not.
+ALTER TABLE auth_audit DROP CONSTRAINT IF EXISTS auth_audit_actor_kind_check;
+ALTER TABLE auth_audit ADD CONSTRAINT auth_audit_actor_kind_check
+  CHECK (actor_kind IN ('user', 'agent', 'service'));
+ALTER TABLE auth_audit ADD COLUMN IF NOT EXISTS configured_by_json TEXT NULL;

package/modules/auth/migrations/0033_auth_account_keyset_indexes.down.sql

@@ -0,0 +1,5 @@
+-- Documentation only; Flowdular never executes a down script. Reversing 0033
+-- drops the two keyset indexes. No row and no constraint depends on them, so
+-- the only consequence is that a sorted member page sorts the workspace again.
+DROP INDEX IF EXISTS auth_accounts_display_name_keyset_idx;
+DROP INDEX IF EXISTS auth_accounts_email_keyset_idx;

package/modules/auth/migrations/0033_auth_account_keyset_indexes.up.sql

@@ -0,0 +1,23 @@
+-- The sorted member listing pages one workspace by display name or by address:
+-- ORDER BY lower(a.display_name), a.id (or a.email_normalized, a.id) with a
+-- keyset predicate on the same pair and a LIMIT, over auth_memberships joined
+-- to auth_accounts for the workspace. Both sort columns live on auth_accounts,
+-- which carries no tenant column, so the (tenant_id, sort column, id) index a
+-- keyset page normally rests on cannot exist on one table. These indexes go
+-- where the sort expressions are. For a workspace that holds most of the
+-- deployment's accounts the planner walks the index in order, joins each
+-- account to its membership through the primary key (account_id, tenant_id)
+-- and stops at the LIMIT, so a page costs the rows it answers. For a small
+-- workspace it reads the membership rows through 0030's (tenant_id,
+-- account_id) index and sorts that workspace alone, which is bounded by the
+-- workspace and never by the deployment. Neither plan reads the deployment's
+-- accounts and sorts them.
+--
+-- 0028's prefix index over lower(display_name) carries text_pattern_ops,
+-- whose byte order is the ORDER BY order under the C collation only, so the
+-- sort needs its own index in the database collation. The address is already
+-- unique, and id follows it here so both keysets have the same shape.
+CREATE INDEX IF NOT EXISTS auth_accounts_display_name_keyset_idx
+  ON auth_accounts (lower(display_name), id);
+CREATE INDEX IF NOT EXISTS auth_accounts_email_keyset_idx
+  ON auth_accounts (email_normalized, id);

package/modules/auth/module.json

@@ -3,7 +3,7 @@
 	"schemaVersion": 1,
 	"id": "auth.core",
 	"package": "@flowdular/module-auth",
-	"version": "0.10.0",
+	"version": "0.13.10",
 	"profile": "full",
 	"capabilities": ["api", "database", "client", "translations", "cli"],
 	"platform": {
@@ -12,7 +12,7 @@
 	"dependencies": [
 		{
 			"id": "system.core",
-			"range": "0.5.0"
+			"range": "^0.7.0"
 		}
 	],
 	"tenancy": "required",
@@ -22,5 +22,5 @@
 		"catalog": "src/cli/commands.json",
 		"entry": "src/cli/index.ts"
 	},
-	"platformApi": "0.1.0"
+	"platformApi": "^0.1.0"
 }

package/modules/auth/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@flowdular/module-auth",
-	"version": "0.10.0",
+	"version": "0.13.10",
 	"type": "module",
 	"exports": {
 		".": "./src/index.ts",
@@ -25,6 +25,7 @@
 		"@flowdular/ui": "workspace:*",
 		"@octanejs/app-core": "0.0.47",
 		"@octanejs/seo": "0.0.38",
+		"nodemailer": "10.0.3",
 		"octane": "0.1.51",
 		"pg": "8.23.0",
 		"segment-state": "0.2.1",