@7365admin1/layer-common 4.97.1-staging.503 → 4.98.0

package/composables/useAccessManagement.ts

@@ -319,23 +319,7 @@ export default function useAccessManagement() {
     );
   }
 
-  /**
-   * `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";
-  }) {
+  function assignUser(payload: { assignees: string[]; unit: string; type: string; acm_url: string; id?: string }) {
     return useNuxtApp().$api<Record<string, any>>(
       `/api/access-management/assign-user`,
       { method: "POST", body: payload }

package/composables/useServiceProvider.ts

@@ -19,15 +19,10 @@ export type TSiteProviderMember = {
   unit?: string | null;
   unitName?: string;
   /**
-   * 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".
+   * 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;
 };

package/package.json

@@ -2,7 +2,7 @@
   "name": "@7365admin1/layer-common",
   "license": "MIT",
   "type": "module",
-  "version": "4.97.1-staging.503",
+  "version": "4.98.0",
   "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,10 +5,7 @@ declare type THidQrCodeFormat = "0" | "1" | "2";
 declare type THidPermissionCategory =
   | "resident"
   | "property_management"
-  /** 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";
+  | "service_provider";
 
 declare type THidPermissionAssignment = {
   subjectId: string;
@@ -30,10 +27,7 @@ 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,20 +8,14 @@
  * in this repo.
  */
 
-/**
- * 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";
+export type HidEnrolmentSubject = "resident" | "property_management";
 
 /**
  * The dropdown's options, in the order they are drawn.
  *
- * `title`/`value` because `AppSelect` takes that shape.
+ * `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`.
  */
 export const HID_ENROLMENT_SUBJECTS: ReadonlyArray<{
   title: string;
@@ -29,7 +23,6 @@ export const HID_ENROLMENT_SUBJECTS: ReadonlyArray<{
 }> = [
   { title: "Resident", value: "resident" },
   { title: "Member", value: "property_management" },
-  { title: "Service provider", value: "service_provider_staff" },
 ];
 
 /**
@@ -45,10 +38,6 @@ 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",
   };
@@ -153,214 +142,3 @@ 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";
-}
-
-/**
- * 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 ─────────────────────────────────────── */
-
-/**
- * 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,19 +27,11 @@
  *    through is a 400.
  */
 
-/**
- * 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.
- */
+/** The three real categories. `intercom` is a candidate FILTER, never a category. */
 export const HID_PERMISSION_CATEGORIES: THidPermissionCategory[] = [
   "resident",
   "property_management",
   "service_provider",
-  "service_provider_member",
 ];
 
 export type HidAssignmentState = Map<string, { category: THidPermissionCategory; intercom: boolean }>;
@@ -142,20 +134,11 @@ export function applySelection(
 
 /** Per-category totals for the dialog header, counted over the whole reader. */
 export function countByCategory(state: HidAssignmentState): Record<THidPermissionCategory, number> {
-  /*
-   * 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;
-  }
+  const counts = { resident: 0, property_management: 0, service_provider: 0 } as Record<
+    THidPermissionCategory,
+    number
+  >;
+  for (const value of state.values()) counts[value.category] += 1;
   return counts;
 }
 
@@ -205,55 +188,3 @@ 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;
-}