@7365admin1/layer-common 4.82.1-staging.479 → 4.82.1-staging.480

package/components/HidUserEnrollment.vue

@@ -363,7 +363,7 @@
                access is bound by user id, so there is nothing to bind. The note
                below says how many were left out rather than letting a missing
                colleague read as a bug. -->
-          <template v-if="!selectedUser && !isResidentSubject">
+          <template v-if="!selectedUser && isMemberSubject">
             <div class="field-label">Member <span>*</span></div>
             <AppSelect
               v-model="form.subjectId"
@@ -389,6 +389,59 @@
             </p>
           </template>
 
+          <!-- SERVICE PROVIDER STAFF. One person from a provider company, and
+               never the company: granting a company puts every employee of the
+               firm on the door, including the ones who do not attend this site.
+               The list, the service filter and the filter's "All services"
+               default are the Members > Service Providers screen's own, from the
+               same endpoint and through the same `filterProviderMembers` rule,
+               so the two screens cannot disagree about who works here.
+               Unpaged - the endpoint returns the site's people in one response -
+               so searching and filtering cost no request. -->
+          <template v-if="!selectedUser && isProviderSubject">
+            <div class="field-label">Service</div>
+            <AppSelect
+              v-model="providerService"
+              :items="providerServiceOptions"
+              klass="mb-3"
+              @update:model-value="onProviderServiceChanged"
+            />
+
+            <div class="field-label">Person <span>*</span></div>
+            <AppSelect
+              v-model="form.subjectId"
+              :items="providerOptions"
+              searchable
+              search-placeholder="Search by name, company or role"
+              :placeholder="providerPlaceholder"
+              klass="mb-3"
+              @update:model-value="onProviderChanged"
+            />
+
+            <!-- ACCESS ONLY, and the button says so. Shown here and nowhere
+                 else: it is the one subject type that arrives a shift at a time,
+                 and the people it adds fill in their own credentials from their
+                 app afterwards. -->
+            <div class="hid-bulk-cta mb-3">
+              <AppButton
+                variant="ghost"
+                icon="mdi-account-multiple-plus-outline"
+                :disabled="loadingProviders"
+                @click="openBulkAdd"
+              >
+                Add Users in Bulk
+              </AppButton>
+              <span class="field-hint">
+                Gives access to many people at once. They add their own face, QR
+                or PIN from their app.
+              </span>
+            </div>
+
+            <p v-if="hiddenProviderNote" class="field-hint mb-3">
+              {{ hiddenProviderNote }}
+            </p>
+          </template>
+
           <!-- The duplicate check. It is reader-scoped: this resident holding a
                HID user on another gate is normal and says nothing here. -->
           <p v-if="checkingResident" class="field-hint">
@@ -412,12 +465,12 @@
                whatever the reader already holds. -->
           <!-- A mirror of the chosen member's role, on the same rule as Name:
                restated from the record, never collected. -->
-          <template v-if="!selectedUser && !isResidentSubject">
-            <div class="field-label">Role</div>
+          <template v-if="!selectedUser && isPersonSubject">
+            <div class="field-label">{{ subjectMirrorLabel }}</div>
             <AppField
               v-model="form.subjectRole"
-              aria-label="Role"
-              placeholder="Select a member above"
+              :aria-label="subjectMirrorLabel"
+              :placeholder="subjectMirrorPlaceholder"
               readonly
               klass="mb-3"
             />
@@ -430,6 +483,8 @@
             :placeholder="
               isResidentSubject
                 ? 'Select a resident above'
+                : isProviderSubject
+                ? 'Select a person above'
                 : 'Select a member above'
             "
             readonly
@@ -567,6 +622,115 @@
       </v-card>
     </v-dialog>
 
