@7365admin1/layer-common 4.73.1-staging.462 → 4.73.1-staging.463

package/components/AccessCardDetailsDialog.vue

@@ -47,14 +47,22 @@
           <div>
             <div class="card-details__label">User</div>
             <div class="card-details__value">
-              {{ details.userCred?.name ?? details.user?.name ?? "N/A" }}
-              <template v-if="details.user?.email">({{ details.user.email }})</template>
+              <template v-if="holderState === 'named'">
+                {{ holderName }}
+                <template v-if="details.user?.email">({{ details.user.email }})</template>
+              </template>
+              <!-- Assigned, but the server did not send the name back. Saying
+                   so beats "N/A", which reads as "nobody holds this card". -->
+              <template v-else-if="holderState === 'assigned'">
+                <span class="text-medium-emphasis">Assigned — name unavailable</span>
+              </template>
+              <template v-else>Unassigned</template>
             </div>
           </div>
 
-          <div v-if="details.userType">
+          <div v-if="holderType">
             <div class="card-details__label">User Type</div>
-            <div class="card-details__value">{{ details.userType }}</div>
+            <div class="card-details__value">{{ holderType }}</div>
           </div>
 
           <!-- Visitor / Resident Credentials -->
@@ -216,6 +224,51 @@ const sortedHistory = computed(() =>
   )
 );
 
