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

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 }`.

package/dist/index.js

@@ -9976,6 +9976,11 @@ function useMemberRepo() {
       const items = await collection.aggregate([
         { $match: query2 },
         { $sort: { _id: -1 } },
+        // `paginate()` only LABELS the range ("11-20 of 42"); it does not
+        // slice. Without this $skip every page returned page 1's rows under
+        // a later page's heading. `page` is already zero-based above, and
+        // this is the same $skip/$limit pair the two getOrgs* reads use.
+        { $skip: page * limit },
         { $limit: limit },
         {
           $lookup: {