+    <!-- ADD USERS IN BULK.
+         Over the enrolment form, not instead of it: the operator came here to
+         enrol, and this is the shortcut for the case where a whole shift arrives
+         at once. It grants ACCESS only - the people it adds are recognised by the
+         reader once they add a face, QR or PIN from their own app - which is why
+         it collects no photo, PIN or password.
+         The table is the same list as the picker behind it, under the same
+         service filter, with Company / Name / Service and nothing else: the
+         Members screen's other columns say nothing about whether to open a door
+         for somebody. -->
+    <v-dialog v-model="bulkDialog" max-width="640" persistent>
+      <v-card class="screen-modal">
+        <v-card-title>Add Users in Bulk</v-card-title>
+        <v-card-text class="screen-modal__body">
+          <p class="field-hint mb-3">
+            Gives these people access to
+            <strong>{{ bulkReaderLabel }}</strong>. They add their own face, QR
+            or PIN from their app - nothing is enrolled on the reader here.
+          </p>
+
+          <AppField
+            v-model="bulkSearch"
+            aria-label="Search people"
+            placeholder="Search by name, company or role"
+            klass="mb-3"
+          />
+
+          <v-progress-linear v-if="bulkLoading" indeterminate class="mb-3" />
+
+          <template v-else-if="bulkRows.length">
+            <v-table density="compact" class="hid-bulk-table mb-2">
+              <thead>
+                <tr>
+                  <th class="hid-bulk-table__check">
+                    <!-- Acts on the rows in front of you - what the service
+                         filter and the search have left - never on the whole
+                         estate. -->
+                    <v-checkbox
+                      :model-value="bulkAllSelected"
+                      :disabled="!bulkSelectableRows.length"
+                      hide-details
+                      density="compact"
+                      aria-label="Select everyone listed"
+                      @update:model-value="toggleBulkAll"
+                    />
+                  </th>
+                  <th>Company</th>
+                  <th>Name</th>
+                  <th>Service</th>
+                </tr>
+              </thead>
+              <tbody>
+                <tr v-for="row in bulkRows" :key="row.subjectId">
+                  <td class="hid-bulk-table__check">
+                    <!-- Already on the door: ticked and locked. Unticking here
+                         would revoke access, and this dialog does not revoke. -->
+                    <v-checkbox
+                      :model-value="row.granted || isBulkSelected(row.subjectId)"
+                      :disabled="row.granted"
+                      hide-details
+                      density="compact"
+                      :aria-label="`Select ${row.name}`"
+                      @update:model-value="toggleBulkRow(row.subjectId, $event)"
+                    />
+                  </td>
+                  <td>{{ row.company || "—" }}</td>
+                  <td>
+                    {{ row.name }}
+                    <span v-if="row.granted" class="hid-bulk-granted">
+                      Already has access
+                    </span>
+                  </td>
+                  <td>{{ row.service || "—" }}</td>
+                </tr>
+              </tbody>
+            </v-table>
+            <p class="field-hint">
+              {{ bulkSelectedCount }} selected<template v-if="bulkGrantedCount">
+                · {{ bulkGrantedCount }} already have access</template
+              >
+            </p>
+          </template>
+
+          <v-alert v-else type="info" variant="tonal" density="compact">
+            {{ bulkEmptyText }}
+          </v-alert>
+        </v-card-text>
+        <v-card-actions class="screen-modal__footer">
+          <v-btn
+            class="text-none screen-btn-ghost"
+            variant="flat"
+            :disabled="bulkSaving"
+            @click="bulkDialog = false"
+          >
+            Cancel
+          </v-btn>
+          <v-btn
+            class="text-none screen-btn-primary"
+            variant="flat"
+            :loading="bulkSaving"
+            :disabled="!bulkSelectedCount"
+            @click="saveBulkAdd"
+          >
+            Give access
+          </v-btn>
+        </v-card-actions>
+      </v-card>
+    </v-dialog>
+
     <HidCameraCaptureDialog v-model="cameraDialog" @capture="onCameraCapture" />
 
     <v-dialog v-model="viewDialog" max-width="430">
@@ -804,9 +968,34 @@ import {
   hiddenSubjectNote,
   memberCandidateOf,
   memberHasAccount,
+  HID_ALL_SERVICES,
+  permissionCategoryOf,
+  providerAccountsKnown,
+  providerCandidateOf,
+  providerEnrollableRows,
   readMemberPage,
+  serviceFilterOf,
   subjectCategoryLabel as labelForSubjectCategory,
+  subjectLinkOf,
+  type HidEnrolmentSubject,
 } from "../utils/hid-enrolment-subject";
