@7365admin1/layer-common 4.97.1-staging.600 → 4.97.1-staging.602

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.
@@ -2845,9 +2845,6 @@ const CLEARABLE_ON_UPDATE = [
2845
2845
  "attachments",
2846
2846
  ];
2847
2847
  const OBJECT_ID = /^[a-f0-9]{24}$/i;
2848
- // Users who record a visit they are not witnessing: their visit opens with no
2849
- // check-in / check-out (isecure365 `backOffice`).
2850
- const BACK_OFFICE_USER_TYPES = /^(service-provider|service-provider-member|site)$/i;
2851
2848
 
2852
2849
  // The site's delivery company list (and the typed name snapped to the
2853
2850
  // listed spelling, "grabfood" -> "GrabFood").
@@ -3033,16 +3030,10 @@ function buildPayload(isUpdate: boolean): Record<string, unknown> {
3033
3030
 
3034
3031
  payload.org = prop.org;
3035
3032
  if (userId) payload.createdBy = userId;
3036
- // Registering a visitor at the guardhouse IS their arrival: checked in as it
3037
- // is created. A back-office user's visit opens with no times at all.
3038
- const userType = currentUser.value?.type ?? "";
3039
- if (BACK_OFFICE_USER_TYPES.test(userType)) {
3040
- payload.clientUserType = userType;
3041
- payload.checkIn = null;
3042
- payload.checkOut = null;
3043
- } else {
3044
- payload.checkIn = new Date().toISOString();
3045
- }
3033
+ // Adding a visitor IS their check-in, whoever adds them - a guard or a
3034
+ // property management user (owner, 2026-10-26). No user type is sent: core
3035
+ // does not take one and refuses it ("clientUserType" is not allowed).
3036
+ payload.checkIn = new Date().toISOString();
3046
3037
  return payload;
3047
3038
  }
3048
3039
 
@@ -327,6 +327,38 @@ export default function useSecurityPermission() {
327
327
  },
328
328
  },
329
329
 
330
+ // People Mgmt in the Security app (owner, 2026-10-27): the same six
331
+ // actions, spelling and wording as `usePropertyPermission`, because both
332
+ // apps open the same `/api/people` records.
333
+ "people-mgmt": {
334
+ "add-people": {
335
+ check: true,
336
+ description: "Allows the user to add a new person to the system.",
337
+ },
338
+ "see-all-people": {
339
+ check: true,
340
+ description: "Allows the user to view the list of all people.",
341
+ },
342
+ "see-people-details": {
343
+ check: true,
344
+ description:
345
+ "Allows the user to view the details of a specific person.",
346
+ },
347
+ "update-people": {
348
+ check: true,
349
+ description: "Allows the user to update person details.",
350
+ },
351
+ "delete-people": {
352
+ check: true,
353
+ description:
354
+ "Allows the user to remove a person from the system permanently.",
355
+ },
356
+ "see-people-nric": {
357
+ check: true,
358
+ description: "Allows the user to see a person nric from the system.",
359
+ },
360
+ },
361
+
330
362
  // "guest-mgmt": {
331
363
  // "add-guest": {
332
364
  // check: true,
package/package.json CHANGED
@@ -2,7 +2,7 @@
2
2
  "name": "@7365admin1/layer-common",
3
3
  "license": "MIT",
4
4
  "type": "module",
5
- "version": "4.97.1-staging.600",
5
+ "version": "4.97.1-staging.602",
6
6
  "author": "7365admin1",
7
7
  "main": "./nuxt.config.ts",
8
8
  "//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.",