@7365admin1/layer-common 4.35.1-staging.385 → 4.37.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +16 -4
- package/assets/css/primitives.css +0 -43
- package/components/AccessCardAddForm.vue +4 -5
- package/components/AccessCardAssignToUnitForm.vue +2 -3
- package/components/AccessCardPreviewDialog.vue +3 -4
- package/components/AppSelect.vue +3 -77
- package/components/CameraForm.vue +6 -20
- package/components/DashboardMain.vue +60 -66
- package/components/Dialog/UpdateMoreAction.vue +1 -11
- package/components/DocumentForm.vue +112 -407
- package/components/DocumentManagement.vue +12 -213
- package/components/EntryPass/QrTemplatePreview.vue +25 -21
- package/components/EntryPassInformation.vue +24 -119
- package/components/Facility/BookingSetup.vue +0 -63
- package/components/HidAccessLogDashboard.vue +17 -74
- package/components/HidIntercomManagement.vue +14 -180
- package/components/HidQrCodeConfiguration.vue +195 -17
- package/components/HidReaderManagement.vue +0 -398
- package/components/HidReaderUserRoster.vue +3 -44
- package/components/HidUserEnrollment.vue +155 -845
- package/components/InvitationClientForm.vue +1 -19
- package/components/Layout/NavigationDrawer.vue +1 -4
- package/components/NotificationBell.vue +7 -59
- package/components/RolePermissionFormCreate.vue +3 -4
- package/components/RolePermissionFormPreviewUpdate.vue +5 -12
- package/components/RolePermissionMain.vue +0 -1
- package/components/ServiceProviderInvitationPrompt.vue +155 -0
- package/components/ServiceProviderMain.vue +30 -178
- package/components/VisitorForm.vue +0 -12
- package/components/VisitorManagement.vue +10 -285
- package/components/VisitorSocketPopUp.vue +1 -2
- package/composables/useANPRSettings.ts +15 -45
- package/composables/useAccessManagement.ts +0 -5
- package/composables/useCleaningPermission.ts +0 -2
- package/composables/useCommonPermission.ts +0 -32
- package/composables/useDocument.ts +0 -7
- package/composables/useFacility.ts +0 -11
- package/composables/useHidAmico.ts +0 -159
- package/composables/useHidNavigation.ts +1 -25
- package/composables/usePeople.ts +0 -19
- package/composables/usePropertyPermission.ts +0 -19
- package/composables/useSecurityPermission.ts +0 -19
- package/composables/useServiceProvider.ts +0 -3
- package/composables/useServiceProviderInvitation.ts +3 -101
- package/composables/useSiteEntryPassSettings.ts +0 -26
- package/composables/useWebUsb.ts +11 -14
- package/package.json +2 -2
- package/pages/[org]/[site]/access-mgmt/administrator/index.vue +1 -1
- package/pages/[org]/[site]/access-mgmt/hid-cards/index.vue +1 -1
- package/pages/[org]/[site]/access-mgmt/hid-readers/index.vue +1 -1
- package/plugins/API.ts +0 -11
- package/types/document.d.ts +0 -14
- package/types/facility.d.ts +0 -4
- package/types/people.d.ts +1 -28
- package/utils/module-routes.ts +1 -8
- package/utils/nav-sections.ts +2 -8
- package/utils/notification-target.ts +8 -277
- package/utils/permission-labels.ts +2 -20
- package/components/ClientInvitations.vue +0 -291
- package/components/HidAccessPermissions.vue +0 -424
- package/components/HidProfileQrCode.vue +0 -332
- package/composables/useHidReaderSelection.ts +0 -50
- package/composables/useSiteCategory.ts +0 -45
- package/pages/[org]/[site]/access-mgmt/hid-qr-code/index.vue +0 -23
- package/utils/dashboard-widget-prefs.ts +0 -54
- package/utils/hid-permission-assignments.ts +0 -190
- package/utils/hid-reader-selection.ts +0 -52
- package/utils/occupancy-role.ts +0 -109
- package/utils/sp-inviter-row.ts +0 -97
|
@@ -1,52 +0,0 @@
|
|
|
1
|
-
/**
|
|
2
|
-
* WHICH HID READER THE OPERATOR IS WORKING ON — the one rule behind it.
|
|
3
|
-
*
|
|
4
|
-
* Every HID screen used to hold its own `ref("")` and default it to
|
|
5
|
-
* `readers[0]`, so picking HID 2 on HID Reader Users and clicking through to
|
|
6
|
-
* HID Cards put you back on HID 1. They are separate PAGES, so the component
|
|
7
|
-
* unmounted and the ref was rebuilt from scratch every time — there was no way
|
|
8
|
-
* to make a choice stick. "I am working on HID 2" is a mode, not a per-screen
|
|
9
|
-
* preference.
|
|
10
|
-
*
|
|
11
|
-
* Navigation between those pages is a route change rather than a page load
|
|
12
|
-
* (`NavigationItem.vue` renders the menu's `route` through `:to`), so the
|
|
13
|
-
* module-scoped ref in `useHidReaderSelection` survives it. This file holds the
|
|
14
|
-
* part worth testing: deciding whether a remembered choice may still be used.
|
|
15
|
-
*/
|
|
16
|
-
|
|
17
|
-
export type HidReaderChoice = { siteId: string; readerId: string };
|
|
18
|
-
|
|
19
|
-
/** Anything with an id — the four screens all carry a different reader shape. */
|
|
20
|
-
type ReaderLike = { _id?: unknown };
|
|
21
|
-
|
|
22
|
-
export const EMPTY_HID_READER_CHOICE: HidReaderChoice = { siteId: "", readerId: "" };
|
|
23
|
-
|
|
24
|
-
/**
|
|
25
|
-
* The reader a screen should show, given what this site actually has.
|
|
26
|
-
*
|
|
27
|
-
* A remembered id is honoured ONLY when it belongs to this site and is still in
|
|
28
|
-
* the list. That single condition covers every way it goes stale:
|
|
29
|
-
*
|
|
30
|
-
* - the operator switched site, so the id belongs to a site they have left
|
|
31
|
-
* - the reader was deleted or deactivated since they chose it
|
|
32
|
-
* - nothing has been chosen yet
|
|
33
|
-
*
|
|
34
|
-
* In all three the first reader is returned instead. The alternative — using
|
|
35
|
-
* the id anyway — sends requests for a reader the site does not own, which come
|
|
36
|
-
* back empty and read on screen as a reader with no users, no cards and no
|
|
37
|
-
* logs, rather than as the mistake it is.
|
|
38
|
-
*/
|
|
39
|
-
export function resolveHidReaderId(
|
|
40
|
-
siteId: string,
|
|
41
|
-
readers: readonly ReaderLike[] | null | undefined,
|
|
42
|
-
choice: HidReaderChoice = EMPTY_HID_READER_CHOICE,
|
|
43
|
-
): string {
|
|
44
|
-
const ids = (Array.isArray(readers) ? readers : [])
|
|
45
|
-
.map((reader) => String(reader?._id ?? ""))
|
|
46
|
-
.filter(Boolean);
|
|
47
|
-
|
|
48
|
-
if (choice.siteId === String(siteId ?? "") && ids.includes(choice.readerId)) {
|
|
49
|
-
return choice.readerId;
|
|
50
|
-
}
|
|
51
|
-
return ids[0] ?? "";
|
|
52
|
-
}
|
package/utils/occupancy-role.ts
DELETED
|
@@ -1,109 +0,0 @@
|
|
|
1
|
-
/**
|
|
2
|
-
* OWNER / OCCUPANT / PERSON IN CHARGE - the three standings a business
|
|
3
|
-
* tenancy has, and everything the product says about them.
|
|
4
|
-
*
|
|
5
|
-
* One list, because three screens read it: the form that asks the question
|
|
6
|
-
* (`PeopleFormMgmt`), the list and preview that print the answer back, and
|
|
7
|
-
* the row menu that reassigns it (`people-mgmt`). The values are the ones the
|
|
8
|
-
* server stores and validates - `OccupancyRoles` in core's `person.model.ts`
|
|
9
|
-
* - so a value added on one side has to be added on the other.
|
|
10
|
-
*/
|
|
11
|
-
export const OCCUPANCY_ROLE_OPTIONS: TOccupancyRoleOption[] = [
|
|
12
|
-
{
|
|
13
|
-
value: "owner",
|
|
14
|
-
title: "Owner",
|
|
15
|
-
action: "Assign Owner",
|
|
16
|
-
prompt: "Assign Owner",
|
|
17
|
-
description:
|
|
18
|
-
"The legal titleholder or primary deed owner of the property.",
|
|
19
|
-
},
|
|
20
|
-
{
|
|
21
|
-
value: "occupant",
|
|
22
|
-
title: "Occupant",
|
|
23
|
-
action: "Assign Occupant",
|
|
24
|
-
prompt: "Assign Occupant",
|
|
25
|
-
description:
|
|
26
|
-
"The person currently living in, renting, or utilizing the physical unit.",
|
|
27
|
-
},
|
|
28
|
-
{
|
|
29
|
-
value: "person-in-charge",
|
|
30
|
-
title: "Person in Charge",
|
|
31
|
-
action: "Assign Person in Charge",
|
|
32
|
-
prompt: "Assign Person in Charge (PIC)",
|
|
33
|
-
description:
|
|
34
|
-
"The designated manager responsible for maintenance, emergencies, and daily operations.",
|
|
35
|
-
},
|
|
36
|
-
];
|
|
37
|
-
|
|
38
|
-
/**
|
|
39
|
-
* The same three, in the order the ROW MENU draws them, which is not the
|
|
40
|
-
* order the form's radio does. Derived rather than re-typed so the wording
|
|
41
|
-
* cannot drift between the two.
|
|
42
|
-
*/
|
|
43
|
-
export const OCCUPANCY_ROLE_ACTIONS: TOccupancyRoleOption[] = (
|
|
44
|
-
["person-in-charge", "owner", "occupant"] as TOccupancyRole[]
|
|
45
|
-
).map(
|
|
46
|
-
(value) =>
|
|
47
|
-
OCCUPANCY_ROLE_OPTIONS.find(
|
|
48
|
-
(option) => option.value === value,
|
|
49
|
-
) as TOccupancyRoleOption,
|
|
50
|
-
);
|
|
51
|
-
|
|
52
|
-
/**
|
|
53
|
-
* The label for a stored role, or "" for a person who was never asked - which
|
|
54
|
-
* is everyone on a residential site and everyone saved before the question
|
|
55
|
-
* existed. Callers decide what to print instead; nobody should print a raw
|
|
56
|
-
* `person-in-charge` at a user.
|
|
57
|
-
*/
|
|
58
|
-
export function occupancyRoleLabel(role?: string | null): string {
|
|
59
|
-
return (
|
|
60
|
-
OCCUPANCY_ROLE_OPTIONS.find((option) => option.value === role)?.title ?? ""
|
|
61
|
-
);
|
|
62
|
-
}
|
|
63
|
-
|
|
64
|
-
/**
|
|
65
|
-
* Does this person hold OWNER at their unit?
|
|
66
|
-
*
|
|
67
|
-
* The role when there is one, `isOwner` when there is not - the same test the
|
|
68
|
-
* server applies (`holdsUnitOwner` in core's `unit-owner.util.ts`). A person
|
|
69
|
-
* recorded before the role existed carries only the flag, and the people list
|
|
70
|
-
* already prints them as "Owner".
|
|
71
|
-
*/
|
|
72
|
-
export function holdsUnitOwner(person?: {
|
|
73
|
-
occupancyRole?: string | null;
|
|
74
|
-
isOwner?: boolean;
|
|
75
|
-
}): boolean {
|
|
76
|
-
if (!person) return false;
|
|
77
|
-
|
|
78
|
-
if (person.occupancyRole) return person.occupancyRole === "owner";
|
|
79
|
-
|
|
80
|
-
return person.isOwner === true;
|
|
81
|
-
}
|
|
82
|
-
|
|
83
|
-
/**
|
|
84
|
-
* MUST THIS PERSON HAND THE UNIT OVER BEFORE THEY CAN BE DEACTIVATED?
|
|
85
|
-
*
|
|
86
|
-
* The owner of a unit does not leave while they still own it - the standing
|
|
87
|
-
* moves to another tenant at the same block, level and unit first.
|
|
88
|
-
*
|
|
89
|
-
* Keyed to the ROLE and never to `isOwner`, exactly as the server keys it
|
|
90
|
-
* (`mustHandOverBeforeDeactivating` in core): the flag is on every resident in
|
|
91
|
-
* the estate, and no residential screen can change it, so a rule keyed to it
|
|
92
|
-
* would trap records that can never satisfy it.
|
|
93
|
-
*/
|
|
94
|
-
export function mustHandOverBeforeDeactivating(person?: {
|
|
95
|
-
occupancyRole?: string | null;
|
|
96
|
-
}): boolean {
|
|
97
|
-
return person?.occupancyRole === "owner";
|
|
98
|
-
}
|
|
99
|
-
|
|
100
|
-
/**
|
|
101
|
-
* Why a deactivation was held back. The SERVER carries the enforcing copy of
|
|
102
|
-
* this rule and of these words (core `unit-owner.util.ts`); this one exists so
|
|
103
|
-
* the console can say it before the round trip rather than after.
|
|
104
|
-
*/
|
|
105
|
-
export function ownerHandoverRequiredMessage(name?: string): string {
|
|
106
|
-
const who = name?.trim() ? `"${name.trim()}"` : "This person";
|
|
107
|
-
|
|
108
|
-
return `${who} is the owner of this unit. Assign the owner role to another tenant at the same block, level and unit before deactivating them.`;
|
|
109
|
-
}
|
package/utils/sp-inviter-row.ts
DELETED
|
@@ -1,97 +0,0 @@
|
|
|
1
|
-
/**
|
|
2
|
-
* The inviting organisation's view of one service-provider invitation, in
|
|
3
|
-
* words. Pure, so it is tested without a browser.
|
|
4
|
-
*
|
|
5
|
-
* The company name comes from the server (`companyName`: the company that
|
|
6
|
-
* accepted, or the new company's name a sign-up invitation carried). While an
|
|
7
|
-
* invitation is unanswered the company is genuinely not known yet - the cell
|
|
8
|
-
* says so instead of drawing "-".
|
|
9
|
-
*/
|
|
10
|
-
|
|
11
|
-
export type TSentInvitation = {
|
|
12
|
-
status?: string;
|
|
13
|
-
viewStatus?: string;
|
|
14
|
-
statusLabel?: string;
|
|
15
|
-
companyName?: string;
|
|
16
|
-
metadata?: Record<string, any>;
|
|
17
|
-
invitedByName?: string;
|
|
18
|
-
invitedAt?: string | null;
|
|
19
|
-
createdAt?: string | null;
|
|
20
|
-
answeredAt?: string | null;
|
|
21
|
-
onSite?: boolean;
|
|
22
|
-
};
|
|
23
|
-
|
|
24
|
-
const ANSWERED: Record<string, string> = {
|
|
25
|
-
complete: "Accepted",
|
|
26
|
-
declined: "Declined",
|
|
27
|
-
cancelled: "Cancelled",
|
|
28
|
-
rejected: "Not approved",
|
|
29
|
-
expired: "Expired",
|
|
30
|
-
};
|
|
31
|
-
|
|
32
|
-
type TNatureOption = { title?: string; value?: string };
|
|
33
|
-
|
|
34
|
-
/**
|
|
35
|
-
* The service type in words: the org's free-text nature if it gave one,
|
|
36
|
-
* else the label from the nature-of-business list, else the raw stored code
|
|
37
|
-
* ("security_agency") as a last resort. `useLocal` can hand back a plain
|
|
38
|
-
* array or a ref-like `{ value }` wrapper - read whichever shape was passed.
|
|
39
|
-
*
|
|
40
|
-
* `nature` is NOT always free text: both `_getServiceProviders` and the
|
|
41
|
-
* `customer.sites`-derived `getServiceProvidersForSite` aggregations in
|
|
42
|
-
* @7365admin1/core set it to `organization.nature`, the SAME raw code `type`
|
|
43
|
-
* carries ("security_agency") - not a human-typed description. Treating it as
|
|
44
|
-
* free text made the raw code win over the label lookup for every row, since
|
|
45
|
-
* `nature` is truthy whenever it is set at all. Only trust it as an override
|
|
46
|
-
* when it is NOT itself one of the known codes.
|
|
47
|
-
*/
|
|
48
|
-
export function spTypeLabel(type: string, nature: string | undefined, source: unknown): string {
|
|
49
|
-
const list = (Array.isArray(source) ? source : (source as any)?.value) as
|
|
50
|
-
| TNatureOption[]
|
|
51
|
-
| undefined;
|
|
52
|
-
const codeMatch = (value?: string) => list?.find((x) => x.value === value);
|
|
53
|
-
|
|
54
|
-
if (nature && String(nature).trim() && !codeMatch(nature)) return String(nature);
|
|
55
|
-
|
|
56
|
-
const hit = codeMatch(type) ?? codeMatch(nature);
|
|
57
|
-
return hit?.title ?? type ?? nature ?? "-";
|
|
58
|
-
}
|
|
59
|
-
|
|
60
|
-
export function spDay(value?: string | null): string {
|
|
61
|
-
if (!value) return "";
|
|
62
|
-
const d = new Date(value);
|
|
63
|
-
return Number.isNaN(d.getTime())
|
|
64
|
-
? ""
|
|
65
|
-
: d.toLocaleDateString("en-GB", { day: "numeric", month: "short", year: "numeric" });
|
|
66
|
-
}
|
|
67
|
-
|
|
68
|
-
/** The company cell: the name, or why there is none yet. */
|
|
69
|
-
export function sentCompany(row: TSentInvitation): { text: string; known: boolean } {
|
|
70
|
-
const name = String(row.companyName || row.metadata?.name || "").trim();
|
|
71
|
-
if (name) return { text: name, known: true };
|
|
72
|
-
const status = row.viewStatus || row.status || "";
|
|
73
|
-
return {
|
|
74
|
-
text: ["pending", "awaiting-approval"].includes(status) ? "Not accepted yet" : "Not accepted",
|
|
75
|
-
known: false,
|
|
76
|
-
};
|
|
77
|
-
}
|
|
78
|
-
|
|
79
|
-
/** "Invited by Tommy on 24 Sep 2026". */
|
|
80
|
-
export function sentInvitedLine(row: TSentInvitation): string {
|
|
81
|
-
const who = String(row.invitedByName ?? "").trim();
|
|
82
|
-
const when = spDay(row.invitedAt ?? row.createdAt);
|
|
83
|
-
return [who ? `by ${who}` : "", when ? `on ${when}` : ""].filter(Boolean).join(" ");
|
|
84
|
-
}
|
|
85
|
-
|
|
86
|
-
/** The line under the status: when it was answered, and what it means now. */
|
|
87
|
-
export function sentStatusLine(row: TSentInvitation): string {
|
|
88
|
-
const status = row.viewStatus || row.status || "";
|
|
89
|
-
const when = spDay(row.answeredAt);
|
|
90
|
-
if (status === "complete" && row.onSite === false) {
|
|
91
|
-
return `Accepted${when ? ` on ${when}` : ""} · no longer on this site`;
|
|
92
|
-
}
|
|
93
|
-
if (ANSWERED[status]) return when ? `${ANSWERED[status]} on ${when}` : "";
|
|
94
|
-
if (status === "awaiting-approval") return "Seven365 checks it before it is sent";
|
|
95
|
-
if (status === "pending") return "Sent - waiting for their answer";
|
|
96
|
-
return "";
|
|
97
|
-
}
|