@7365admin1/layer-common 4.97.1-staging.500 → 4.97.1-staging.502

package/utils/hid-permission-assignments.ts

@@ -142,11 +142,20 @@ export function applySelection(
 
 /** Per-category totals for the dialog header, counted over the whole reader. */
 export function countByCategory(state: HidAssignmentState): Record<THidPermissionCategory, number> {
-  const counts = { resident: 0, property_management: 0, service_provider: 0 } as Record<
-    THidPermissionCategory,
-    number
-  >;
-  for (const value of state.values()) counts[value.category] += 1;
+  /*
+   * Every category seeded at zero, and the increment guarded.
+   * `counts[category] += 1` on a key this object does not hold yields NaN, so a
+   * category added to the union but missed here would print "NaN" beside a tab
+   * rather than a number. That is exactly what happened when
+   * `service_provider_member` was added.
+   */
+  const counts = HID_PERMISSION_CATEGORIES.reduce(
+    (seeded, category) => ({ ...seeded, [category]: 0 }),
+    {} as Record<THidPermissionCategory, number>,
+  );
+  for (const value of state.values()) {
+    counts[value.category] = (counts[value.category] ?? 0) + 1;
+  }
   return counts;
 }
 
@@ -196,3 +205,55 @@ export function readCandidatePage(response: unknown): {
     pageRange,
   };
 }
+
+/* ── THE SUBJECT AN IDENTITY NAMES ─────────────────────────────────────── */
+
+/**
+ * WHICH GRANT AN ENROLLED PERSON'S ACCESS IS FILED UNDER.
+ *
+ * Mirrors `permissionSubjectOfIdentity` in core, which is the authority. This
+ * repository cannot import it - layer-common does not depend on the core
+ * package - so there is a copy, and the point of putting it HERE is that there
+ * is only one.
+ *
+ * There used to be two: a local `subjectOf` in `HidAccessPermissions.vue` and
+ * the same ternary inline in `HidUserEnrollment.vue`. The first was stale. It
+ * read every `member` link as `property_management`, so granting a contractor
+ * from the permissions screen wrote a staff assignment - and the reconcile then
+ * derived `staff` from that category and rewrote the identity's `type`, moving
+ * the person out of the service-provider tab and into the member one. The
+ * screen for managing contractors reclassified them by being used.
+ *
+ * A `member` link is how BOTH a property-management member and a service
+ * provider's own employee are stored - the person's membership at this site -
+ * so the identity's `type` is the discriminator. `"contractor"` is written by
+ * the enrolment form and re-confirmed by `permissionIdentityType` on every
+ * reconcile, so the two agree instead of one overwriting the other.
+ *
+ * Returns null for a visitor and for an identity linked to nobody. Visitor
+ * access comes from `user_access_rules` rather than a group, so there is nothing
+ * to switch; an identity holding only an account link names no subject to
+ * assign. Both are still DRAWN by the permissions screen, disabled, with a
+ * reason - dropping them silently is what once made the pager say "1-9 of 9"
+ * over seven rows.
+ */
+export function subjectOfIdentity(
+  identity: Record<string, unknown> | null | undefined,
+): { subjectId: string; category: THidPermissionCategory } | null {
+  if (!identity) return null;
+  if (identity.person) {
+    return { subjectId: String(identity.person), category: "resident" };
+  }
+  if (identity.member) {
+    return {
+      subjectId: String(identity.member),
+      category: String(identity.type ?? "") === "contractor"
+        ? "service_provider_member"
+        : "property_management",
+    };
+  }
+  if (identity.serviceProvider) {
+    return { subjectId: String(identity.serviceProvider), category: "service_provider" };
+  }
+  return null;
+}