@7365admin1/core 3.42.0 → 3.42.2

package/CHANGELOG.md

@@ -1,5 +1,92 @@
 # @iservice365/core
 
+## 3.42.2
+
+### Patch Changes
+
+- 7078e6f: Make ANPR "Connection Lost" alerts readable, paced, and self-clearing
+
+  The alert an operator actually saw was `Camera [Seventh Condominium-both]
+Connection Lost. Retrying in 10 seconds. Check the camera if this issue
+persists, Or set the camera to Inactive to stop this notification.` Three
+  things were wrong with it:
+
+  - `[<site>-<direction>]` glued a database enum onto the site name and showed it
+    as if it were a place. "both" is the camera's direction setting, not
+    somewhere you can go. The camera is now named the way the setup form names
+    it — by its own name where it has one, otherwise "the entry and exit ANPR
+    camera at <site>".
+  - It told the operator to set the camera Inactive to stop the alert. On a
+    camera driving a barrier, that is advice to switch off plate reading in order
+    to silence the warning that plate reading is off. Removed.
+  - It was emitted on every reconnect attempt — once every 10 seconds with no
+    ceiling — into a snackbar with a 20-second timeout, so a camera that stayed
+    down held a red toast on screen permanently, on every page. One hour of
+    downtime produced 360 alerts.
+
+  Alerts are now paced: the first failure, then roughly 1, 5 and 15 minutes, then
+  every 15 minutes for as long as it stays down. When the camera answers again,
+  an operator who was told it was down is told it is back; if they were never
+  alerted, nothing is sent.
+
+  **The reconnect loop itself is unchanged and still retries every 10 seconds** —
+  only the alerting is paced. A barrier camera has to come back the moment it can.
+
+  Recovery and fault alerts also carry `event` and `camera` fields so a client can
+  group or clear alerts per camera rather than matching on message text. Existing
+  clients ignore them and render `message` as they always have.
+
+- a5d2b88: Stop logging camera and mailer credentials
+
+  Six places wrote a secret or a resident's details to stdout on an ordinary code
+  path. `getTrafficJunction` dumped the whole `TSiteCamera` object — including the
+  camera's `username` and plaintext `password` — on every reconnect, and
+  `addPlateNumber` logged its argument, which carries the same password plus a
+  resident's plate number and owner name. `checkOutBySiteAndPlate` logged the
+  matched visitor transaction. `siteCameraRepo.updateById` logged the re-read
+  camera document, and `vehicleService.add` logged the whole array of a site's
+  cameras, both with credentials in them. `sendEmail` printed `MAILER_PASSWORD`
+  itself on every message sent.
+
+  All now log identifiers, counts and outcomes only, through the module's logger
+  rather than `console.log`; the mailer line is removed outright because it
+  carried nothing but the secret.
+
+- b472360: Fix three Dahua HTTP API defects found by checking our integration against the
+  vendor specification (V3.37):
+
+  - The ANPR reconnect loop retried authentication ten times at one-second
+    intervals. The device locks the account for 1800 seconds after three failed
+    logins in thirty, so our own recovery could take ANPR down at a site for half
+    an hour. Authentication now backs off well past the device's counting window,
+    and a network fault is distinguished from an authentication failure.
+  - 401 and 403 were handled backwards. Per spec §3.4, 401 is the digest
+    challenge (retry) and 403 is a credentials rejection (stop). We treated 403 as
+    an account lock and killed the listener, and counted 401s toward a "wrong
+    password" warning.
+  - `updatePlateNumber`, `bulkInsertPlateNumber` and `removePlateNumber`
+    interpolated values into the CGI query string unencoded, against the spec's
+    stated RFC 3986 requirement. A plate or owner name containing a space or "&"
+    broke the request or appended extra parameters to it.
+
+## 3.42.1
+
+### Patch Changes
+
+- 87c073f: Make the "an invitation is already waiting" check actually find the invitation
+
+  The duplicate-invitation guard added with the existing-provider invite fix never
+  fired. Invitations are written with `metadata.siteId` as an ObjectId, but the
+  lookup searched for the site id as the plain string it arrived as on the request,
+  and MongoDB does not treat the two as equal. The query therefore always came back
+  empty: a property manager could send the same service provider a second, third
+  and fourth invitation for the same site while the first was still valid, and each
+  one produced another email and another pending row for them to chase.
+
+  The lookup now matches either form, so older records that hold the string are
+  still found. Nothing else changes: the refusal message and the status code are
+  the ones already shipped.
+
 ## 3.42.0
 
 ### Minor Changes

