@rytass/bpm-core-nestjs-module 0.1.6 → 0.1.8

package/CHANGELOG.md

@@ -9,6 +9,66 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 Releases are managed by [`nx release`](https://nx.dev/recipes/nx-release) with
 Conventional Commits — see `nx.json` for the release config.
 
+## 0.1.8 — 2026-05-28
+
+### Documentation
+
+- **Casbin example BPMAuthContext shape corrected.** The 0.1.6/0.1.7
+  example returned `{ memberId, email, name, roles, permissions,
+  metadata }` — the actual `BPMAuthContext` interface is
+  `{ memberId, roles, permissions, metadata }` (no `email`, no `name`).
+  Example now stashes display data inside `metadata`, with an explicit
+  callout that name/email reach resolvers through `BPMMemberResolver`
+  instead.
+- **`createPosition` / `updatePosition` / `createMembership` /
+  `updateMembership` / `createManagerResolution` exact signatures
+  added** to the org Worked Example section. The 0.1.7 README only
+  listed function names; downstream developers were guessing input
+  shapes (e.g. mandatory `level` and `metadataJson` on positions).
+- **`metadataJson` write-only clarification.** The "host-FK stash"
+  rule was misleading: `metadataJson` is accepted by every mutation
+  but the records returned by `readOrganizationDashboard` do NOT
+  surface a `metadata` field. Updated to "always reconcile by `code`;
+  treat `metadataJson` as audit/debugging breadcrumb, not a live FK
+  pointer."
+
+### Why a patch
+
+Documentation only. No source change.
+
+## 0.1.7 — 2026-05-28
+
+### Documentation
+
+- **README "Bring-your-own-host-auth" recipe** added under Auth
+  Context. Documents the `ApiMember` JSON shape, the expected status
+  codes for `/auth/login`, `/auth/me`, `/auth/logout`, and two
+  integration patterns: (A) extend the host API with `/auth/*`
+  controllers that emit `ApiMember` (recommended for member-base
+  hosts), or (B) run a thin wrapper host on a separate subdomain.
+- **README "Sharing a Postgres cluster with the host"** added under
+  Database Setup. Compares same-schema / separate-schema / separate-DB
+  trade-offs, recommends separate-schema, clarifies Vault path
+  isolation between host and BPM.
+- **`commitOrgUnitTreeDraft` signature corrected** in the Worked
+  Example listing — previously `{ baseUpdatedAt, draft }` (incorrect),
+  now `{ moves: { id, parentId, baseUpdatedAt }[] }` matching the
+  actual export.
+- **`OrgUnitType` literal case corrected** in the README's example
+  comment — previously `'COMPANY' | 'DIVISION' | ...`, now `'company'
+  | 'division' | ...`. (See `@rytass/bpm-core-shared@0.1.7` for the
+  actual TS type change.)
+- **"Positions are intentionally not deletable" note** added to the
+  Organization mirror pattern. Explains why no `deletePosition`
+  mutation exists and how to retire a position safely.
+- **README "Package Status" current-version line refreshed** to
+  `0.1.7`.
+
+### Why a patch
+
+Documentation-only. No public API change beyond what
+`@rytass/bpm-core-shared@0.1.7` ships.
+
 ## 0.1.6 — 2026-05-28
 
 ### Added

package/README.md

@@ -14,7 +14,7 @@ directory integration, storage adapters, and deployment.
 
 ## Package Status
 
-Current version: `0.0.1`
+Current version: `0.1.7`
 
 The package is intended for NestJS backend hosts. It does not include the
 Next.js backoffice UI and does not provide a production auth system by itself.
@@ -198,6 +198,104 @@ class HostResolver {
 }
 ```
 
+### Bring-your-own-host-auth (for hosts that already have auth)
+
+The BPM React `<AuthProvider>` calls `POST /auth/login`, `GET /auth/me`,
+and `POST /auth/logout` on the BPM API host and expects responses that
+match the `ApiMember` shape (exported from `@rytass/bpm-core-client`):
+
+```ts
+interface ApiMember {
+  readonly memberId: string;
+  readonly email: string;
+  readonly name: string;
+  readonly roles: readonly string[];
+  readonly permissions: readonly string[];
+  readonly expiresAt: string; // ISO 8601
+}
+```
+
+Status-code contract:
+
+| Endpoint              | Success     | Failure                             |
+| --------------------- | ----------- | ----------------------------------- |
+| `POST /auth/login`    | `200` + `ApiMember` JSON      | `401` (bad credentials) / `400` (validation) |
+| `GET /auth/me`        | `200` + `ApiMember` JSON      | `401` (no session — React client treats as anonymous, not error) |
+| `POST /auth/logout`   | `204` (or `200` empty)        | `401` ignored |
+
+Session lifetime is owned by the host. The React `<AuthProvider>`
+relies on `credentials: 'include'` plus an HTTP-only cookie issued by
+the host on successful login — BPM does **not** issue cookies itself.
+
+Hosts that already have their own JWT / cookie auth have two integration
+patterns:
+
+#### Pattern A — Extend the host API surface
+
+Add `/auth/login`, `/auth/me`, `/auth/logout` controllers to your
+existing NestJS host. Internally those endpoints call the host's
+existing auth service (e.g. `MemberBaseService.login()`) and emit the
+`ApiMember` shape. This is the simplest integration when BPM and the
+host run on the same origin. Example for a member-base host:
+
+```ts
+@Controller('auth')
+export class HostAuthController {
+  constructor(private readonly memberBase: MemberBaseService) {}
+
+  @Post('login')
+  async login(@Body() input: LoginInput, @Res({ passthrough: true }) res: Response): Promise<ApiMember> {
+    const { member, accessToken, refreshToken } = await this.memberBase.login(input);
+    // Set the host's existing HTTP-only cookies; the React client will
+    // forward them on subsequent /auth/me and /graphql calls.
+    res.cookie('access_token', accessToken, { httpOnly: true, sameSite: 'lax' });
+    res.cookie('refresh_token', refreshToken, { httpOnly: true, sameSite: 'lax' });
+    return projectMemberToApiMember(member);
+  }
+
+  @Get('me')
+  async me(@Req() req: Request): Promise<ApiMember> {
+    const member = await this.memberBase.resolveCurrentMember(req); // throws 401 if no cookie
+    return projectMemberToApiMember(member);
+  }
+
+  @Post('logout')
+  @HttpCode(204)
+  logout(@Res({ passthrough: true }) res: Response): void {
+    res.clearCookie('access_token');
+    res.clearCookie('refresh_token');
+  }
+}
+```
+
+The `projectMemberToApiMember` helper is host-specific — map your own
+member shape to BPM's expectations, project Casbin roles into the BPM
+role-literal strings (see "Mapping from a host RBAC system" below),
+and compute `expiresAt` from the token TTL.
+
+#### Pattern B — Run BPM on a separate auth host
+
+When BPM lives on its own subdomain (e.g. `bpm.example.com`) separate
+from the main app at `app.example.com`, you can run a thin wrapper
+host that **only** owns the `/auth/*` endpoints and a session cookie
+scoped to `*.example.com`. The BPM React client points at this
+subdomain via `NEXT_PUBLIC_API_URL` / `NEXT_PUBLIC_API_AUTH_URL`
+(or `configureBPMClient` for server-side). The wrapper host
+internally calls back to the main app to verify the user.
+
+This pattern is heavier (cross-origin cookies, CORS) but lets the main
+app stay completely decoupled from BPM's auth surface. Use it only
+when a same-origin deployment is impossible.
+
+#### Cross-host auth precedence
+
+If the consumer wants the React client to skip the BPM auth entirely
+and rely on the host's existing session check at the Next.js layer,
+the simplest path is to **not mount `<AuthProvider>` from
+`@rytass/bpm-core-react`** and instead implement a host-side
+`useAuth()` shim that returns the host's session. This is rare — most
+consumers find Pattern A simpler.
+
 ## Role and Permission Contract
 
 BPM guards inspect `BPMAuthContext.roles` and `BPMAuthContext.permissions` with
@@ -255,16 +353,23 @@ export class BPMAuthContextFactory {
 
     return {
       memberId: member.id,
-      email: member.email,
-      name: member.name,
       roles: bpmRoles,
       permissions: [], // Host can also use `bpm:*` style permissions if preferred.
-      metadata: {},
+      // The BPMAuthContext shape does NOT include name/email — those are
+      // surfaced through BPMMemberResolver instead. If you want them
+      // available to downstream resolvers without an extra resolver call,
+      // stash them in `metadata` (BPM passes it through unchanged).
+      metadata: { name: member.name, email: member.email },
     };
   }
 }
 ```
 
+> **`BPMAuthContext` shape**: `{ memberId, roles, permissions, metadata }`
+> — exactly four fields. The host's `name` / `email` are not part of the
+> contract; resolvers call `BPMMemberResolver.resolve(memberId)` when
+> they need display data.
+
 > The host owns the mapping table. Keep it in one place (a constant
 > module or a database table) so adding a new BPM tier in a future
 > BPMCore release becomes a one-line addition.
@@ -384,14 +489,26 @@ and observable:
    uniqueness; use your host's stable identifier here (e.g. an LDAP DN
    slug or a internal ERP code). On a re-sync, look up existing entities
    by `code` before deciding INSERT vs UPDATE.
-2. **`metadata` is the host-FK stash.** Both `OrgUnit` and `Membership`
-   carry an opaque `metadata` JSON object that BPM never introspects.
-   Store your host's primary key here (e.g. `{ shuttleOrgUnitId: 12345 }`)
-   so you can chase the back-pointer when reconciling.
-3. **Soft delete via `deleteOrgUnit` / `deleteMembership`.** Deletes set
+2. **`metadataJson` is write-only.** The mutations
+   (`createOrgUnit`/`updateOrgUnit`/`createPosition`/`updatePosition`)
+   accept a `metadataJson` string that BPM stores verbatim. **However**,
+   `OrgUnitRecord` and `PositionRecord` returned by
+   `readOrganizationDashboard` do NOT include the metadata field —
+   it's intentionally hidden so the JSON blob doesn't bloat every
+   pagination payload. **For reconciliation, always key on `code`**
+   (which IS returned). Treat `metadataJson` as a debugging/audit
+   stash, not a live FK pointer.
+3. **Soft delete via `deleteOrgUnit` / `deleteMembership` / `deleteManagerResolution`.** Deletes set
    `deletedAt` rather than removing rows. BPM's query layer hides
    soft-deleted rows automatically; reading `orgUnitCount()` will report
    the live count.
+4. **Positions are intentionally not deletable.** There is no
+   `deletePosition` mutation — positions are part of the historical
+   record (every signed approval task references the assignee's position
+   at sign time, so deleting a position would lose audit data). Retire a
+   position by removing all active memberships referencing it; the
+   position itself stays. Use `updatePosition({ id, name: 'retired-' + oldName, ... })`
+   if you want a UI hint that a position is no longer in use.
 
 ### Worked example: idempotent sync
 
@@ -405,8 +522,12 @@ input shapes — no `{id, input: {...}}` wrapping):
 - `createOrgUnit({ code, name, type, parentId, metadataJson })`
 - `updateOrgUnit({ id, code, name, type, parentId, metadataJson })`
 - `deleteOrgUnit(id)` (soft-delete)
-- `commitOrgUnitTreeDraft({ baseUpdatedAt, draft })` (transactional batch moves)
-- `createPosition` / `updatePosition` (key on `code`)
+- `commitOrgUnitTreeDraft({ moves: { id, parentId, baseUpdatedAt }[] })` (transactional batch moves — each entry's `baseUpdatedAt` is the row's last-known `updatedAt`, used by BPM for optimistic-locking conflict detection)
+- `createPosition({ code, name, level, metadataJson })` — `level` (1+) controls hierarchy weight (higher = more senior, used by manager-resolution priority sort); `metadataJson` is required (pass `'{}'` if unused)
+- `updatePosition({ id, code, name, level, metadataJson })` — every field except `id` is `T | null`; pass `null` to leave a field unchanged
+- `createMembership({ memberId, orgUnitId, positionId, isPrimary, effectiveFrom, effectiveTo })` — `positionId` and `effectiveTo` accept `null`; `effectiveFrom` is an ISO timestamp string. Uniqueness key is `(memberId, orgUnitId, positionId)`
+- `updateMembership({ id, orgUnitId, positionId, isPrimary, effectiveFrom, effectiveTo })` — every field except `id` is `T | null`
+- `createManagerResolution({ scopeType, scopeId, managerMemberId, priority, effectiveFrom, effectiveTo })` — `scopeType` is `'MEMBER' | 'ORG_UNIT' | 'POSITION'`; `priority` orders the resolver chain (lower number = checked first)
 - `createMembership` / `updateMembership` (unique by `(memberId, orgUnitId, positionId)`)
 - `createManagerResolution` / `updateManagerResolution`
 
@@ -423,7 +544,7 @@ interface HostOrgUnit {
   readonly hostId: string;          // e.g. ERP primary key — your host-FK
   readonly code: string;            // stable across sync runs
   readonly name: string;
-  readonly type: OrgUnitType;       // 'COMPANY' | 'DIVISION' | 'DEPARTMENT' | 'TEAM'
+  readonly type: OrgUnitType;       // 'company' | 'division' | 'department' | 'team'
   readonly parentCode: string | null;
 }
 
@@ -653,6 +774,32 @@ Required environment variables for direct Vault loading:
 | `VAULT_PASSWORD` | Vault userpass password.            |
 | `VAULT_PATH`     | Vault KV path, defaults to develop. |
 
+### Sharing a Postgres cluster with the host
+
+Hosts that already run their own Postgres (and their own Vault path,
+e.g. `shuttle/develop`) have three options for where BPM's 22 tables
+live. Pick the one that matches your operational model:
+
+| Option | When to use | Trade-off |
+|---|---|---|
+| **Same database, same schema (`public`)** | Tiny prototypes, monorepo dev | Table-name collision risk — BPM owns `org_units`, `positions`, etc., common names. Audit your host's tables before choosing. |
+| **Same database, separate schema** (recommended) | Most production hosts | Clean isolation; pg_dump per-schema; one connection pool. Set `DB_SCHEMA=bpm_core` in BPM's Vault path. Host stays on its own schema (typically `public`). |
+| **Separate database** | Hard multi-tenant or compliance boundary | Two pools; cross-schema joins impossible (BPM doesn't need them); migration runners stay completely independent. |
+
+For option B (separate schema), the host's own TypeORM `forRoot()` and
+BPM's `buildTypeOrmModuleOptions` create **two distinct connections**
+to the same Postgres cluster with different `schema:` settings — that
+is the cleanest separation Nest's TypeORM module supports.
+
+Vault paths can be split independently: keep `shuttle/develop` for the
+host and create `bpm_core/develop` for BPM secrets. BPM's helper reads
+its own path; the host's auth module reads its own. They do not
+interfere.
+
+> **Schema migrations** are per-schema. Run BPM's migrations against
+> the schema named in `DB_SCHEMA`; the host's migrations stay on its
+> own schema. There is no cross-schema migration coordination.
+
 ## Migrations
 
 This package ships TypeORM migrations under `src/lib/migrations`.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rytass/bpm-core-nestjs-module",
-  "version": "0.1.6",
+  "version": "0.1.8",
   "description": "Embeddable NestJS BPM approval workflow module: workflow engine, approval templates, forms, organization/member contracts, attachments, signatures, notifications, delegation, and TypeORM migrations.",
   "keywords": [
     "bpm",
@@ -141,7 +141,7 @@
     "@nestjs/core": "^11.0.0",
     "@nestjs/graphql": "^13.4.0",
     "@nestjs/typeorm": "^11.0.1",
-    "@rytass/bpm-core-shared": "^0.1.6",
+    "@rytass/bpm-core-shared": "^0.1.8",
     "@rytass/secret-adapter-vault-nestjs": "^0.4.5 || ^0.5.0",
     "express": "^4.0.0 || ^5.0.0",
     "graphql": "^16.0.0",