@7365admin1/layer-common 4.90.2-staging.485 → 4.90.2-staging.486

package/components/AccessCardDetailsDialog.vue

@@ -68,9 +68,9 @@
           <!-- Visitor / Resident Credentials -->
           <template v-if="details.userCred">
             <v-divider />
-            <div class="card-details__section">
+            <!-- <div class="card-details__section">
               {{ details.userType ?? "Visitor Information" }}
-            </div>
+            </div> -->
 
             <div v-if="details.userCred.email">
               <div class="card-details__label">Email</div>

package/components/AccessCardPreviewDialog.vue

@@ -50,18 +50,28 @@
 
         <!-- Person Selector -->
         <InputLabel title="Person" required class="mb-1" />
-        <v-select
+        <!--
+          An autocomplete rather than a select: a unit's Management and provider
+          lists are short, but a site's can run to dozens, and scrolling for a
+          name is slow. `custom-filter` widens the match beyond the title,
+          because the thing an operator remembers is often the email or the role
+          - and a member's name IS frequently their email address.
+        -->
+        <v-autocomplete
           v-model="assignPerson"
+          v-model:search="personSearch"
           :items="assignPeopleItems"
+          :custom-filter="filterPerson"
           density="compact"
           item-title="name"
           item-value="assigneeId"
           hide-details="auto"
-          placeholder="Select person..."
+          placeholder="Search or select person..."
           persistent-placeholder
           :loading="peopleLoading"
           :disabled="peopleLoading"
           return-object
+          :hide-no-data="false"
           :no-data-text="assignNoDataText"
         >
           <!--
@@ -98,7 +108,7 @@
               </div>
             </div>
           </template>
-        </v-select>
+        </v-autocomplete>
 
         <!--
           A card is assigned by writing the person's USER id onto it, so a row
@@ -455,6 +465,20 @@ const { getEncryptedAcmUrl } = useSiteEntryPassSettings();
 const { getAll: getMembers } = useMember();
 const { getSiteMembers } = useServiceProvider();
 
+/**
+ * The member type of whichever app this layer is running in
+ * ("property_management_agency", "security_agency", ...), which `/api/members`
+ * requires and rejects empty.
+ *
+ * Read HERE, during setup, not inside the loader that uses it:
+ * `useRuntimeConfig` needs the Nuxt instance, and that is only guaranteed
+ * synchronously in setup. Called from an async function resumed after an
+ * await — which is exactly what the loader is — it throws "nuxt instance
+ * unavailable", the loader's catch turns that into an empty list, and the
+ * Management group silently shows nothing with no request ever sent.
+ */
+const APP = String(useRuntimeConfig().public.APP ?? "");
+
 const historyDialog = ref(false);
 const showAssignForm = ref(false);
 const assignPerson = ref<Record<string, any> | null>(null);
@@ -471,10 +495,22 @@ const assignPerson = ref<Record<string, any> | null>(null);
  */
 type AssignCategory = "residents" | "management" | "providers";
 
