@7365admin1/layer-common 4.90.2-staging.491 → 4.90.2

package/composables/useHidReaderSelection.ts

@@ -1,50 +0,0 @@
-import {
-  EMPTY_HID_READER_CHOICE,
-  resolveHidReaderId,
-  type HidReaderChoice,
-} from "../utils/hid-reader-selection";
-
-/**
- * ONE HID READER CHOICE, SHARED BY EVERY HID SCREEN.
- *
- * Declared at MODULE scope on purpose. Each screen held its own `ref("")`, and
- * because the HID screens are separate pages the ref was rebuilt on every
- * navigation — HID Reader Users, HID Cards, Access Logs and HID QR Code each
- * reset to the first reader no matter what had just been picked next door.
- *
- * A module-scoped ref is enough because moving between those pages is a ROUTE
- * change, not a page load: the menu's items carry a `route` and
- * `NavigationItem.vue` renders them through `:to`, so vue-router handles them
- * and this module is never re-evaluated.
- *
- * Deliberately NOT persisted. `localStorage` would carry the choice through a
- * hard refresh as well, which is a real but much smaller benefit than the
- * navigation case, and it is worth adding only once somebody has felt the
- * absence. See `utils/hid-reader-selection.ts` for the staleness rule that
- * would have to hold either way.
- *
- * Intercom keeps its own reader and is not wired to this. Its question is which
- * panel you are calling, not which door you are administering, and joining them
- * would mean switching reader on Access Logs changed who you would dial.
- */
-const choice = ref<HidReaderChoice>({ ...EMPTY_HID_READER_CHOICE });
-
-export default function useHidReaderSelection() {
-  /** Remember a choice. The site travels with it; an id alone means nothing. */
-  function selectHidReader(siteId: string, readerId: string) {
-    choice.value = { siteId: String(siteId ?? ""), readerId: String(readerId ?? "") };
-  }
-
-  /**
-   * The reader this screen should show, given the readers it just loaded.
-   *
-   * Call it after the reader list arrives, and write the answer back with
-   * `selectHidReader` so the screens agree on what "current" means even when
-   * one of them had to fall back to the first reader.
-   */
-  function resolveForSite(siteId: string, readers: readonly { _id?: unknown }[]) {
-    return resolveHidReaderId(siteId, readers, choice.value);
-  }
-
-  return { choice, selectHidReader, resolveForSite };
-}

package/composables/useSiteCategory.ts

@@ -1,45 +0,0 @@
-/**
- * THE CATEGORY OF THE SITE THE USER IS CURRENTLY IN.
- *
- * One shared answer, published once by the application's layout from the site
- * it already loaded for the switcher, and read by anything that has to behave
- * differently on a commercial or industrial site - the business Add Tenant
- * form, the tenant list. Publishing it rather than re-fetching it per
- * component means no two screens can disagree about which site this is.
- *
- * READ FROM THE CUSTOMER-SITE RECORD, NOT THE SITE RECORD. Both carry a
- * `category` and `customer-site.service` keeps them equal (it writes the site
- * on create and on update), but `siteSchema` DEFAULTS the site's own copy to
- * `commercial` - so a site created without an explicit category reads back as
- * commercial there even when it is a residential estate. The customer-site
- * copy has no default: it is either the category somebody chose or nothing.
- *
- * An empty category means "not published yet" or "never set", and every
- * caller must behave as it did before this existed - never assume commercial
- * from silence.
- */
-const BUSINESS_SITE_CATEGORIES: string[] = ["commercial", "industrial"];
-
-export default function useSiteCategory() {
-  const siteCategory = useState<string>("current-site-category", () => "");
-
-  function setSiteCategory(value?: string | null) {
-    siteCategory.value = typeof value === "string" ? value : "";
-  }
-
-  /**
-   * The categories whose units are LET TO A BUSINESS rather than lived in.
-   *
-   * These are the sites where a unit has an owner, an occupier and often a
-   * person in charge who is neither, so they are the sites that ask for a
-   * tenant's standing and print it back (see `OCCUPANCY_ROLE_OPTIONS`).
-   *
-   * The category never changes what the APPLICATION is called: the rail says
-   * Property Management on every site it serves.
-   */
-  const isBusinessSite = computed(() =>
-    BUSINESS_SITE_CATEGORIES.includes(siteCategory.value),
-  );
-
-  return { siteCategory, isBusinessSite, setSiteCategory };
-}

package/pages/[org]/[site]/access-mgmt/hid-qr-code/index.vue

