7 Commits

Author	SHA1	Message	Date
simoleo89	989b132c6a	fix(hooks): useHasPermission must distinguish ALLOWED from ROOM_OWNER ... The permission map shipped over the wire carries both PermissionSetting.ALLOWED (value 1) and PermissionSetting.ROOM_OWNER (value 2). Server-side, `Habbo.hasPermission(key)` calls `Rank.hasPermission(key, isRoomOwner=false)`, whose implementation at Rank.java:120 is: setting == ALLOWED || (setting == ROOM_OWNER && isRoomOwner) So a permission whose rank value is ROOM_OWNER is only granted when the caller is the active room owner — Habbo.hasPermission(key) with the default `false` therefore returns false for ROOM_OWNER entries. The previous useHasPermission implementation (`> 0`) treated ROOM_OWNER as unconditionally true, which would let a UI gate light up even when the server would refuse the action. Real example from the default seed: `acc_closedice_room` is ROOM_OWNER for rank_1..6 and ALLOWED only for rank_7 — under `> 0` the predicate was true for every rank, diverging from the server behaviour. Tighten useHasPermission to `=== 1` (ALLOWED only). For the genuine "this is a ROOM_OWNER permission, combine with room session" scenarios, code reaches for usePermissionValue(key) and checks `=== 2 && roomSession.isRoomOwner` explicitly. None of the 11 migrated consumers are affected by the tightening: the keys they use (acc_supporttool / acc_anyroomowner / acc_catalogfurni / acc_calendar_force / acc_staff_pick / acc_ambassador) are all ALLOWED-only in the default seed. Test refresh: - useHasPermission('acc_supporttool') (value 1) stays true. - useHasPermission('acc_anyroomowner') with value 2 in the mock flips from true to false — the new contract. - Other cases unchanged. Verification: yarn typecheck clean, yarn lint:hooks clean, yarn test 214/214.	2026-05-19 19:45:19 +02:00
simoleo89	c7e258e3d1	feat(hooks): permission-driven gating via useHasPermission ... Replace the rank-level family (useHasRankLevel + STAFF_LEVELS constants + useIsRank) with a permission-driven family that reads straight from the deployment's `permission_definitions` table — no more hardcoded SecurityLevel/rank-id thresholds on the client. A new rank in permission_ranks or a re-shuffling of permission_definitions rank columns now propagates through the UI automatically. Renderer-side wire shipped in companion commit feat/react19-event-bus@159c5eb (UserPermissionsMapParser + Event, SessionDataManager.getPermissionsSnapshot + USER_PERMISSIONS_UPDATED). New public API in `useSessionSnapshots.ts`: - useUserPermissions(): ReadonlyMap<string, number> — full map - useHasPermission(key): boolean — > 0 ⇒ true - usePermissionValue(key): number — raw 1/2 or 0 - useIsAmbassador() now aliases useHasPermission('acc_ambassador') - useUserRank() kept for PRESENTATIONAL use only (badge, prefix, prefix color) — documented as such in JSDoc; gating must use useHasPermission. Dropped: - src/api/nitro/session/RankLevels.ts (STAFF_LEVELS constants) - useHasRankLevel / useIsRank exports (rank-based gating) 11 consumer migrations, each mapped to the right `permission_definitions.permission_key`: - ToolbarView (mod-only chat-input button) → acc_supporttool - ChooserWidgetView (room-object id column) → acc_supporttool - CatalogClassicView (admin toggles) → acc_catalogfurni - CatalogModernView (admin toggles) → acc_catalogfurni - FurniEditorView (panel access) → acc_catalogfurni - CalendarView (force-open day) → acc_calendar_force - InfoStandWidgetFurniView (mod buildtools btn) → acc_anyroomowner - AvatarInfoWidgetPetView (canPickUp) → acc_anyroomowner - FurnitureMannequinView (controller mode) → acc_anyroomowner - YouTubePlayerView (isMyRoom) → acc_anyroomowner - NavigatorRoomInfoView 'settings' → acc_anyroomowner - NavigatorRoomInfoView 'staff_pick' → acc_staff_pick Test refresh: - useUserRank still tested for the presentational shape. - useHasPermission: true for non-zero, false for absent/zero. - usePermissionValue: raw 1 / 2 / 0 (default). - useUserPermissions: full map exposure. - Runtime promote test: mutate the permissions map + dispatch USER_PERMISSIONS_UPDATED, assert useHasPermission flips false→true. Locks in the new reactive contract. Mock unchanged (the test sets getPermissionsSnapshot via vi.mocked). Verification: yarn typecheck clean, yarn lint:hooks clean, yarn test 214/214 (213 prior + 1 net new for useUserPermissions). Backward compatible: older Arcturus deployments don't ship the map → empty snapshot → every gate is false → mod UI hidden (safe default).	2026-05-19 19:00:10 +02:00
simoleo89	8aa02249e1	feat(hooks): rank-based API tied to permission_ranks DB table ... Drop the SecurityLevel-named family (useIsModerator / useIsAdmin / useIsCommunity / useIsPlayerSupport / useHasSecurityLevel / useUserSecurityLevel) in favour of a rank-based family tied to the operator's actual `permission_ranks` rows in the Arcturus DB: - `useUserRank()` returns `{ id, name, level, badge, prefix, prefixColor }` derived from the snapshot. Powered by the renderer's extended IUserDataSnapshot (companion commit 87e67d5 on feat/react19-event-bus). - `useHasRankLevel(min)` replaces useHasSecurityLevel; consumers pass a `permission_ranks.level` threshold from the deployment. - `useIsRank(name)` matches `permission_ranks.rank_name` exactly. To avoid bare integers in widget bodies, added a deployment-scoped constants file at `src/api/nitro/session/RankLevels.ts`: export const STAFF_LEVELS = { MEMBER: 1, SUPPORT: 4, MOD: 5, SUPER_MOD: 6, ADMIN: 7 }; A deployment that re-numbers `permission_ranks` only edits this file. Migrated all 11 consumer reads (same set as the earlier session's useIsModerator migration plus the audit catch): ToolbarView, CatalogClassicView, CatalogModernView, ChooserWidgetView, CalendarView, YouTubePlayerView, FurniEditorView, InfoStandWidgetFurniView, AvatarInfoWidgetPetView, FurnitureMannequinView, NavigatorRoomInfoView. The NavigatorRoomInfoView `staff_pick` permission was previously `securityLevel >= COMMUNITY (7)` via the renderer-enum wrapper — ported to `useHasRankLevel(STAFF_LEVELS.ADMIN)` because in the default seed level 7 is Administrator, which is the actual rank that gets the `acc_anyroomowner`-style permissions for staff-picking. Tests refreshed under `useSessionSnapshots.test.tsx`: - useUserRank surfaces the full metadata block; - useHasRankLevel does `>=` against the threshold; - useIsRank exact-matches against rank_name; - a runtime promote (snapshot mutation + SESSION_DATA_UPDATED dispatch) flips the result, locking in the reactive contract. Mock extended only minimally — kept the SecurityLevel enum class for any consumer outside the dropped family that still imports it. Verification: yarn typecheck clean, yarn lint:hooks clean, yarn test 213/213. The Arcturus-side composer change (UserPermissionsComposer appending the 5 extra fields) is staged but UNCOMMITTED on Arcturus main (which has unrelated WIP); the wire is backward-compatible so the React client works against both pre- and post-extension emulators.	2026-05-19 18:38:31 +02:00
simoleo89	c11a6c4699	feat(hooks): generalise security-level family + audit catch + reactivity test ... Build on the useIsModerator landing (532cb28c) along three axes: 1. Family. Extract `useHasSecurityLevel(min)` as the primitive, backed by a fresh `useUserSecurityLevel()` raw-level reader. The six SecurityLevel constants (1..9) deserve named wrappers so the "show this only to X-and-up" pattern doesn't get re-derived ad-hoc each time: shipped `useIsModerator` / `useIsPlayerSupport` / `useIsCommunity` / `useIsAdmin` as one-line shims. Also added `useIsAmbassador()` as a sibling — not derived from security level, reads the boolean field on the snapshot directly. 2. Audit. The 532cb28c migration covered 6 React-render reads but missed 5 more discovered by a follow-up grep: - FurniEditorView (top-level `const isMod`) - InfoStandWidgetFurniView (inline JSX, mod-only build-tools button) - NavigatorRoomInfoView (3 reads in hasPermission(): isModerator and securityLevel >= COMMUNITY for the staff-pick gate. The userId read stays imperative — userId doesn't flip at runtime in practice, no reactivity gain.) - AvatarInfoWidgetPetView (inside useMemo with [roomSession] deps; migrated and isModerator added to the deps so a runtime promote/demote re-derives canPickUp without remount) - FurnitureMannequinView (inside useEffect; same treatment — added isModerator to the deps so the mode re-resolves on flip) The remaining ~17 reads (CanManipulateFurniture, AvatarInfoUtilities.populate*, useChatInputActions, useFurnitureDimmerWidget / useFurniturePlaylistEditorWidget / useFurnitureStickieWidget canModify checks, useCatalog admin filter, useNavigator door-mode guard) are click-time / event-time imperative — they read at the moment a user action fires, so a reactive value would be cached at hook execution and stale by the time the action runs. Leaving them on the synchronous manager read is correct. 3. Test. Added four cases pinning the contract: - useUserSecurityLevel returns the raw level. - useHasSecurityLevel does `>=` against the threshold. - Named wrappers map to the right constants (MODERATOR=5, COMMUNITY=7, ADMINISTRATOR=8). - **Reactive flip** — mutate the snapshot, dispatch the SESSION_DATA_UPDATED event on the mock dispatcher, assert the hook re-derives. Locks in the whole point of the snapshot pattern (a static read would pass cases 1-3 but fail case 4). Mock changes: - Added SecurityLevel class (mirrors the renderer enum 0..9) so the family wrappers resolve to actual numbers in jsdom — without it `useIsModerator()` would call `useHasSecurityLevel(undefined)` and the test would silently pass false-positives. Verification: yarn typecheck clean, yarn lint:hooks clean, yarn test 213/213 (209 baseline + 4 new family/reactivity cases).	2026-05-19 18:18:20 +02:00
simoleo89	532cb28ca7	feat(hooks): useIsModerator() + migrate 6 component reads ... Adds a reactive `useIsModerator()` derived from `useUserDataSnapshot().securityLevel >= SecurityLevel.MODERATOR` (mirrors the renderer-side getter at SessionDataManager.ts:684), and migrates the six React component-body reads of `GetSessionDataManager().isModerator`: - ToolbarView (mod-only chat-input button) - CatalogClassicView, CatalogModernView (admin toggles in catalog header) - ChooserWidgetView (room-object id column visibility) - YouTubePlayerView (room-control affordance — hook moved above the `if (!isOpen) return null` early return so the hook order stays stable when the player opens/closes) - CalendarView (mod-only "open all" affordance) UX impact: any future promote/demote that flips SESSION_DATA_UPDATED now re-renders the mod-only UI live, instead of requiring an F5. Imperative call sites (AvatarInfoUtilities.populate*, CanManipulateFurniture, RoomChatHandler) still read the manager directly — they run at click time, not in a React render, so reactivity has no upside there. Five of the six call sites are top-level component-body reads (no early-return interaction). YouTubePlayerView has an `if (!isOpen) return null` below the hook list, so the hook had to move ABOVE it; same shape as the recent CatalogPurchaseWidgetView and CatalogItemGridWidgetView fixes. Verification: yarn typecheck clean, yarn lint:hooks clean, yarn test 209/209.	2026-05-19 18:07:17 +02:00
simoleo89	c35a2d4b4f	fix(useSessionSnapshots): defensive guards against missing renderer methods ... The snapshot hooks were chained against renderer Manager methods (getUserDataSnapshot, getIgnoredUsersSnapshot, subscribe, …) under the assumption that the resolved \`@nitrots/nitro-renderer\` bundle always includes the v2.1.0+ snapshot API. That assumption fails in two real scenarios: 1. A stale \`dist/index.js\` shadows the source umbrella at resolution time (the vite alias commit 790ad2b mitigates this in dev, but it only takes effect after a server restart). 2. A consumer bundles the client against an older renderer release (e.g. NitroV3-Housekeeping's embedded copy in \`public/nitro3\`). In both cases the snapshot hook calls \`undefined()\` and React shows the error-boundary fallback "(intermediate value)() is undefined". Wrap every renderer-side call with a typeof guard: const manager = GetSessionDataManager(); if(!manager || typeof manager.getUserDataSnapshot !== 'function') return DEFAULT_USER_DATA; return manager.getUserDataSnapshot(); Module-level frozen defaults (DEFAULT_USER_DATA, EMPTY_IGNORED_LIST, EMPTY_GROUP_BADGES, EMPTY_USER_LIST, DEFAULT_VOLUMES, NOOP_UNSUBSCRIBE) keep the snapshot reference stable across fallback calls, so useSyncExternalStore's bailout still works and we don't trigger render loops on the degraded path. Once the renderer is upgraded (or the alias kicks in after restart), the hooks transparently switch to the real getters — no code change needed at any consumer. Verification: yarn typecheck clean, yarn test 207/207, yarn build green. The fix is defense-in-depth on top of 790ad2b (vite alias) — both can coexist, neither alone is sufficient for every deployment surface.	2026-05-18 22:06:32 +02:00
simoleo89	b2a86da912	feat(hooks/session): React-side consumer hooks for the renderer snapshot pattern ... The renderer exposes six referentially-stable snapshot getters under the v2.1.0 React-friendly pattern (SessionData / RoomSession / IgnoredUsers / GroupBadges / RoomUserList / SoundVolumes), each invalidated by a dedicated NitroEventType.*_UPDATED dispatch. Until now nothing on the client consumed them — useExternalSnapshot existed as a useSyncExternalStore wrapper but no widget was wired up to a snapshot. Add thin consumer hooks under src/hooks/session/useSessionSnapshots.ts, each a useExternalSnapshot wrapper around the matching subscribe+getter pair: - useUserDataSnapshot() → Readonly<IUserDataSnapshot> - useActiveRoomSessionSnapshot() → Readonly<IRoomSessionSnapshot> | null - useIgnoredUsersSnapshot() → ReadonlyArray<string> - useIsUserIgnored(name) → boolean (useMemo over the array) - useGroupBadgesSnapshot() → ReadonlyMap<number, string> - useGroupBadge(groupId) → string (useMemo over the map) - useVolumesSnapshot() → Readonly<ISoundVolumesSnapshot> - useRoomUserListSnapshot() → ReadonlyArray<IRoomUserData> Two design details worth noting: - useRoomUserListSnapshot subscribes to BOTH ROOM_USER_LIST_UPDATED (for join/leave/update inside a session) AND ROOM_SESSION_UPDATED (because the underlying userDataManager reference flips when the active room session changes). A single module-level frozen EMPTY_USER_LIST is the fallback when no session is active, keeping reference stability across reads in the no-room state. - useIsUserIgnored / useGroupBadge memoize the scalar derivation so a re-render only happens when the underlying snapshot reference flips, not on unrelated useExternalSnapshot wake-ups. These hooks unlock per-component snapshot consumption — widgets that previously juggled addEventListener + useState pairs (or worse, read GetSessionDataManager().userId directly and never re-rendered) can now go through one of these and get reactivity for free. Migration of existing consumers (useSessionInfo, AvatarInfoUtilities, etc.) is the next pass. Verification: yarn typecheck clean, yarn test 203/203, yarn build green.	2026-05-18 21:24:03 +02:00