+/**
+ * WHO HOLDS THIS CARD.
+ *
+ * `userCred` is written by the visitor-pass flow and carries the person's
+ * details on the card itself. `user` is the resolved account - the card only
+ * stores `userId`, so the server has to join it.
+ *
+ * `card-details` does not do that join today (the lookup is commented out in
+ * core's `getCardDetailsRepo`), so this is empty for every card assigned
+ * through Assign to Person and the field falls through to `holderState`.
+ * Nothing here needs to change when the join is restored.
+ */
+const holderName = computed(
+  () => details.value?.userCred?.name ?? details.value?.user?.name ?? "",
+);
+
+/**
+ * A card with a `userId` IS assigned, whether or not the name came back.
+ *
+ * Printing "N/A" for both cases is the actual defect here: it reads as "nobody
+ * holds this card", which is the opposite of the truth for an assigned one and
+ * could have someone hand out a card that is already in use.
+ */
+const holderState = computed<"named" | "assigned" | "unassigned">(() => {
+  if (holderName.value) return "named";
+  return details.value?.userId ? "assigned" : "unassigned";
+});
+
+/**
+ * WHICH KIND OF PERSON HOLDS THIS CARD — Visitor/Resident, Management or
+ * Service Provider, matching the groups Assign to Person offers.
+ *
+ * `holderType` is what the server should send once it records the category the
+ * card was assigned under. `userType` is NOT that: it is the card's own pool,
+ * and `getCardDetailsRepo` filters on `EAccessCardUserTypes.DEFAULT`, so every
+ * card this dialog can load has the literal value "Visitor/Resident" whoever
+ * actually holds it. Preferring `holderType` means a card given to Management
+ * stops describing itself as a resident's the day the field arrives.
+ *
+ * Falls back to `userType` so nothing disappears in the meantime.
+ */
+const holderType = computed(
+  () => details.value?.holderType ?? details.value?.userType ?? "",
+);
+
 watch(
   () => props.modelValue,
   async (val) => {

package/components/AccessCardPreviewDialog.vue

@@ -453,7 +453,7 @@ const emit = defineEmits<{
 const { getResidents, assignUser } = useAccessManagement();
 const { getEncryptedAcmUrl } = useSiteEntryPassSettings();
 const { getAll: getMembers } = useMember();
-const { getAll: getServiceProviders } = useServiceProvider();
+const { getSiteMembers } = useServiceProvider();
 
 const historyDialog = ref(false);
 const showAssignForm = ref(false);
@@ -552,14 +552,12 @@ const personTypeLabel = (person: Record<string, any>) => {
 const assignNoDataText = computed(() => {
   if (peopleLoading.value) return "Loading...";
   if (assignCategory.value === "management") return "No management members assigned to this unit";
-  if (assignCategory.value === "providers") return "No service providers assigned to this unit";
+  if (assignCategory.value === "providers") return "No service provider members assigned to this unit";
   return "No residents or tenants found for this unit";
 });
 
-const assignUnassignableText = computed(() =>
-  assignCategory.value === "providers"
-    ? "A card is held by a person, and this is the provider company. Assigning to service providers needs the server to say which account the card belongs to."
-    : "This person has no user account, so a card cannot be assigned to them.",
+const assignUnassignableText = computed(
+  () => "This person has no account on record, so a card cannot be assigned to them.",
 );
 
 /** Residents and tenants of THIS UNIT - the list the dialog has always shown. */
@@ -619,41 +617,48 @@ async function loadManagementRows(): Promise<AssignRow[]> {
 }
 
 /**
- * Service Providers ATTACHED TO THIS UNIT.
+ * Service Providers - the provider PEOPLE attached to this unit.
  *
- * `GET /api/service-providers?siteId&status=active&unit=<id>` - the same list
- * and the same unit filter the Unit Management tab uses (core #2515), so the
- * providers offered are the ones this unit actually has.
+ * `GET /api/service-providers/site-members?siteId&unit=<id>`. A card is held by
+ * a person, so this lists provider staff rather than the companies
+ * `GET /api/service-providers` returns, and the `unit` filter keeps it to the
+ * people that unit actually has - the same scoping Management uses.
  *
- * These rows are COMPANIES, not people: the list has `name`, `email` and the
- * service `type`, and there is no user account behind a company. See
- * `assigneeId` below.
+ * The response also carries a `companies` summary; only `items` is people.
  */
 async function loadProviderRows(): Promise<AssignRow[]> {
   if (!props.siteId || !props.unit?._id) return [];
-  const res: any = await getServiceProviders({
-    siteId: props.siteId,
-    unit: props.unit._id,
-    status: "active",
-    page: 1,
-    limit: 50,
-  });
-  const rows: Record<string, any>[] = res?.items ?? [];
-  return rows.map((provider) => ({
+  const res = await getSiteMembers(props.siteId, props.unit._id);
+  const rows = res?.items ?? [];
+  return rows.map((member: Record<string, any>) => ({
+    /*
+     * `user` when the endpoint returns it, otherwise the MEMBERSHIP `_id`.
+     *
+     * `site-members` does not carry `user` today (the repository projects it,
+     * the service layer drops it), and the product decision is to assign on
+     * `_id` rather than wait. Worth knowing what that means: the card's
+     * `userId` then holds a `service-provider-members` id, so the card list's
+     * `userId -> users` lookup finds nothing and the holder column reads blank
+     * for these cards. The door access itself is unaffected - the ACM command
+     * is built from the CARD's id, not the assignee's.
+     *
+     * `user` is preferred so that the day it starts arriving, these cards
+     * begin resolving to real people with no change here.
+     */
+    assigneeId: String(member.user ?? member._id ?? ""),
+    name: member.name || member.email || "",
+    subtitle: member.email ?? "",
     /*
-     * Empty on purpose, and not a missing field: a card is assigned by writing
-     * a USER id onto it, and a provider company has no user account. Which id a
-     * company-held card should carry - the `service-providers` row, the
-     * provider `orgId`, or a person from that company - is a backend decision
-     * that has not been made. Sending one anyway would write an id the server
-     * stores without checking and that matches no user.
+     * The service the company provides, plus this person's role - two people
+     * from the same company differ only by role ("VMS Access" vs "Security
+     * Access"). `typeLabel` is computed by the endpoint; the local converter is
+     * the fallback for a row that predates it.
      */
-    assigneeId: "",
-    name: provider.name ?? "",
-    subtitle: provider.email ?? "",
-    // The service code is a database value; show what people call it.
-    meta: serviceTypeLabel(provider.type),
-    raw: provider,
+    meta:
+      [member.typeLabel || serviceTypeLabel(member.type), member.role]
+        .filter(Boolean)
+        .join(" · "),
+    raw: member,
   }));
 }
 

package/composables/useServiceProvider.ts

@@ -18,6 +18,13 @@ export type TSiteProviderMember = {
   /** The building unit this person is attached to (a unit's Management tab). */
   unit?: string | null;
   unitName?: string;
+  /**
+   * The person's user account. NOT yet returned by the endpoint — the
+   * repository projects it but the service layer drops it. Anything acting on
+   * the PERSON (assigning an access card writes it onto the card as `userId`)
+   * needs this rather than `_id`, which identifies the membership.
+   */
+  user?: string | null;
 };
 
 export type TSiteProviderCompany = {

package/package.json

@@ -2,7 +2,7 @@
   "name": "@7365admin1/layer-common",
   "license": "MIT",
   "type": "module",
-  "version": "4.73.1-staging.462",
+  "version": "4.73.1-staging.463",
   "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.",