+/* The SAME filter the Members > Service Providers screen applies, not a second
+   copy of the rule: a picker that disagrees with the screen the operator was
+   just looking at is a picker they cannot trust. Core applies it to the Excel
+   export too (`filterSiteProviderMembers`). */
+import {
+  filterProviderMembers,
+  serviceTypeOptions,
+} from "../utils/site-provider-members";
+/* Bulk access is granted through the permissions document, and the PUT REPLACES
+   this reader's whole assignment set. These three are what keep a bulk add from
+   revoking everybody who was already on the door - see the file's own header. */
+import {
+  seedAssignments,
+  setAssignment,
+  toAssignmentPayload,
+  type HidAssignmentState,
+} from "../utils/hid-permission-assignments";
 
 const props = defineProps({
   site: {
@@ -847,8 +1036,13 @@ const {
   createIdentity,
   updateIdentity,
   deleteIdentity,
+  getSitePermissions,
+  updateSitePermissions,
 } = useHidAmico();
 const { getAll: getAllMembers } = useMember();
+/* Members > Service Providers reads this same call, so the enrolment picker
+   offers exactly the people that screen lists. Site-scoped by the server. */
+const { getSiteMembers } = useServiceProvider();
 const runtimeConfig = useRuntimeConfig();
 
 type HidMetadata = Record<string, unknown> & {
@@ -1034,7 +1228,11 @@ type UnitPerson = {
  * the dialog, and `useHidReaderSelection` already set the precedent for where
  * that line sits.
  */
-const REMEMBERED_SUBJECT_CATEGORY = ref<THidPermissionCategory>("resident");
+/* The dropdown's values, plus `service_provider` - which the dropdown does not
+   offer but `openEdit` resolves from records that name a COMPANY. */
+type TEnrolmentSubjectValue = HidEnrolmentSubject | "service_provider";
+
+const REMEMBERED_SUBJECT_CATEGORY = ref<HidEnrolmentSubject>("resident");
 
 const form = reactive({
   reader: "",
@@ -1048,7 +1246,7 @@ const form = reactive({
   accessPin: "",
   password: "",
   photoPreview: "",
-  subjectCategory: REMEMBERED_SUBJECT_CATEGORY.value,
+  subjectCategory: REMEMBERED_SUBJECT_CATEGORY.value as TEnrolmentSubjectValue,
   subjectId: "",
   /** A mirror of the chosen member's role. Never sent; display only. */
   subjectRole: "",
@@ -1170,6 +1368,28 @@ const unitResidentNote = computed(() => {
 const subjectCategoryOptions = HID_ENROLMENT_SUBJECTS;
 
 const isResidentSubject = computed(() => form.subjectCategory === "resident");
+/* Members and provider staff both pick ONE PERSON from a flat list, but from
+   different lists, so they are separate branches rather than "not a resident". */
+const isMemberSubject = computed(
+  () => form.subjectCategory === "property_management"
+);
+const isProviderSubject = computed(
+  () => form.subjectCategory === "service_provider_staff"
+);
+/** Either of the two person pickers - what the Role mirror follows. */
+const isPersonSubject = computed(
+  () => isMemberSubject.value || isProviderSubject.value
+);
+
+/* The mirror's label follows the list it mirrors. A member's subtitle is their
+   role at the site; a contractor's is the firm they work for, and calling that
+   "Role" would read as a mistake. */
+const subjectMirrorLabel = computed(() =>
+  isProviderSubject.value ? "Company" : "Role"
+);
+const subjectMirrorPlaceholder = computed(() =>
+  isProviderSubject.value ? "Select a person above" : "Select a member above"
+);
 
 /* What an EDIT shows in place of the control, since the type cannot change.
    Looked up in the util, not in the switch's own options: records carry
@@ -1363,6 +1583,387 @@ function loadMoreMembers() {
   return fetchMemberPage(memberPage.value + 1, true);
 }
 
+/* ── SERVICE PROVIDER STAFF ───────────────────────────────────────────────
+ *
+ * ONE PERSON from a provider company, never the company.
+ *
+ * Read from `GET /api/service-providers/site-members` - the same call behind
+ * Members > Service Providers, with the same `filterProviderMembers` rule - so
+ * the picker lists exactly the people that screen lists. The server scopes it to
+ * the site; these are the contractors who attend THIS site, not every employee
+ * of every firm engaged with the organisation.
+ *
+ * Unpaged, deliberately, unlike the staff picker above: this endpoint returns
+ * the site's people in one response (capped at 1000 by the repository) and has
+ * no per-page cache entry to disagree with. The service filter and the search
+ * box both run over the loaded list, so neither costs a request.
+ */
+const providerPeople = ref<Record<string, unknown>[]>([]);
+const providerCompanyCount = ref(0);
+const loadingProviders = ref(false);
+const providersLoaded = ref(false);
+/**
+ * All services is the default, the same as the Members screen - but it carries a
+ * REAL value here, not "". `AppSelect`'s `hasSingleValue` is false for an empty
+ * string, so an empty-valued option draws the placeholder in placeholder grey and
+ * is never marked as chosen: the filter worked and the field looked blank. See
+ * `serviceFilterOf`.
+ */
+const providerService = ref<string>(HID_ALL_SERVICES);
+
+/** What the filter actually receives: "" for All services. */
+const providerServiceFilter = computed(() => serviceFilterOf(providerService.value));
+let providerRequestSeq = 0;
+
+/** Everyone who can actually be given a door: an app account, and active. */
+const providerEnrollable = computed(() =>
+  providerEnrollableRows(providerPeople.value)
+);
+
+/* Whether the endpoint told us who holds an app account. It only began
+   returning `user` in core 3.130, and this layer can be deployed ahead of it. */
+const providerAccountsVisible = computed(() =>
+  providerAccountsKnown(providerPeople.value)
+);
+
+/** People the operator can see on the Members screen but cannot enrol here. */
+const hiddenProviderCount = computed(
+  () => providerPeople.value.length - providerEnrollable.value.length
+);
+
+const providerServiceOptions = computed(() => [
+  { title: "All services", value: HID_ALL_SERVICES },
+  // From the ENROLLABLE set, so choosing a service never lands on an empty list.
+  ...serviceTypeOptions(providerEnrollable.value as Array<{ type?: string; typeLabel?: string }>),
+]);
+
+/** The filtered list - what both the picker and the bulk table draw. */
+const providerRows = computed(() =>
+  filterProviderMembers(providerEnrollable.value as Array<Record<string, any>>, {
+    type: providerServiceFilter.value,
+  })
+);
+
+const providerOptions = computed(() =>
+  providerRows.value.map((row) => {
+    const candidate = providerCandidateOf(row);
+    return {
+      // The firm in the title as well as the mirror: two contractors sharing a
+      // first name is the normal case, and the popover is where they have to be
+      // told apart.
+      title: candidate.subtitle
+        ? `${candidate.name} — ${candidate.subtitle}`
+        : candidate.name,
+      value: candidate.subjectId,
+    };
+  })
+);
+
+const providerPlaceholder = computed(() => {
+  if (loadingProviders.value) return "Loading people...";
+  if (!providersLoaded.value) return "Select a person";
+  if (providerOptions.value.length) return "Select a person";
+  if (providerServiceFilter.value) return "Nobody in this service can be enrolled yet";
+  if (hiddenProviderCount.value) return "Nobody here can be enrolled yet";
+  return providerCompanyCount.value
+    ? "No service provider people at this site"
+    : "No service providers work at this site yet";
+});
+
+/* Say why somebody on the Members screen is not in this list, rather than
+   letting a missing colleague read as a broken dialog. */
+const hiddenProviderNote = computed(() => {
+  if (loadingProviders.value || !hiddenProviderCount.value) return "";
+  const count = hiddenProviderCount.value;
+  const subject = count === 1 ? "1 person" : `${count} people`;
+  const verb = count === 1 ? "is" : "are";
+  const holder = count === 1 ? "that person is" : "they are";
+  const needs = providerAccountsVisible.value
+    ? "an active membership with an app account"
+    : "an active membership at this site";
+  return `${subject} from this site's service providers ${verb} not listed:`
+    + ` HID enrollment needs ${needs}, and ${holder} without one.`;
+});
+
+/** Back to "nothing loaded", so the next open starts clean. */
+function resetProviderCandidates() {
+  providerRequestSeq += 1;
+  providerPeople.value = [];
+  providerCompanyCount.value = 0;
+  providerService.value = HID_ALL_SERVICES;
+  providersLoaded.value = false;
+}
+
+/**
+ * This site's service provider people.
+ *
+ * NEVER THROWS, on the same rule as the staff loader: choosing Service provider
+ * must not break the dialog. The placeholder carries the failure.
+ */
+async function loadProviderCandidates() {
+  if (!props.site) {
+    resetProviderCandidates();
+    providersLoaded.value = true;
+    return;
+  }
+  const seq = (providerRequestSeq += 1);
+  loadingProviders.value = true;
+  try {
+    const data = await getSiteMembers(props.site);
+    // A response that arrived after the dialog was reopened belongs to a list
+    // that no longer exists - the same guard the staff pager uses.
+    if (seq !== providerRequestSeq) return;
+    providerPeople.value = Array.isArray(data?.items)
+      ? (data.items as unknown as Record<string, unknown>[])
+      : [];
+    providerCompanyCount.value = Array.isArray(data?.companies)
+      ? data.companies.length
+      : 0;
+    providersLoaded.value = true;
+  } catch (error: unknown) {
+    if (seq !== providerRequestSeq) return;
+    console.error("Unable to load service provider people for HID enrollment:", error);
+    providerPeople.value = [];
+    providerCompanyCount.value = 0;
+    providersLoaded.value = true;
+  } finally {
+    loadingProviders.value = false;
+  }
+}
+
+/** The chosen person, restated into Name and the Company mirror. */
+function onProviderChanged() {
+  // Compared on the TRIMMED id, because that is what the option's value carries
+  // (`providerCandidateOf` trims) - matching the raw field would silently find
+  // nobody and blank the name the operator just picked.
+  const row = providerRows.value.find(
+    (item) => String(item._id ?? "").trim() === form.subjectId
+  );
+  const candidate = row ? providerCandidateOf(row) : null;
+  form.name = candidate?.name ?? "";
+  form.subjectRole = candidate?.subtitle ?? "";
+  void checkSubjectEnrollment();
+}
+
+/* Changing the service can take the chosen person out of the list. Leaving a
+   selection that is no longer on screen is how a save ends up naming somebody
+   the operator cannot see. */
+function onProviderServiceChanged() {
+  if (!form.subjectId) return;
+  const stillThere = providerRows.value.some(
+    (item) => String(item._id ?? "").trim() === form.subjectId
+  );
+  if (stillThere) return;
+  form.subjectId = "";
+  form.name = "";
+  form.subjectRole = "";
+  residentConflict.value = null;
+}
+
+/* ── ADD USERS IN BULK ────────────────────────────────────────────────────
+ *
+ * ACCESS, NOT CREDENTIALS. This grants a reader group to many people at once and
+ * stops there - no face, no card, no PIN. Each person then adds their own
+ * credential from their app, which attaches to the HID user this grant created
+ * (`getProfileEnrollmentContext` reuses the existing profile identity), so
+ * nobody has to be enrolled twice.
+ *
+ * It writes through `PUT /sites/:siteId/permissions`, the one call that writes
+ * group membership, and the device users are created by the reconcile that call
+ * triggers: `provisionPermissionUser` writes `{ name, registration }` and
+ * nothing else. That is exactly "user record and group, credentials empty".
+ *
+ * THE TRAP, and the reason the saved set is fetched first: that PUT REPLACES
+ * this reader's whole assignment set. Sending only the ticked contractors would
+ * revoke every resident and every member on the door. The payload is always
+ * built from the reader's existing assignments PLUS the selection.
+ */
+const bulkDialog = ref(false);
+const bulkLoading = ref(false);
+const bulkSaving = ref(false);
+const bulkSearch = ref("");
+/** The reader's CURRENT assignments, across every category. The merge base. */
+const bulkSaved = ref<HidAssignmentState>(new Map());
+/** Who is being added now. Already-granted people are never in here. */
+const bulkSelected = ref<Set<string>>(new Set());
+
+/* NAME THE DOOR. A bulk grant is reader-scoped and the reader was chosen on the
+   screen behind two dialogs, so the confirmation says which one rather than
+   leaving the operator to remember. */
+const bulkReaderLabel = computed(() => {
+  const reader = selectedReader.value;
+  const name = String(reader?.name ?? "").trim() || "this HID reader";
+  const location = String(reader?.location ?? "").trim();
+  return location ? `${name} · ${location}` : name;
+});
+
+/** The same people the picker offers, narrowed by this dialog's own search. */
+const bulkRows = computed(() => {
+  const rows = filterProviderMembers(
+    providerRows.value as Array<Record<string, any>>,
+    { search: bulkSearch.value }
+  );
+  return rows.map((row) => {
+    const candidate = providerCandidateOf(row);
+    const id = candidate.subjectId;
+    return {
+      subjectId: id,
+      name: candidate.name,
+      company: String(row.company ?? "").trim(),
+      service: String(row.typeLabel ?? row.type ?? "").trim(),
+      // Already on the door. Ticked and locked rather than hidden: hiding them
+      // would make "select all" look like it had missed people, and unticking
+      // one here would revoke access this dialog is not for revoking.
+      granted: bulkSaved.value.has(id),
+    };
+  });
+});
+
+const bulkSelectableRows = computed(() =>
+  bulkRows.value.filter((row) => !row.granted)
+);
+const bulkSelectedCount = computed(() => bulkSelected.value.size);
+const bulkAllSelected = computed(
+  () =>
+    bulkSelectableRows.value.length > 0 &&
+    bulkSelectableRows.value.every((row) => bulkSelected.value.has(row.subjectId))
+);
+const bulkGrantedCount = computed(
+  () => bulkRows.value.filter((row) => row.granted).length
+);
+
+const bulkEmptyText = computed(() => {
+  if (bulkLoading.value) return "Loading...";
+  if (bulkSearch.value.trim()) return "No one matches this search.";
+  if (providerServiceFilter.value) return "No one in this service can be enrolled yet.";
+  return "No service provider people can be enrolled at this site yet.";
+});
+
+function isBulkSelected(subjectId: string) {
+  return bulkSelected.value.has(subjectId);
+}
+
+function toggleBulkRow(subjectId: string, selected: boolean) {
+  const next = new Set(bulkSelected.value);
+  if (selected) next.add(subjectId);
+  else next.delete(subjectId);
+  bulkSelected.value = next;
+}
+
+/* Select-all acts on the ROWS IN FRONT OF THE OPERATOR - what the service filter
+   and the search have left - never on the whole estate. A tick box cannot
+   quietly grant a door to people who are not on screen. */
+function toggleBulkAll(selected: boolean) {
+  const next = new Set(bulkSelected.value);
+  for (const row of bulkSelectableRows.value) {
+    if (selected) next.add(row.subjectId);
+    else next.delete(row.subjectId);
+  }
+  bulkSelected.value = next;
+}
+
+/**
+ * Open the bulk dialog, after reading what the reader already holds.
+ *
+ * The saved set is fetched EVERY time rather than cached: it is the merge base
+ * for a write that replaces the reader's assignments, and a stale one would
+ * revoke whoever was granted in between.
+ */
+async function openBulkAdd() {
+  const readerId =
+    selectedReaderId.value || form.reader || readers.value[0]?._id;
+  if (!readerId) {
+    showToast("Select a HID reader before adding people in bulk.", "error");
+    return;
+  }
+  /* The permissions endpoints REQUIRE an org - `schemaHidPermissionScopeQuery`
+     has it as `required()`, unlike `createIdentity`, which falls back to the
+     site's own. Both pages that mount this component pass one, so this is a
+     guard against a 400 that would read as a server fault. */
+  if (!props.org) {
+    showToast(
+      "This screen cannot grant access in bulk without an organization.",
+      "error"
+    );
+    return;
+  }
+  bulkSearch.value = "";
+  bulkSelected.value = new Set();
+  bulkSaved.value = new Map();
+  bulkDialog.value = true;
+  bulkLoading.value = true;
+  try {
+    if (!providersLoaded.value) await loadProviderCandidates();
+    const response = await getSitePermissions(props.site, props.org, readerId);
+    bulkSaved.value = seedAssignments(response?.data?.assignments ?? []);
+  } catch (error: unknown) {
+    // Closed rather than left open on an empty merge base: saving from here
+    // would send only the ticked people and revoke everybody else.
+    bulkDialog.value = false;
+    showToast(
+      apiReason(error) || "Unable to read this reader's current access.",
+      "error"
+    );
+  } finally {
+    bulkLoading.value = false;
+  }
+}
+
+/** Grant the ticked people, keeping everyone the reader already admits. */
+async function saveBulkAdd() {
+  if (bulkSaving.value || !bulkSelected.value.size) return;
+  const readerId =
+    selectedReaderId.value || form.reader || readers.value[0]?._id;
+  if (!readerId) {
+    showToast("Select a HID reader before adding people in bulk.", "error");
+    return;
+  }
+
+  bulkSaving.value = true;
+  try {
+    // Seeded from what the server holds, so every category the reader already
+    // admits survives this write.
+    let draft: HidAssignmentState = new Map(bulkSaved.value);
+    for (const subjectId of bulkSelected.value) {
+      draft = setAssignment(
+        draft,
+        bulkSaved.value,
+        subjectId,
+        // A provider employee's grant is stored under the STAFF category: core's
+        // `permissionSubjectOfIdentity` reads the `member` link and cannot see
+        // this dropdown, and that category's subject list already includes these
+        // people. See `permissionCategoryOf`.
+        permissionCategoryOf("service_provider_staff") as THidPermissionCategory,
+        true
+      );
+    }
+    const added = bulkSelected.value.size;
+    await updateSitePermissions(
+      props.site,
+      props.org,
+      readerId,
+      toAssignmentPayload(draft)
+    );
+    // Both dialogs close and the list is re-read: the reconcile has just created
+    // a HID user for each person, so the roster behind this dialog is stale.
+    bulkDialog.value = false;
+    formDialog.value = false;
+    await loadUsers();
+    showToast(
+      `${added} ${added === 1 ? "person" : "people"} can now use this reader. `
+        + "They add their own face, QR or PIN from their app.",
+      "success"
+    );
+  } catch (error: unknown) {
+    showToast(
+      apiReason(error) || "Unable to give these people access to this reader.",
+      "error"
+    );
+  } finally {
+    bulkSaving.value = false;
+  }
+}
+
 /**
  * Switching type clears the chosen subject, and nothing else.
  *
@@ -1372,15 +1973,20 @@ function loadMoreMembers() {
  * choice, so they clear with it.
  */
 async function onSubjectCategoryChanged() {
-  REMEMBERED_SUBJECT_CATEGORY.value = form.subjectCategory;
+  REMEMBERED_SUBJECT_CATEGORY.value = form.subjectCategory as HidEnrolmentSubject;
   form.subjectId = "";
   form.subjectRole = "";
   form.name = "";
   residentConflict.value = null;
 
-  if (!isResidentSubject.value && !membersLoaded.value) {
+  // Each list is fetched on first use and then kept, so flipping between the
+  // three options costs one request each rather than one per flip.
+  if (isMemberSubject.value && !membersLoaded.value) {
     await loadMemberCandidates();
   }
+  if (isProviderSubject.value && !providersLoaded.value) {
+    await loadProviderCandidates();
+  }
 }
 
 /* The staff equivalent of `onResidentChanged`. */
@@ -1939,7 +2545,9 @@ async function openEnroll() {
   // the request must not delay it, and the picker carries its own loading
   // placeholder. Fresh each opening, because staff change between them.
   resetMemberCandidates();
-  if (!isResidentSubject.value) await loadMemberCandidates();
+  resetProviderCandidates();
+  if (isMemberSubject.value) await loadMemberCandidates();
+  if (isProviderSubject.value) await loadProviderCandidates();
 }
 
 async function openEdit(user: HidUser) {
@@ -1961,10 +2569,19 @@ async function openEdit(user: HidUser) {
   removePinRequested.value = false;
   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".
+   */
   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 || ""
@@ -2081,6 +2698,8 @@ async function saveUser() {
     : !selectedUser.value && !form.subjectId
     ? isResidentSubject.value
       ? "a resident"
+      : isProviderSubject.value
+      ? "a person"
       : "a member"
     : !form.name
     ? "a name"
@@ -2139,27 +2758,7 @@ async function saveUser() {
     // an empty string as a link being removed and then refuses the write for
     // having no subject at all. Omitting the keys is what makes it keep the
     // subject the record already has.
-    const subjectLink = form.subjectId
-      ? {
-          person: form.subjectCategory === "resident" ? form.subjectId : "",
-          member:
-            form.subjectCategory === "property_management"
-              ? form.subjectId
-              : "",
-          serviceProvider:
-            form.subjectCategory === "service_provider" ? form.subjectId : "",
-          type: (form.subjectCategory === "resident"
-            ? "resident"
-            : form.subjectCategory === "service_provider"
-            ? "contractor"
-            : "staff") as
-            | "resident"
-            | "staff"
-            | "contractor"
-            | "visitor"
-            | "unknown",
-        }
-      : {};
+    const subjectLink = subjectLinkOf(form.subjectCategory, form.subjectId);
 
     const payload = {
       hidUserId: String(hidUser.id),
@@ -3283,6 +3882,47 @@ watch(selectedReaderId, (value) => {
   color: var(--err);
 }
 
+/* The bulk button and the sentence that says what it does. Stacked rather than
+   side by side: the sentence is the part that stops somebody expecting this to
+   enrol faces, so it must not be squeezed into a margin at narrow widths. */
+.hid-bulk-cta {
+  display: flex;
+  flex-direction: column;
+  align-items: flex-start;
+  gap: 4px;
+}
+
+.hid-bulk-cta .field-hint {
+  margin: 0;
+}
+
+/* Checkbox column only as wide as the control, so the three columns that carry
+   meaning keep the width. */
+.hid-bulk-table__check {
+  width: 44px;
+  padding-right: 0 !important;
+}
+
+.hid-bulk-table :deep(th) {
+  font-size: 12px;
+  font-weight: 700;
+  color: var(--muted);
+  white-space: nowrap;
+}
+
+.hid-bulk-table :deep(td) {
+  font-size: 13px;
+}
+
+/* Why this row cannot be unticked, on the row itself. A disabled checkbox with
+   no reason beside it reads as a broken control. */
+.hid-bulk-granted {
+  display: block;
+  color: var(--muted);
+  font-size: 11px;
+  font-weight: 600;
+}
+
 .photo-wrap {
   display: grid;
   place-items: center;

package/composables/useServiceProvider.ts

@@ -19,10 +19,15 @@ export type TSiteProviderMember = {
   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.
+   * The person's user account. Anything acting on the PERSON needs this rather
+   * than `_id`, which identifies the membership: an access card carries it as
+   * `userId`, and HID reader access is bound by it -
+   * `resolvePermissionUserBindings` drops every subject without one.
+   *
+   * Returned from core 3.130. Before that the repository projected it and the
+   * service layer dropped it, so against an older API it is absent on every
+   * row - `providerAccountsKnown` is how the HID enrolment screen tells the two
+   * apart rather than reading an absence as "nobody has an account".
    */
   user?: string | null;
 };

package/package.json

@@ -2,7 +2,7 @@
   "name": "@7365admin1/layer-common",
   "license": "MIT",
   "type": "module",
-  "version": "4.82.1-staging.479",
+  "version": "4.82.1-staging.480",
   "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/types/site.d.ts

@@ -5,7 +5,10 @@ declare type THidQrCodeFormat = "0" | "1" | "2";
 declare type THidPermissionCategory =
   | "resident"
   | "property_management"
-  | "service_provider";
+  /** A provider COMPANY - granting one admits every active member of that org. */
+  | "service_provider"
+  /** ONE PERSON from a provider company, by their membership at this site. */
+  | "service_provider_member";
 
 declare type THidPermissionAssignment = {
   subjectId: string;
@@ -27,7 +30,10 @@ declare type THidSitePermissions = {
   counts: {
     resident: number;
     propertyManagement: number;
+    /** Provider COMPANIES granted. */
     serviceProvider: number;
+    /** Named provider people granted. Counted apart from the companies. */
+    serviceProviderMember: number;
     intercom: number;
   };
 };

package/utils/hid-enrolment-subject.ts

@@ -8,14 +8,20 @@
  * in this repo.
  */
 
-export type HidEnrolmentSubject = "resident" | "property_management";
+/**
+ * What the ENROLLING dropdown offers. Three of these four are the server's own
+ * permission categories; `service_provider_staff` is this screen's own value
+ * and deliberately not one of them - see `subjectLinkOf`.
+ */
+export type HidEnrolmentSubject =
+  | "resident"
+  | "property_management"
+  | "service_provider_staff";
 
 /**
  * The dropdown's options, in the order they are drawn.
  *
- * `title`/`value` because `AppSelect` takes that shape. A service-provider
- * option is expected next; adding it here is most of the work, since the write
- * path already maps `service_provider` onto `serviceProvider`.
+ * `title`/`value` because `AppSelect` takes that shape.
  */
 export const HID_ENROLMENT_SUBJECTS: ReadonlyArray<{
   title: string;
@@ -23,6 +29,7 @@ export const HID_ENROLMENT_SUBJECTS: ReadonlyArray<{
 }> = [
   { title: "Resident", value: "resident" },
   { title: "Member", value: "property_management" },
+  { title: "Service provider", value: "service_provider_staff" },
 ];
 
 /**
@@ -38,6 +45,10 @@ export function subjectCategoryLabel(category: unknown): string {
   const labels: Record<string, string> = {
     resident: "Resident",
     property_management: "Member",
+    // The dropdown's own value: ONE PERSON from a provider company.
+    service_provider_staff: "Service provider",
+    // The server's category, which names a COMPANY. Records in the wild carry
+    // it, and an edit must not call such a row a resident.
     service_provider: "Service provider",
     visitor: "Visitor",
   };
@@ -142,3 +153,192 @@ export function hiddenSubjectNote(count: number, noun: "resident" | "member"): s
   return `${subject} at this site ${verb} not listed:`
     + ` HID enrollment needs an app account, and ${holder} none yet.`;
 }
+
+/* ── THE LINK THAT REACHES THE DEVICE ──────────────────────────────────── */
+
+/**
+ * WHICH SUBJECT FIELD AN ENROLMENT WRITES, and what the identity is called.
+ *
+ * This is the one decision in the dialog that changes who a door lets in, so it
+ * lives here with tests rather than inline in the template's script.
+ *
+ * `service_provider_staff` links through `member`, NOT `serviceProvider`, and
+ * that is the whole design:
+ *
+ * - `serviceProvider` names a `site.service-providers` row, which is a COMPANY.
+ *   `resolvePermissionUserBindings` expands one into every active member of
+ *   that organisation with NO site filter, so granting it puts a 200-person
+ *   firm on a door that eight of them attend.
+ * - A provider employee's membership lives in `members` with `siteId` set to
+ *   this site - `members` carries a unique index on `{org, siteId, user, type}`,
+ *   so it cannot exist there without one. That makes the person site-scoped by
+ *   construction, which is the whole point.
+ *
+ * The identity `type` is `"contractor"` rather than `"staff"`, and it is load
+ * bearing on the server as well as here: core's `permissionSubjectOfIdentity`
+ * reads it to tell a contractor's `member` link from a property-management one,
+ * and files the grant under `service_provider_member` or `property_management`
+ * accordingly. It is also what the Access Permissions tabs filter on.
+ *
+ * An earlier version filed provider staff under `property_management`, since that
+ * category's subject list already accepts these rows. It worked for access and
+ * failed for identity: `permissionIdentityType` derives the identity's type from
+ * the category, so every contractor came back as `staff` - and because the
+ * reconcile rewrites the identity it finds, the `"contractor"` written here was
+ * overwritten seconds later.
+ *
+ * An empty `subjectId` returns `{}` ON PURPOSE. Sending `person: ""` is not
+ * "leave this alone", it is "clear it": the server reads an empty string as the
+ * link being removed and then refuses the write for having no subject at all.
+ */
+export function subjectLinkOf(
+  category: unknown,
+  subjectId: unknown,
+): {
+  person?: string;
+  member?: string;
+  serviceProvider?: string;
+  type?: "resident" | "staff" | "contractor";
+} {
+  const id = String(subjectId ?? "").trim();
+  if (!id) return {};
+  const of = (
+    field: "person" | "member" | "serviceProvider",
+    type: "resident" | "staff" | "contractor",
+  ) => ({
+    person: field === "person" ? id : "",
+    member: field === "member" ? id : "",
+    serviceProvider: field === "serviceProvider" ? id : "",
+    type,
+  });
+  switch (String(category ?? "")) {
+    case "resident":
+      return of("person", "resident");
+    case "service_provider_staff":
+      return of("member", "contractor");
+    case "service_provider":
+      return of("serviceProvider", "contractor");
+    default:
+      return of("member", "staff");
+  }
+}
+
+/**
+ * Which PERMISSION CATEGORY an enrolment's access grant is stored under.
+ *
+ * Mirrors `permissionSubjectOfIdentity` in core, which reads the stored links
+ * rather than this dropdown: a `member` link resolves to `property_management`
+ * whatever the identity's `type` says. Provider staff therefore share the staff
+ * category, which is correct - they are validated against the same subject list
+ * - and the identity `type` is what tells them apart on screen.
+ */
+export function permissionCategoryOf(category: unknown): string {
+  const value = String(category ?? "");
+  if (value === "resident") return "resident";
+  if (value === "service_provider") return "service_provider";
+  if (value === "service_provider_staff") return "service_provider_member";
+  return "property_management";
+}
+
+/* ── PROVIDER STAFF AS PICKER ROWS ─────────────────────────────────────── */
+
+/**
+ * Can this provider employee be enrolled?
+ *
+ * Two conditions, and both have to be checked here rather than trusted from the
+ * list. An app account, because reader access is bound by user id
+ * (`memberHasAccount`). And an ACTIVE membership: `getProviderMembersBySite`
+ * returns everyone who is not deleted, so a suspended person is in the list the
+ * Members screen draws - marked, deliberately, so the property manager can see
+ * them. Offering a suspended person a door is a different matter.
+ */
+export function providerCanEnrol(
+  row: Record<string, unknown> | null | undefined,
+): boolean {
+  if (!memberHasAccount(row)) return false;
+  return String(row?.status ?? "").trim() === "active";
+}
+
+/**
+ * How a provider employee reads in the picker: their name, their company and
+ * the service beneath it.
+ *
+ * The company comes FIRST in the subtitle. Two contractors with the same first
+ * name are common, and which firm somebody belongs to is what the property
+ * manager actually recognises them by - the service type alone ("Security")
+ * describes half the list.
+ */
+export function providerCandidateOf(row: Record<string, unknown>): {
+  subjectId: string;
+  name: string;
+  subtitle: string;
+} {
+  const text = (value: unknown) => String(value ?? "").trim();
+  const parts = [text(row.company), text(row.typeLabel)].filter(Boolean);
+  return {
+    subjectId: text(row._id),
+    name: text(row.name) || text(row.email) || "Service provider",
+    subtitle: parts.join(" · ") || text(row.role) || text(row.email) || "",
+  };
+}
+
+/**
+ * Does this list tell us who has an app account?
+ *
+ * `GET /api/service-providers/site-members` only began returning `user` in core
+ * 3.130; before that the service layer dropped it even though the repository
+ * projected it. Frontend and backend deploy separately, so this screen can run
+ * against either. Asked of the ROWS rather than of a version number: the key is
+ * present on every row or on none.
+ *
+ * It matters because the answer flips a filter from "cannot be bound to a door"
+ * to "unknown", and a screen that silently reports NOBODY can be enrolled is
+ * worse than one that offers somebody the server then refuses by name.
+ */
+export function providerAccountsKnown(
+  rows: ReadonlyArray<Record<string, unknown>>,
+): boolean {
+  return rows.some((row) => Boolean(row) && typeof row === "object" && "user" in row);
+}
+
+/**
+ * Who may be offered a door, from whatever the endpoint returned.
+ *
+ * With accounts known, both conditions apply (`providerCanEnrol`). Without them,
+ * active membership is all that can be checked here — the server still refuses
+ * anyone it cannot bind, with a message naming them, which is a better failure
+ * than an empty picker.
+ */
+export function providerEnrollableRows<T extends Record<string, unknown>>(
+  rows: ReadonlyArray<T>,
+): T[] {
+  const known = providerAccountsKnown(rows);
+  return rows.filter((row) =>
+    known ? providerCanEnrol(row) : String(row?.status ?? "").trim() === "active",
+  );
+}
+
+/* ── THE SERVICE FILTER'S "ALL" ────────────────────────────────────────── */
+
+/**
+ * WHY "ALL SERVICES" CANNOT BE THE EMPTY STRING HERE.
+ *
+ * `filterProviderMembers` reads an empty `type` as "do not filter", and the
+ * Members screen's own filter uses `value: ""` for All services - but that screen
+ * draws a Vuetify `v-select`, which renders an empty value perfectly well.
+ *
+ * `AppSelect` does not. Its `hasSingleValue` is false for `""`, so the field
+ * falls back to the placeholder, draws in the placeholder's grey, and the option
+ * is never marked as the chosen one in the menu. The filter worked; it just
+ * looked like nothing was selected and like only the real services existed.
+ *
+ * So the option carries a real value here and is translated on the way to the
+ * filter. Changing `AppSelect` instead would touch every one of its callers.
+ */
+export const HID_ALL_SERVICES = "all";
+
+/** The `type` to filter by: "" for All services, the service code otherwise. */
+export function serviceFilterOf(selected: unknown): string {
+  const value = String(selected ?? "").trim();
+  return value === HID_ALL_SERVICES ? "" : value;
+}

package/utils/hid-permission-assignments.ts

@@ -27,11 +27,19 @@
  *    through is a 400.
  */
 
-/** The three real categories. `intercom` is a candidate FILTER, never a category. */
+/**
+ * The real categories. `intercom` is a candidate FILTER, never a category.
+ *
+ * Mirrors `HID_PERMISSION_CATEGORIES` in core, and has to: `seedAssignments`
+ * DROPS a row whose category is not in this list, so a category missing here
+ * silently loses that grant from the edit state - and the save that follows,
+ * being a whole-reader replace, would revoke it.
+ */
 export const HID_PERMISSION_CATEGORIES: THidPermissionCategory[] = [
   "resident",
   "property_management",
   "service_provider",
+  "service_provider_member",
 ];
 
 export type HidAssignmentState = Map<string, { category: THidPermissionCategory; intercom: boolean }>;