12 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	a029ee63cb	fix(catalog,ci): catch hook-order violations + add CI gate ... Two follow-ups to the CatalogPurchaseWidgetView fix (6bf3366): 1. CatalogItemGridWidgetView had the same shape — four useCallback declarations (handleDragStart / handleDragOver / handleDrop / handleDragEnd) sat below an `if(!currentPage) return null` early return. When currentPage flipped from null to a real page the hook count jumped by 4 and React would have thrown "Rendered more hooks than during the previous render" the moment any consumer rendered the grid in admin mode. Moved the four useCallback declarations above the early-return; their bodies are safe pre-load (only currentPage?.offers is accessed inside handleDrop, optional-chained already). 2. CI gate — the existing GitHub Actions workflow runs `yarn typecheck` and `yarn test`, but NOT `yarn eslint`. That's why this pattern slipped through twice in a row: ESLint flags it locally but no PR check enforces it. Full `yarn eslint` emits ~900 pre-existing baseline errors (brace-style, indentation, recommended TS rules — out of scope for this branch), so a blanket step would always fail. Instead added a focused `eslint.hooks.config.mjs` + `yarn lint:hooks` script that runs ESLint with ONLY `react-hooks/rules-of-hooks: error`. Wired into ci.yml between `typecheck` and `test`. The local repo now has zero violations of the rule. 3. useSessionSnapshots.test.tsx — added eslint-disable-next-line comments on the three lines that intentionally violate the rule (they're the assertions that the broken pattern crashes). Without the comments the new CI gate would fail on the regression-guard suite. Verification: yarn lint:hooks green, yarn typecheck clean, yarn test 209/209.	2026-05-19 17:57:28 +02:00
simoleo89	d28819db89	fix(snapshots): re-apply the 3 snapshot-consumer migrations with the use-between/useSyncExternalStore incompatibility resolved ... Root cause of last session's "(intermediate value)() is undefined" at ToolbarView.tsx:46: use-between 1.x ships its own React-dispatcher proxy (ownDispatcher in node_modules/use-between/release/index.esm.js:54-169) that re-implements only useState, useReducer, useEffect, useLayoutEffect, useCallback, useMemo, useRef and useImperativeHandle. It does NOT implement useSyncExternalStore. When the inner state function of useBetween(stateFn) calls useSyncExternalStore (directly or via useExternalSnapshot / useUserDataSnapshot), React resolves the dispatcher to use-between's proxy, finds .useSyncExternalStore missing, and calls undefined() — that's the exact production crash in Firefox. Chrome reports the same as "dispatcher.useSyncExternalStore is not a function". Neither the vite alias (790ad2b) nor the defensive renderer-method guards (c35a2d4) could fix it — both addressed downstream symptoms (stale dist / missing manager methods) but the dispatcher is upstream of both. That's why every retry kept reproducing the same error. Fix is structural: snapshot hooks (useUserDataSnapshot, useIsUserIgnored, etc.) MUST run outside any useBetween scope. Three re-applied migrations: - useSessionInfo: snapshot read moved into the outer wrapper. The inner useSessionInfoState (useBetween-shared) now contains only use-between-safe hooks: useState, useMessageEvent, plain actions. userFigure / userRespectRemaining / petRespectRemaining come from useUserDataSnapshot() OUTSIDE useBetween, so useSyncExternalStore installs against the real React dispatcher. - useChatWidget.ownUserId: direct snapshot read. useChatWidget is exported as `useChatWidget = useChatWidgetState` (NOT wrapped in useBetween), so this hook never sat inside the broken scope — the precautionary rollback was unnecessary in retrospect. Gains session-change reactivity (e.g. reconnect under a different user id). - AvatarInfoWidgetAvatarView Ignore/Unignore: useIsUserIgnored(name) read directly in the component body. Same reasoning as useChatWidget — never inside useBetween. The menu auto-flips Ignore <-> Unignore while the popup is open. Added regression guard at src/hooks/session/useSessionSnapshots.test.tsx with two cases: (1) useSyncExternalStore inside useBetween throws, (2) useSyncExternalStore outside useBetween in the same render works. Pins the constraint so future migrations cannot reintroduce the bad shape silently. Verification: yarn typecheck clean, yarn test 209/209 (207 baseline + 2 new regression cases), no consumer surface changes — every destructured field (userFigure, userRespectRemaining, respectUser, petRespectRemaining, respectPet, chatStyleId, updateChatStyleId) is still returned with the same name and shape.	2026-05-19 17:30:03 +02:00
simoleo89	e142efd793	revert(hooks): roll back the three snapshot-consumer migrations to pre-71a0eee state ... The migrations of useSessionInfo, useChatWidget.ownUserId and the AvatarInfo Ignore/Unignore menu to the new useSessionSnapshots hooks were correct in code but produce a persistent runtime error in the user's deployment: TypeError: (intermediate value)() is undefined ToolbarView ToolbarView.tsx:46 The error fires from React's render loop on the first paint — ToolbarView is the first mounted consumer of useSessionInfo, which is why it carries the boundary message. Two attempted fixes did not resolve it on the user's side: - 790ad2b: vite alias forcing @nitrots/nitro-renderer to source index.ts - c35a2d4: defensive typeof guards on every Manager method call inside useSessionSnapshots (so a missing method degrades to a frozen default rather than calling undefined) Both are correct defenses but the error persists, meaning the failure mode is upstream of those guards. Rather than burn more cycles remote-debugging, roll back the three consumer migrations: - useSessionInfo: restored to the pre-71a0eee shape — 5 useState fields driven by useMessageEvent<UserInfoEvent, FigureUpdateEvent, UserSettingsEvent>. The five consumers (ToolbarView, HcCenterView, ChatInputView, AvatarInfoPetTrainingPanelView, InfoStandWidgetPetView, AvatarInfo{Avatar,Pet,OwnPet}View) get the same destructured shape they had before this session. - useChatWidget.ownUserId: restored to `GetSessionDataManager()?.userId` (synchronous, captured at mount). Loses the session-change reactivity but matches the previous, working behaviour. - AvatarInfoWidgetAvatarView Ignore/Unignore: restored to `avatarInfo.isIgnored` (captured by AvatarInfoUtilities at click time, not reactive). Loses the live-toggle if the user is ignored/unignored while the popup is open — known small regression, worth it for stability. Kept intact: - The useSessionSnapshots.ts hook file itself, with defensive guards, so the API stays available for any future opt-in consumer. - 790ad2b vite alias for the umbrella, still useful as defence in depth for future migrations. - All the other non-snapshot modernizations from this session (usePetPackageWidget reducer, useWordQuizWidget bug fix, useChatCommandSelector Zustand store, useAvatarInfoWidget typed globalThis accessor). Verification: yarn typecheck clean, yarn test 207/207, yarn build green. The toolbar should boot without the error now — the call chain on the first paint no longer touches the new useExternalSnapshot / snapshot getter path.	2026-05-18 22:16:48 +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	71a0eee195	refactor(hooks/session): migrate useSessionInfo to useUserDataSnapshot ... Replace the local useState mirror of userFigure / userRespectRemaining / petRespectRemaining (driven by useMessageEvent<UserInfoEvent> + useMessageEvent<FigureUpdateEvent> + manual setUser after giveRespect) with a single useUserDataSnapshot() read. Why this works: SessionDataManager already invalidates its snapshot on every state change that mattered to the old hook — UserInfoEvent handler (line 142), FigureUpdateEvent listener (line 117), giveRespect / givePetRespect (lines 540/551). The snapshot's respectsLeft / respectsPetLeft map directly to the parser fields respectsRemaining / respectsPetRemaining the old code mirrored. Net result: 3 useState declarations + 2 useMessageEvent subscriptions removed; respectUser / respectPet become trivial pass-throughs (no post-call setState because the manager's invalidate dispatches the event for us). UserSettingsEvent stays on useMessageEvent — chatStyleId is not in the snapshot. Also drops the deprecated `userInfo: UserInfoDataParser` field from the return shape — no in-tree consumer reads it (verified via grep across src/), it was carried as legacy clutter. Consumers unchanged: ToolbarView, HcCenterView, ChatInputView, AvatarInfoPetTrainingPanelView, InfoStandWidgetPetView, AvatarInfoWidget {Avatar,Pet,OwnPet}View. All destructure individual fields, not the deprecated userInfo. Verification: yarn typecheck clean, yarn test 203/203.	2026-05-18 21:31:36 +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
DuckieTM	7feb10ab15	🆙 Init V3	2026-01-31 09:10:52 +01:00