@@ -1,23 +0,0 @@
-<template>
-  <v-container fluid>
-    <HidEnabledGate
-      :site="siteId"
-      :org="orgId"
-      message="Enable HID as a service for this site before generating a QR code."
-    >
-      <HidProfileQrCode :site="siteId" />
-    </HidEnabledGate>
-  </v-container>
-</template>
-
-<script setup lang="ts">
-definePageMeta({
-  layout: "default",
-  middleware: ["01-auth", "02-org"],
-  memberOnly: true,
-});
-
-const route = useRoute();
-const siteId = computed(() => String(route.params.site ?? ""));
-const orgId = computed(() => String(route.params.org ?? ""));
-</script>

package/utils/hid-enrolment-subject.ts

@@ -1,344 +0,0 @@
-/**
- * WHO A HID ENROLMENT IS FOR — the pure decisions behind the subject picker.
- *
- * `HidUserEnrollment.vue` can enrol a resident or a staff member. The write path
- * always carried both (`subjectLink` maps them onto `person` or `member`); what
- * was missing was a way to choose. These are the parts of that choice worth
- * testing on their own, kept here because a `.vue` component has no test harness
- * 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";
-
-/**
- * The dropdown's options, in the order they are drawn.
- *
- * `title`/`value` because `AppSelect` takes that shape.
- */
-export const HID_ENROLMENT_SUBJECTS: ReadonlyArray<{
-  title: string;
-  value: HidEnrolmentSubject;
-}> = [
-  { title: "Resident", value: "resident" },
-  { title: "Member", value: "property_management" },
-  { title: "Service provider", value: "service_provider_staff" },
-];
-
-/**
- * What an EDIT calls the subject it is already attached to.
- *
- * Wider than the dropdown on purpose. An identity's category cannot change after
- * it is created, so an edit states it rather than offering it — and the records
- * in the wild include `service_provider`, which the dropdown does not offer yet
- * but `openEdit` does resolve. Falling back to the first option would label a
- * contractor "Resident", which is worse than saying nothing useful.
- */
-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",
-  };
-  return labels[String(category ?? "")] ?? "Unknown";
-}
-
-/**
- * One page of `GET /api/members`, read defensively.
- *
- * `paginate` puts `{ items, pages }` at the root, but `items` sits under `data`
- * on some of this product's endpoints, so both are read — the same allowance
- * `readCandidatePage` makes. A response that carries neither is an empty page
- * rather than a thrown error: an empty staff picker with a placeholder beats a
- * broken dialog.
- */
-export function readMemberPage(response: unknown): {
-  items: Record<string, unknown>[];
-  pages: number;
-  total: number;
-} {
-  const source = (response && typeof response === "object" ? response : {}) as Record<string, unknown>;
-  const nested = (source.data && typeof source.data === "object" ? source.data : {}) as Record<string, unknown>;
-  const raw = Array.isArray(source.items)
-    ? source.items
-    : Array.isArray(nested.items)
-      ? nested.items
-      : [];
-  const pages = Number(source.pages ?? nested.pages ?? 1);
-  const items = raw.filter((row): row is Record<string, unknown> => Boolean(row) && typeof row === "object");
-  /*
-   * `total` drives "showing 10 of 23" and the Load more button. It falls back to
-   * the page's own length, not to zero, so a response without it simply reads as
-   * "this is everything" — a missing count must never make the button offer a
-   * page that is not there.
-   */
-  const total = Number(source.total ?? nested.total ?? items.length);
-  return {
-    items,
-    pages: Number.isFinite(pages) && pages > 0 ? Math.floor(pages) : 1,
-    total: Number.isFinite(total) && total >= 0 ? Math.floor(total) : items.length,
-  };
-}
-
-/**
- * Can this member actually be enrolled?
- *
- * Reader access is bound by USER id — `resolvePermissionUserBindings` in
- * `iservice365-core` drops every subject without one — so a member with no app
- * account cannot be given access and is not a candidate. The id arrives as a
- * string from JSON but may be an object if a caller passes a raw document, so
- * both are read rather than trusting the shape.
- */
-export function memberHasAccount(row: Record<string, unknown> | null | undefined): boolean {
-  const user = row?.user;
-  if (!user) return false;
-  if (typeof user === "object") {
-    const id = (user as { _id?: unknown; toString?: () => string })._id ?? user;
-    return Boolean(String(id ?? "").trim());
-  }
-  return Boolean(String(user).trim());
-}
-
-/**
- * How a member reads in the picker: their name, and their role beneath it.
- *
- * THE ACCOUNT'S NAME FIRST, then the membership's. The two diverge — a
- * membership is created with whatever name was typed at invite time, and the
- * person may have set their own on the account since — and the account name is
- * the one they are known by. `userName` comes from the members endpoint's own
- * lookup into `users`; a member with no account has none, but such a row is not
- * a candidate anyway (`memberHasAccount`).
- *
- * Every step falls back, because a row with no name at all still has to be
- * selectable rather than blank, or it cannot be told apart from the next one.
- */
-export function memberCandidateOf(row: Record<string, unknown>): {
-  subjectId: string;
-  name: string;
-  subtitle: string;
-} {
-  const text = (value: unknown) => String(value ?? "").trim();
-  return {
-    subjectId: text(row._id),
-    name: text(row.userName) || text(row.name) || text(row.email) || "Member",
-    subtitle: text(row.roleName) || text(row.email) || "",
-  };
-}
-
-/**
- * Why somebody the operator can see elsewhere is not in this list.
- *
- * Left unexplained, an absence reads as a broken screen — the same reason the
- * resident cascade carries `unitResidentNote`. Returns "" when there is nothing
- * to say, so the caller can render it unconditionally.
- */
-export function hiddenSubjectNote(count: number, noun: "resident" | "member"): string {
-  if (!Number.isFinite(count) || count <= 0) return "";
-  const whole = Math.floor(count);
-  const subject = whole === 1 ? `1 ${noun}` : `${whole} ${noun}s`;
-  const verb = whole === 1 ? "is" : "are";
-  const holder = whole === 1 ? "that person has" : "they have";
-  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

@@ -1,198 +0,0 @@
-/**
- * WHO IS ASSIGNED TO A HID READER — the editing model behind the permissions
- * dialog.
- *
- * This is the step that actually grants access. Enrolling a person gives the
- * reader a face, a card or a PIN it can RECOGNISE; it puts nobody in the group
- * the access rule is attached to, so a recognised person is still refused at
- * the door (access log event 6). `PUT /sites/:siteId/permissions` is the only
- * call in the system that writes that group membership.
- *
- * Two contracts make this file necessary rather than inlining the logic in the
- * component:
- *
- * 1. **The PUT REPLACES the whole assignment set for the reader.** The server
- *    keeps other readers' rows and overwrites this reader's with exactly what
- *    is sent. The candidate list, however, is fetched ONE CATEGORY AT A TIME.
- *    Saving from the tab in front of you while sending only that tab's people
- *    would silently revoke every resident if you were looking at the service
- *    providers tab. So the edit state is held for the whole reader and the
- *    payload is always built from all of it.
- *
- * 2. **The body schema accepts three keys and nothing else.**
- *    `hidPermissionAssignmentSchema` is `{ subjectId, category, intercom }`,
- *    and Joi rejects unknown keys rather than stripping them. The candidate
- *    rows carry `name`, `subtitle`, `location` and friends for display, so the
- *    payload has to be narrowed deliberately — passing a candidate straight
- *    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.
- */
-export const HID_PERMISSION_CATEGORIES: THidPermissionCategory[] = [
-  "resident",
-  "property_management",
-  "service_provider",
-  "service_provider_member",
-];
-
-export type HidAssignmentState = Map<string, { category: THidPermissionCategory; intercom: boolean }>;
-
-/** Body row for `updateSitePermissions` — exactly the keys Joi allows. */
-export type HidAssignmentPayload = {
-  subjectId: string;
-  category: THidPermissionCategory;
-  intercom: boolean;
-};
-
-function isRealCategory(value: unknown): value is THidPermissionCategory {
-  return HID_PERMISSION_CATEGORIES.includes(value as THidPermissionCategory);
-}
-
-/**
- * The reader's CURRENT assignments, as the edit state.
- *
- * Seeded from `getSitePermissions`, which returns every category at once —
- * that is what makes a whole-reader payload possible from a one-category view.
- * Rows with an unrecognised category are dropped rather than carried: sending
- * one back fails the enum check and takes the entire save with it.
- */
-export function seedAssignments(
-  assignments: readonly THidPermissionAssignment[] | undefined | null,
-): HidAssignmentState {
-  const state: HidAssignmentState = new Map();
-  if (!Array.isArray(assignments)) return state;
-  for (const assignment of assignments) {
-    const subjectId = String(assignment?.subjectId ?? "");
-    if (!subjectId || !isRealCategory(assignment?.category)) continue;
-    state.set(subjectId, {
-      category: assignment.category,
-      intercom: assignment.intercom === true,
-    });
-  }
-  return state;
-}
-
-/**
- * Add or remove one person.
- *
- * `saved` is the state the dialog opened with, and it is consulted for one
- * reason: the `intercom` flag. Nothing here edits that flag, but
- * `userHasSiteIntercomPermission` reads it off these same rows, so it must
- * survive a round trip through the checkbox.
- *
- * - **Untick then save** drops it, which is right — an unassigned person
- *   holding a dangling intercom right would keep answering the door panel
- *   after losing the door.
- * - **Untick then re-tick, without saving** must restore it. Removing from the
- *   draft forgets the flag, so re-adding recovers it from `saved`; otherwise a
- *   misclick corrected a second later would silently revoke intercom on the
- *   next save, with nothing on screen to show it had happened.
- */
-export function setAssignment(
-  state: HidAssignmentState,
-  saved: HidAssignmentState,
-  subjectId: string,
-  category: THidPermissionCategory,
-  selected: boolean,
-): HidAssignmentState {
-  const next: HidAssignmentState = new Map(state);
-  const id = String(subjectId ?? "");
-  if (!id || !isRealCategory(category)) return next;
-  if (!selected) {
-    next.delete(id);
-    return next;
-  }
-  const intercom = next.get(id)?.intercom ?? saved.get(id)?.intercom ?? false;
-  next.set(id, { category, intercom: intercom === true });
-  return next;
-}
-
-/** The whole reader's assignments, narrowed to the three keys the API accepts. */
-export function toAssignmentPayload(state: HidAssignmentState): HidAssignmentPayload[] {
-  return [...state.entries()].map(([subjectId, value]) => ({
-    subjectId,
-    category: value.category,
-    intercom: value.intercom === true,
-  }));
-}
-
-/**
- * The server sends `selected` with each candidate, describing what is SAVED.
- * Once the dialog is open the local edit state is the truth, so the flag is
- * recomputed rather than trusted — otherwise paging or searching would redraw
- * a row with the saved value and quietly discard an unsaved tick.
- */
-export function applySelection(
-  candidates: readonly THidPermissionCandidate[] | undefined | null,
-  state: HidAssignmentState,
-): THidPermissionCandidate[] {
-  if (!Array.isArray(candidates)) return [];
-  return candidates.map((candidate) => ({
-    ...candidate,
-    selected: state.has(String(candidate?.subjectId ?? "")),
-  }));
-}
-
-/** 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;
-  return counts;
-}
-
-/** Has anything changed since the dialog opened? Drives the Save button. */
-export function hasChanges(saved: HidAssignmentState, draft: HidAssignmentState): boolean {
-  if (saved.size !== draft.size) return true;
-  for (const [subjectId, value] of draft) {
-    const before = saved.get(subjectId);
-    if (!before) return true;
-    if (before.category !== value.category) return true;
-    if (before.intercom !== value.intercom) return true;
-  }
-  return false;
-}
-
-/**
- * What a listing response tells us: the rows, and how many pages exist.
- *
- * It deliberately does NOT return the current page, and the caller must keep
- * owning that. `paginate` in `@7365admin1/node-server-utils` returns only
- * `{ items, pages, pageRange }` — it never echoes the page it was asked for. A
- * caller that read one back therefore got a default on every fetch and pinned
- * itself to page one, so the pager moved and the rows never did.
- *
- * `items` sits at the root on some of these endpoints and under `data` on
- * others, so both are read.
- */
-export function readCandidatePage(response: unknown): {
-  items: THidPermissionCandidate[];
-  pages: number;
-  pageRange: string;
-} {
-  const source = (response && typeof response === "object" ? response : {}) as Record<string, unknown>;
-  const nested = (source.data && typeof source.data === "object" ? source.data : {}) as Record<string, unknown>;
-  const items = Array.isArray(source.items)
-    ? source.items
-    : Array.isArray(nested.items)
-      ? nested.items
-      : [];
-  const pages = Number(source.pages ?? nested.pages ?? 1);
-  // `paginate` builds this ("1-10 of 37") and the table renders it verbatim.
-  // Without it the pager draws its placeholder, "-- - -- of --".
-  const pageRange = String(source.pageRange ?? nested.pageRange ?? "");
-  return {
-    items: items as THidPermissionCandidate[],
-    pages: Number.isFinite(pages) && pages > 0 ? pages : 1,
-    pageRange,
-  };
-}