-const assignCategories: { value: AssignCategory; label: string }[] = [
-  { value: "residents", label: "Resident / Tenant" },
-  { value: "management", label: "Management" },
-  { value: "providers", label: "Service Provider" },
+const assignCategories: {
+  value: AssignCategory;
+  label: string;
+  /**
+   * What the server stores as the card's `holderType` (core
+   * `EAccessCardHolderTypes`). Sent with the assignment, because `assignees`
+   * alone is ambiguous: it is a `users` id for a resident and a membership id
+   * for a provider, and only the group says which to resolve against. These
+   * strings are a server contract - the labels above are free to change, these
+   * are not.
+   */
+  holderType: "Visitor/Resident" | "Management" | "Service Provider";
+}[] = [
+  { value: "residents", label: "Resident / Tenant", holderType: "Visitor/Resident" },
+  { value: "management", label: "Management", holderType: "Management" },
+  { value: "providers", label: "Service Provider", holderType: "Service Provider" },
 ];
 
 const assignCategory = ref<AssignCategory>("residents");
@@ -500,6 +536,30 @@ type AssignRow = {
 };
 
 const assignPeopleItems = ref<AssignRow[]>([]);
+
+/** What is typed in the person picker. Cleared whenever the group changes. */
+const personSearch = ref("");
+
+/**
+ * Match a person on everything the row shows, not just the name.
+ *
+ * Vuetify filters on the title alone by default, which is too narrow here: a
+ * Management member's name is often their email address, and two provider
+ * people from one company are told apart only by their role. Both of those sit
+ * in the second line, so a name-only match would hide the row an operator is
+ * actually searching for.
+ *
+ * The first argument is the title Vuetify matched against; it is ignored in
+ * favour of the row itself, which carries all three fields.
+ */
+function filterPerson(_title: string, query: string, item: any): boolean {
+  const q = String(query ?? "").trim().toLowerCase();
+  if (!q) return true;
+  const row = item?.raw ?? {};
+  return [row.name, row.subtitle, row.meta].some((field) =>
+    String(field ?? "").toLowerCase().includes(q),
+  );
+}
 const peopleLoading = ref(false);
 const assignLoading = ref(false);
 const assignError = ref("");
@@ -597,7 +657,7 @@ async function loadManagementRows(): Promise<AssignRow[]> {
     org: props.orgId,
     siteId: props.siteId,
     unit: props.unit._id,
-    type: String(useRuntimeConfig().public.APP ?? ""),
+    type: APP,
     status: "active",
     page: 1,
     limit: 50,
@@ -678,9 +738,19 @@ async function loadAssignPeople() {
           : await loadResidentRows();
     if (seq !== assignLoadSeq) return;
     assignPeopleItems.value = rows;
-  } catch {
+  } catch (e: any) {
     if (seq !== assignLoadSeq) return;
     assignPeopleItems.value = [];
+    /*
+     * Say that the list failed rather than showing an empty one.
+     *
+     * This swallowed everything, so a group whose request 400'd, or never got
+     * sent at all, looked exactly like a group with nobody in it - there was
+     * nothing on screen to tell the two apart, and no way to tell from the UI
+     * that anything had gone wrong.
+     */
+    assignError.value =
+      e?.data?.message ?? e?.message ?? "Could not load the list. Please try again.";
   } finally {
     if (seq === assignLoadSeq) peopleLoading.value = false;
   }
@@ -688,6 +758,9 @@ async function loadAssignPeople() {
 
 function onAssignCategoryChange() {
   assignPerson.value = null;
+  // A term typed for the previous group means nothing in the next one, and
+  // leaving it would show an empty list over a list that has people in it.
+  personSearch.value = "";
   assignError.value = "";
   loadAssignPeople();
 }
@@ -695,6 +768,7 @@ function onAssignCategoryChange() {
 async function openAssignForm() {
   showAssignForm.value = true;
   assignPerson.value = null;
+  personSearch.value = "";
   assignCategory.value = "residents";
   assignError.value = "";
   assignPeopleItems.value = [];
@@ -714,6 +788,7 @@ async function openAssignForm() {
 function cancelAssign() {
   showAssignForm.value = false;
   assignPerson.value = null;
+  personSearch.value = "";
   assignCategory.value = "residents";
   assignPeopleItems.value = [];
   assignError.value = "";
@@ -744,6 +819,8 @@ async function confirmAssign() {
       type: selectedCardType.value,
       acm_url: encryptedAcmUrl.value,
       id: props.selectedCardInUnit?._id,
+      holderType: assignCategories.find((c) => c.value === assignCategory.value)
+        ?.holderType,
     });
     emit("assign-to-person", {
       card: props.selectedCardInUnit,

package/composables/useAccessManagement.ts

@@ -319,7 +319,23 @@ export default function useAccessManagement() {
     );
   }
 
-  function assignUser(payload: { assignees: string[]; unit: string; type: string; acm_url: string; id?: string }) {
+  /**
+   * `holderType` is the GROUP the card was given from — "Visitor/Resident",
+   * "Management" or "Service Provider" (core `EAccessCardHolderTypes`).
+   *
+   * It is what lets the server resolve the holder afterwards: `assignees`
+   * carries a `users` id for a resident, but a membership id for a service
+   * provider, and only the group says which collection to look in. Omit it and
+   * the card stores `holderType: null`, so card details cannot name the holder.
+   */
+  function assignUser(payload: {
+    assignees: string[];
+    unit: string;
+    type: string;
+    acm_url: string;
+    id?: string;
+    holderType?: "Visitor/Resident" | "Management" | "Service Provider";
+  }) {
     return useNuxtApp().$api<Record<string, any>>(
       `/api/access-management/assign-user`,
       { method: "POST", body: payload }

package/package.json

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