@7365admin1/core 3.64.3-staging.284 → 3.64.3-staging.286

package/.changeset/hid-profile-qr-backend.md

@@ -0,0 +1,31 @@
+---
+"@7365admin1/core": minor
+---
+
+Let a signed-in member hold their own HID QR code.
+
+`GET`, `POST` and `DELETE /readers/:readerId/profile-qr` read, issue and revoke
+the caller's own QR credential on one reader. The caller comes from the session,
+so there is no user id in the path to point at somebody else, and each handler
+calls `authorizeReader` for itself rather than trusting the router - the site is
+re-resolved from the stored reader record.
+
+The credential is the visitor mechanism: an alphanumeric value in the reader's
+`qrcodes` table, with the reader put into the QR-readable configuration first.
+Unlike a visitor pass it carries no validity window, matching the member's
+facial enrollment, which is standing until removed. Issuing replaces any earlier
+code for that member on that reader, and the replacement is written and verified
+before the old one is removed.
+
+It creates no access rule, deliberately. `setProfileFacial` beside it does not
+either: a member's door access comes from the HID permissions screen, and
+minting a rule here would mean anyone who can press Generate admits themselves.
+The read reports whether that screen admits them, resolved through
+`resolvePermissionUserBindings` - the same resolver that writes the rules onto
+the device - so the answer is the one the reader will actually be asked.
+
+Two settings are now readable that were already writable: the QR identification
+and legacy-mode flags `configureVisitorQrReader` sets on every issue, plus
+`access_rule_time_zones` alongside its two sibling link tables. Whether a reader
+was set up to accept a QR, and whether an access rule had a schedule, were
+invisible to every screen and every diagnosis.

package/.changeset/hid-reader-user-search.md

@@ -0,0 +1,22 @@
+---
+"@7365admin1/core": patch
+---
+
+Make the search on the HID reader user roster work.
+
+`listReaderUsers` asked the device to filter. Amico's `where` takes a value or a
+list of values per column and has no operator form, so the substring clause it
+sent for a text term, `{name: {LIKE: "%x%"}}`, was answered
+`400 Invalid value (string or array expected)`. Every search by name threw, and
+the screen showed "Unable to load HID users from reader" with an empty table.
+
+A numeric term took a different branch that matched the HID user id exactly.
+That did not fail, it answered wrongly: searching a registration number like
+`000004` resolved to `id = 4` and returned a different person.
+
+Rows are already pulled in one page and filtered here for `userType`, so the
+search now joins that filter as a case-insensitive substring over name, id and
+registration - the same three fields, and the same "contains" semantics, the
+identities search uses. Verified against a live reader: a name matches
+partially and case-insensitively, a registration number returns its own user,
+a full UID still works, and no match returns an empty page rather than an error.

package/dist/index.d.ts

@@ -4851,7 +4851,6 @@ declare function MPerson(value: TPerson): {
     end: string | Date | undefined;
     type: "resident" | "walk-in" | "drop-off" | "contractor" | "delivery" | "pick-up" | "guest" | "tenant" | undefined;
     email: string | undefined;
-    password: string;
     status: string;
     nric: string | undefined;
     remarks: string | undefined;
@@ -12643,6 +12642,48 @@ declare function useHidAmicoService(): {
         facialEnrolled: boolean;
         facialEnrolledAt: string;
     }>;
+    getProfileQr: (readerId: string, userId: string) => Promise<{
+        readerId: string;
+        userId: string;
+        memberId: string;
+        hidUserId: string;
+        registration: string;
+        readerName: string;
+        portalName: string;
+        qrEnabled: boolean;
+        issued: boolean;
+        qrValue: string;
+        issuedAt: string;
+        assigned: boolean | null;
+    }>;
+    issueProfileQr: (readerId: string, userId: string) => Promise<{
+        readerId: string;
+        userId: string;
+        memberId: string;
+        hidUserId: string;
+        registration: string;
+        readerName: string;
+        portalName: string;
+        qrEnabled: boolean;
+        issued: boolean;
+        qrValue: string;
+        issuedAt: string;
+        assigned: boolean | null;
+    }>;
+    deleteProfileQr: (readerId: string, userId: string) => Promise<{
+        readerId: string;
+        userId: string;
+        memberId: string;
+        hidUserId: string;
+        registration: string;
+        readerName: string;
+        portalName: string;
+        qrEnabled: boolean;
+        issued: boolean;
+        qrValue: string;
+        issuedAt: string;
+        assigned: boolean | null;
+    }>;
     setProfileFacial: (readerId: string, userId: string, image: Buffer, options?: {
         timestamp?: number;
         match?: boolean;
@@ -12892,6 +12933,9 @@ declare function useHidAmicoController(): {
     revokeVisitorQr: (req: Request, res: Response, next: NextFunction) => Promise<void>;
     getProfileFacial: (req: Request, res: Response, next: NextFunction) => Promise<void>;
     setProfileFacial: (req: Request, res: Response, next: NextFunction) => Promise<void>;
+    getProfileQr: (req: Request, res: Response, next: NextFunction) => Promise<void>;
+    issueProfileQr: (req: Request, res: Response, next: NextFunction) => Promise<void>;
+    deleteProfileQr: (req: Request, res: Response, next: NextFunction) => Promise<void>;
     setVisitorImage: (req: Request, res: Response, next: NextFunction) => Promise<void>;
     deleteVisitorImage: (req: Request, res: Response, next: NextFunction) => Promise<void>;
     getIntercomStatus: (req: Request, res: Response, next: NextFunction) => Promise<void>;