package/dist/index.d.ts

@@ -1613,7 +1613,7 @@ declare function useServiceProviderRepo(): {
         siteId?: string | ObjectId | undefined;
         orgId?: string | ObjectId | undefined;
         serviceProviderOrgId?: string | ObjectId | undefined;
-    }) => Promise<{} | null>;
+    }) => Promise<{}>;
     updateStatusById: (_id: string | ObjectId, status: string) => Promise<mongodb.UpdateResult<bson.Document>>;
 };
 
@@ -1621,6 +1621,7 @@ declare function useServiceProviderController(): {
     createServiceProvider: (req: Request, res: Response, next: NextFunction) => Promise<void>;
     getServiceProviders: (req: Request, res: Response, next: NextFunction) => Promise<void>;
     getByProviderOrg: (req: Request, res: Response, next: NextFunction) => Promise<void>;
+    getByEmail: (req: Request, res: Response, next: NextFunction) => Promise<void>;
     getServiceProviderNames: (req: Request, res: Response, next: NextFunction) => Promise<void>;
     getServiceProviderTypes: (req: Request, res: Response, next: NextFunction) => Promise<void>;
     getServiceProviderById: (req: Request, res: Response, next: NextFunction) => Promise<void>;
@@ -2605,6 +2606,7 @@ declare function useCustomerSiteRepo(): {
         name: string;
         org: string | ObjectId;
     }) => Promise<TCustomerSite[]>;
+    countActiveByOrgAndSite: (org: string | ObjectId, site: string | ObjectId) => Promise<number>;
     getBySiteAsServiceProvider: (site: string | ObjectId) => Promise<{} | undefined>;
     getById: (id: string | ObjectId) => Promise<mongodb.WithId<bson.Document>>;
     updateCustomerSiteById: (id: string | ObjectId, payload: Partial<TCustomerSite>, session?: ClientSession) => Promise<mongodb.WithId<bson.Document>>;
@@ -2613,7 +2615,7 @@ declare function useCustomerSiteRepo(): {
 
 declare function useCustomerSiteService(): {
     add: (value: TCustomerSite) => Promise<string>;
-    addViaInvite: (invite: string) => Promise<string>;
+    addViaInvite: (invite: string) => Promise<"This site is already on your list." | "Invite accepted, successfully added site.">;
     updateCusSiteById: (customerSiteId: string, payload: Partial<TCustomerSite>) => Promise<mongodb.WithId<bson.Document>>;
 };
 
@@ -7079,6 +7081,7 @@ declare function useVerificationRepoV2(): {
     updateStatusById: (_id: string | ObjectId, status: string, session?: ClientSession) => Promise<mongodb.UpdateResult<bson.Document>>;
     countPendingOrgInvites: (orgId: string | ObjectId) => Promise<number>;
     getPendingVerificationByEmail: (email: string) => Promise<TVerificationV2 | null>;
+    getPendingServiceProviderInvite: (email: string, siteId: string) => Promise<TVerificationV2 | null>;
     updateVerificationCodeById: (_id: string | ObjectId, verificationCode: string, expireAt: string, session?: ClientSession) => Promise<mongodb.UpdateResult<bson.Document>>;
     completePendingInvites: ({ email, orgId, siteId, app, session, }: {
         email: string;