@7365admin1/core 3.52.3-staging.243 → 3.52.3-staging.245
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.changeset/bulletin-board-create-rollback.md +16 -0
- package/.changeset/visitor-invite-type-default.md +12 -0
- package/dist/index.d.ts +1 -1
- package/dist/index.js +2588 -2647
- package/dist/index.js.map +1 -1
- package/dist/index.mjs +2588 -2647
- package/dist/index.mjs.map +1 -1
- package/package.json +2 -2
- package/test/bulletin-service-apps.test.mjs +87 -0
- package/test/visitor-invite-schema.test.mjs +77 -0
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
---
|
|
2
|
+
"@7365admin1/core": patch
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
Stop silently discarding a bulletin whose recipients include a service app with no users.
|
|
6
|
+
|
|
7
|
+
`POST /api/bulletin-boards` inserts the announcement inside a Mongo transaction and then
|
|
8
|
+
notifies each recipient group. The five per-service-app blocks each carried a bare `return;` for
|
|
9
|
+
"this site has no id" and "this app has no registered users". Those returns left the enclosing
|
|
10
|
+
`try` before `commitTransaction()`, so the session was ended with the transaction still open and
|
|
11
|
+
the announcement was rolled back — while the controller still answered `201 Created`. Selecting
|
|
12
|
+
Cleaning, M&E, Pest Control, Landscaping or Pool Maintenance at an estate with no users of that
|
|
13
|
+
app therefore made the announcement vanish with no error anywhere.
|
|
14
|
+
|
|
15
|
+
The five blocks are now one loop over a recipient-to-app-slug map, and a missing push audience
|
|
16
|
+
skips one notification instead of ending the request. Same apps, same order, same payloads.
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
---
|
|
2
|
+
"@7365admin1/core": patch
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
Default the visitor-invite `type` to `guest` so already-installed resident app builds can invite again.
|
|
6
|
+
|
|
7
|
+
`POST /api/visitor-transactions/invite/:inviterId` made `type` a required field when the
|
|
8
|
+
contractor invite was added. Every resident app build already in the stores sends no `type`, so
|
|
9
|
+
those users get a 400 — `"type" is required` — on a form that has no Type field. `type` now
|
|
10
|
+
defaults to `guest`, which is exactly what the endpoint did before the contractor work.
|
|
11
|
+
Contractor invites are unchanged: `contractorType` is still required when `type` is `contractor`,
|
|
12
|
+
and an unrecognised `type` is still refused.
|
package/dist/index.d.ts
CHANGED
|
@@ -6487,7 +6487,7 @@ declare function useBulletinBoardRepo(): {
|
|
|
6487
6487
|
};
|
|
6488
6488
|
|
|
6489
6489
|
declare function useBulletinBoardService(): {
|
|
6490
|
-
add: (value: TBulletinBoard) => Promise<
|
|
6490
|
+
add: (value: TBulletinBoard) => Promise<string>;
|
|
6491
6491
|
updateBulletinBoardById: (id: string | ObjectId, value: Partial<TBulletinBoard>) => Promise<string>;
|
|
6492
6492
|
processExpiredBulletinBoards: () => Promise<void>;
|
|
6493
6493
|
processUpcomingBulletinBoards: () => Promise<void>;
|