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

package/components/HidAccessPermissions.vue

@@ -26,9 +26,9 @@
       <template v-else>
         <div class="hid-access-permissions__intro">
           <p class="text-body-2 text-medium-emphasis mb-0">
-            Residents enrolled on this reader. Enrolling already grants access — switch
-            somebody off to close the door to them without removing their face, card
-            or PIN.
+            Everybody enrolled on this reader, by type. Enrolling already grants
+            access — switch somebody off to close the door to them without removing
+            their face, card or PIN.
           </p>
         </div>
 
@@ -45,12 +45,36 @@
             @refresh="loadEnrolled"
             @update:page="goToPage"
           >
+            <!-- WHICH OF THE READER'S PEOPLE TO SHOW.
+                 The reader holds residents, members and contractors; each tab is
+                 one `type`, filtered and paged by the server. The strip is
+                 `TableMain`'s own slot and the shared `.app-tab` markup, the same
+                 as every other tabbed table here - not a `v-tabs`, whose selected
+                 state is drawn from Vuetify's `on-surface` rather than the
+                 design's accent underline.
+                 The count beside each label is the whole reader's, from the
+                 draft, so it follows an unsaved tick. -->
+            <template #tabs>
+              <button
+                v-for="tab in TABS"
+                :key="tab.value"
+                type="button"
+                class="app-tab"
+                :class="{ 'app-tab--active': activeTab === tab.value }"
+                :aria-pressed="activeTab === tab.value"
+                @click="selectTab(tab.value)"
+              >
+                {{ tab.label }}
+                <span class="hid-access-permissions__tab-count">{{ tabCount(tab) }}</span>
+              </button>
+            </template>
+
             <template #extension>
               <div class="app-filter-row">
                 <AppField
                   v-model="search"
                   search
-                  placeholder="Search name, unit or registration"
+                  :placeholder="searchPlaceholder"
                   @keyup.enter="searchFromFirstPage"
                 />
               </div>
@@ -121,6 +145,7 @@ import {
   readCandidatePage,
   seedAssignments,
   setAssignment,
+  subjectOfIdentity,
   toAssignmentPayload,
   type HidAssignmentState,
 } from "../utils/hid-permission-assignments";
@@ -156,11 +181,52 @@ const emit = defineEmits<{
 
 const { getSitePermissions, getIdentities, updateSitePermissions } = useHidAmico();
 
-/* Name over unit in one cell rather than a "Unit" column — see `subtitleOf`. */
-const headers = [
-  { title: "Resident", value: "name", sortable: false },
+/**
+ * WHO EACH TAB LISTS, AND WHAT A GRANT MADE FROM IT IS FILED UNDER.
+ *
+ * `type` is the identity's own, filtered by the SERVER (`listIdentities` does an
+ * exact match on it), and it is what the enrolment writes and what
+ * `permissionIdentityType` re-confirms on every reconcile. `category` is the
+ * permission category a NEW grant from this tab belongs to.
+ *
+ * The two are a pair rather than one derived from the other, because the tab is
+ * the only thing on this screen that knows which of them the operator means: a
+ * contractor and a property-management member are both a `member` link, and
+ * guessing between them from the record is exactly what went wrong before.
+ */
+const TABS = [
+  { value: "resident", label: "Resident", noun: "Resident", type: "resident", category: "resident" },
+  { value: "member", label: "Member", noun: "Member", type: "staff", category: "property_management" },
+  {
+    value: "provider",
+    label: "Service provider",
+    noun: "Person",
+    type: "contractor",
+    category: "service_provider_member",
+  },
+] as const satisfies ReadonlyArray<{
+  value: string;
+  label: string;
+  noun: string;
+  type: string;
+  category: THidPermissionCategory;
+}>;
+
+const activeTab = ref<(typeof TABS)[number]["value"]>("resident");
+const currentTab = computed(
+  () => TABS.find((tab) => tab.value === activeTab.value) ?? TABS[0],
+);
+
+/** Granted counts per category, for the tab strip. One call, all three. */
+const counts = ref<Record<string, number>>({});
+const tabCount = (tab: (typeof TABS)[number]) => counts.value[tab.category] ?? 0;
+
+/* Name over unit in one cell rather than a "Unit" column — see `subtitleOf`.
+   The first column follows the tab; "Door access" is the same action for all. */
+const headers = computed(() => [
+  { title: currentTab.value.noun, value: "name", sortable: false },
   { title: "Door access", value: "selected", sortable: false, width: 190 },
-];
+]);
 
 const search = ref("");
 const page = ref(1);
@@ -187,6 +253,13 @@ const readerLabel = computed(() => {
   return readerLocation.value ? `${name} · ${readerLocation.value}` : name;
 });
 
+/* "unit" only means something for a resident. */
+const searchPlaceholder = computed(() =>
+  activeTab.value === "resident"
+    ? "Search name, unit or registration"
+    : "Search name or registration",
+);
+
 const assignedTotal = computed(() => draft.value.size);
 const dirty = computed(() => hasChanges(savedState.value, draft.value));
 /* The draft is the truth once the dialog is open, so `selected` is recomputed
@@ -199,6 +272,7 @@ watch(
     if (!isOpen || !readerId.value) return;
     search.value = "";
     page.value = 1;
+    activeTab.value = "resident";
     void loadAll();
   },
   { immediate: true },
@@ -221,6 +295,13 @@ async function loadAssignments() {
     const assignments = response?.data?.assignments ?? [];
     savedState.value = seedAssignments(assignments);
     draft.value = seedAssignments(assignments);
+    /*
+     * Counted from the assignments themselves rather than the server's `counts`
+     * block, so the strip follows the DRAFT and a tick updates the number it
+     * sits beside. `countByCategory` is the same helper the candidate screens
+     * use.
+     */
+    counts.value = countByCategory(draft.value);
   } catch (error) {
     showToast(getErrorMessage(error, "Unable to load this reader's permissions."), "error");
   }
