@7365admin1/core 3.47.1-staging.125 → 3.47.1-staging.127

package/.changeset/console-audit-client-status.md

@@ -0,0 +1,20 @@
+---
+"@7365admin1/core": patch
+---
+
+Suspending or reactivating a client is now recorded in the console audit trail.
+
+The audit trail (`console-audit`) already carried `client.suspended` and
+`client.reactivated` with their labels and their allow-listed fields, but nothing
+wrote them: `organization.controller.ts` was deliberately left unhooked while the
+suspend work was still an open PR. Now that it has landed, `updateStatus` records
+one row per status change - the direction taken from the status that was actually
+written, the actor taken from the owner guard's return value and never from the
+request body, and only `status` kept from the change.
+
+The row is written after the status has changed and before the reply, the same
+order as every other recorded action, so a row can never describe something that
+did not happen. `recordConsoleAction` still swallows its own failures, so a lost
+audit row cannot undo a suspension.
+
+`client.created` stays unconnected on purpose and its reminder is unchanged.

package/.changeset/members-paging-skip.md

@@ -0,0 +1,18 @@
+---
+"@7365admin1/core": patch
+---
+
+Fix GET /api/members returning the same page over and over
+
+`member.repo.ts` `getAll` built its aggregate with `{ $limit: limit }` and no
+`$skip`. `paginate()` only *labels* the range — it returns `items` untouched and
+computes `pageRange` arithmetically — so the server answered page 2 with page
+1's rows under an "11-20 of 42" heading. Every Members screen in every app was
+affected, not one screen.
+
+`{ $skip: page * limit }` is added ahead of the limit, matching the two
+`getOrgs*` reads in the same file that were already correct. `page` is
+zero-based by then, and the cache key already varies by page, so no cache
+change is needed.
+
+The response shape is unchanged: `{ items, pages, pageRange }`.