@@ -230,27 +311,6 @@ function toRecord(value: unknown): Record<string, unknown> {
   return value && typeof value === "object" ? (value as Record<string, unknown>) : {};
 }
 
-/**
- * The subject an identity names, in the order `createIdentity` validates them.
- *
- * A visitor returns null and is left out of the list: visitor access comes from
- * `user_access_rules`, not from a group, so there is nothing here to switch
- * off. An identity linked to nobody — a device user the reader holds that was
- * never tied to a person — is dropped for the same reason.
- */
-function subjectOf(identity: Record<string, unknown>) {
-  if (identity.person) {
-    return { subjectId: String(identity.person), category: "resident" as const };
-  }
-  if (identity.member) {
-    return { subjectId: String(identity.member), category: "property_management" as const };
-  }
-  if (identity.serviceProvider) {
-    return { subjectId: String(identity.serviceProvider), category: "service_provider" as const };
-  }
-  return null;
-}
-
 /**
  * Why a row cannot be switched, in words the reader of the screen can act on.
  *
@@ -294,10 +354,10 @@ async function loadEnrolled() {
       page: page.value,
       limit: 10,
       search: search.value.trim(),
-      // Residents only, and filtered by the SERVER rather than here. The pager's
-      // count comes back from the same query, so narrowing the list on this side
-      // would print a total that never matched the rows under it.
-      type: "resident",
+      // THIS TAB's people, and filtered by the SERVER rather than here. The
+      // pager's count comes back from the same query, so narrowing the list on
+      // this side would print a total that never matched the rows under it.
+      type: currentTab.value.type,
     });
     const result = readCandidatePage(response);
     /*
@@ -309,11 +369,13 @@ async function loadEnrolled() {
      */
     enrolled.value = result.items.map((row) => {
       const identity = toRecord(row);
-      const subject = subjectOf(identity);
+      const subject = subjectOfIdentity(identity);
       const metadata = toRecord(identity.metadata);
       return {
         subjectId: subject?.subjectId ?? "",
-        category: subject?.category ?? "resident",
+        // The record's own category where it has one; otherwise the tab's,
+        // which is the only thing that knows what the operator means.
+        category: subject?.category ?? currentTab.value.category,
         // The row's own key. `subjectId` is empty for the rows below, and two
         // empty keys would collapse into one row in the table.
         rowKey: String(identity._id ?? identity.hidUserId ?? Math.random()),
@@ -342,6 +404,24 @@ async function loadEnrolled() {
   }
 }
 
+/**
+ * Switching tabs refetches, because the filter is the SERVER's.
+ *
+ * The draft is untouched: it is the whole reader's, and the save sends all of it
+ * whatever tab is in front of you. Clearing it here - or building the payload
+ * from the loaded rows - is what would revoke everybody on the other two tabs.
+ *
+ * Search is cleared with the tab. It is a server-side search within one type, so
+ * carrying it across would land on an empty list and look like the tab was empty.
+ */
+function selectTab(value: (typeof TABS)[number]["value"]) {
+  if (activeTab.value === value) return;
+  activeTab.value = value;
+  search.value = "";
+  page.value = 1;
+  void loadEnrolled();
+}
+
 function goToPage(value: number) {
   page.value = Number(value) || 1;
   void loadEnrolled();
@@ -352,15 +432,34 @@ function searchFromFirstPage() {
   void loadEnrolled();
 }
 
+/**
+ * Grant or revoke one person.
+ *
+ * The category comes from the row where the server gave it one, and otherwise
+ * from the TAB - never from re-reading the identity's links on this side. A
+ * contractor and a property-management member are both a `member` link, and the
+ * stale local copy of that reading is what used to file contractors as staff: the
+ * reconcile then derived `staff` from that category and rewrote the person's
+ * type, moving them into the Member tab.
+ *
+ * An ALREADY GRANTED person keeps the category their assignment holds, so merely
+ * visiting a tab and toggling somebody off and on cannot re-file them.
+ */
 function toggle(item: THidPermissionCandidate, selected: boolean) {
-  if (!String(item.subjectId ?? "")) return;
+  const subjectId = String(item.subjectId ?? "");
+  if (!subjectId) return;
+  const category = savedState.value.get(subjectId)?.category
+    ?? item.category
+    ?? currentTab.value.category;
   draft.value = setAssignment(
     draft.value,
     savedState.value,
-    String(item.subjectId ?? ""),
-    item.category,
+    subjectId,
+    category,
     selected,
   );
+  // The strip sits beside the rows, so it follows the tick rather than the save.
+  counts.value = countByCategory(draft.value);
 }
 
 async function save() {
@@ -401,6 +500,15 @@ function getErrorMessage(error: unknown, fallback: string) {
 </script>
 
 <style scoped lang="scss">
+/* The granted count beside a tab label. Quieter than the label and set in
+   tabular figures so the three tabs do not shift width as numbers change. */
+.hid-access-permissions__tab-count {
+  margin-left: 6px;
+  color: var(--muted);
+  font-weight: 600;
+  font-variant-numeric: tabular-nums;
+}
+
 .hid-access-permissions {
   &__title { padding-block: 16px; }
 

package/components/HidUserEnrollment.vue

@@ -969,6 +969,7 @@ import {
   memberCandidateOf,
   memberHasAccount,
   HID_ALL_SERVICES,
+  enrolmentSubjectOfCategory,
   permissionCategoryOf,
   providerAccountsKnown,
   providerCandidateOf,
@@ -993,6 +994,7 @@ import {
 import {
   seedAssignments,
   setAssignment,
+  subjectOfIdentity,
   toAssignmentPayload,
   type HidAssignmentState,
 } from "../utils/hid-permission-assignments";
@@ -2570,22 +2572,20 @@ async function openEdit(user: HidUser) {
   form.photoPreview = "";
   facialEnrolled.value = hasFacialEnrollment(user);
   /*
-   * Read in the order `createIdentity` validates the links, with one extra
-   * test. 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 what tells them apart. Without
-   * that test a contractor's edit would be headed "Member".
+   * ONE reading of the links, shared with the Access Permissions screen.
+   * `subjectOfIdentity` knows that a `member` link is how BOTH a
+   * property-management member and a service provider's own employee are stored,
+   * and uses the identity's `type` to tell them apart - without which a
+   * contractor's edit would be headed "Member".
+   *
+   * This was the same ternary written out inline. The other copy of it went
+   * stale, so neither is written out any more.
    */
-  form.subjectCategory = user.person
-    ? "resident"
-    : user.serviceProvider
-    ? "service_provider"
-    : user.member && String(user.type ?? "") === "contractor"
-    ? "service_provider_staff"
-    : "property_management";
-  form.subjectId = String(
-    user.person || user.member || user.serviceProvider || ""
-  );
+  const editedSubject = subjectOfIdentity(user as Record<string, unknown>);
+  form.subjectCategory = enrolmentSubjectOfCategory(
+    editedSubject?.category
+  ) as TEnrolmentSubjectValue;
+  form.subjectId = editedSubject?.subjectId ?? "";
   // The resident this user already holds is not a conflict with itself. A real
   // one only appears if the operator reassigns the row to somebody else.
   residentConflict.value = null;

package/package.json

@@ -2,7 +2,7 @@
   "name": "@7365admin1/layer-common",
   "license": "MIT",
   "type": "module",
-  "version": "4.97.1-staging.500",
+  "version": "4.97.1-staging.501",
   "author": "7365admin1",
   "main": "./nuxt.config.ts",
   "//files": "What a consumer extending this layer actually loads. Without this npm ships the whole working tree - the changesets, the CI workflows, the render harness in tools/ and any scratch directory that happened to exist at publish time. Nuxt resolves a layer by directory, so every runtime directory below has to stay listed; adding a new top-level runtime directory means adding it here too.",

package/utils/hid-enrolment-subject.ts

@@ -240,6 +240,28 @@ export function permissionCategoryOf(category: unknown): string {
   return "property_management";
 }
 
+/**
+ * The dropdown value for a grant's category — the inverse of
+ * `permissionCategoryOf`.
+ *
+ * An edit STATES the subject type rather than offering it, because an identity's
+ * category cannot change after it is created. This is how a stored record is
+ * turned back into the value the form holds, and it is wider than the dropdown on
+ * purpose: records in the wild carry `service_provider`, which names a COMPANY
+ * and which the dropdown does not offer.
+ *
+ * Paired with `subjectOfIdentity` so the mapping lives in one place. `openEdit`
+ * used to repeat the whole links-and-type ternary inline, which is how the copy
+ * in `HidAccessPermissions.vue` was able to go stale without anything noticing.
+ */
+export function enrolmentSubjectOfCategory(category: unknown): string {
+  const value = String(category ?? "");
+  if (value === "resident") return "resident";
+  if (value === "service_provider_member") return "service_provider_staff";
+  if (value === "service_provider") return "service_provider";
+  return "property_management";
+}
+
 /* ── PROVIDER STAFF AS PICKER ROWS ─────────────────────────────────────── */
 
 /**

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;
+}