Lewati ke isi

Modular Menu Architecture (Apps-based)

This document is the Single Source of Truth (SSOT) for the Scola Frontend Navigation & Menu Architecture.

1. Overview

The legacy menuRegistry and AppSidebar have been completely deprecated and removed. Scola now uses an Apps-based architecture. Each user role gets one or more "Apps" (defined as appFragments). This provides dedicated portals and isolates navigation contexts.

2. App Fragments (src/config/apps/appFragments/)

All application navigation is defined via fragments. Each fragment defines: - id, label, icon, color: Visual identifiers for the app launcher. - capability / featureFlag: Root-level access gating. - homeRoute: Default landing page for the app. - sections: Groups of menu items. Each item maps to a route and specifies its capability/featureFlag.

2.1 Removing the Tier System

The legacy MENU_TIERS (primary, secondary, advanced) is deprecated. Menu ordering is now strictly driven by the order property explicitly defined in each app and section.

3. Mobile Navigation Configuration

Mobile presentation is controlled via role navigation metadata plus the mobile property on leaf items.

3.1 Mobile Shell Contract

  • The mobile bottom bar has 5 visible controls total:
  • 4 pinned task destinations
  • 1 fixed center Menu launcher that opens /apps
  • Therefore bottomRank is standardized to 1-4, not 1-5.
  • The /apps launcher stays inside the mobile shell and must not disable the bottom bar.

3.2 Leaf-Level Mobile Hints

  • bottomRank: <1-4>: Maps the menu item to one of the 4 configurable task slots on the mobile bottom bar.
  • launcher: true: Pins the menu item to the Mobile Launcher grid for quick visual access.
  • quickAccess: true / quickAccessRank: <number>: Promotes the item to a quick-action strip at the top of the mobile screen.

3.3 Role-Level Navigation Metadata

src/config/apps/roleApps.js is the runtime owner for: - navigation.desktopMode - navigation.desktopRailMode - navigation.mobileMode - navigation.primaryAppId - navigation.utilityAppIds - navigation.sectionOrder - navigation.hiddenSectionIds - navigation.hiddenLeafIds - navigation.mobilePinnedLeafIds - navigation.mobileQuickAccessLeafIds

Section-first roles render the dominant workspace sections as desktop primary navigation. App-first roles keep apps in the desktop rail. desktopRailMode defaults to capped; use all only when a role intentionally shows every app in the scrollable desktop rail instead of the Aplikasi Lainnya overflow. Role-specific variants should prefer sectionOrder, hiddenSectionIds, and hiddenLeafIds before forking an app fragment.

4. Feature Flags vs Core Modules

Scola uses strict Feature Flag normalization aligned with Backend module names.

Rules for Gating: 1. Core Modules NEVER get Feature Flags: Features belonging to scola_bundle_core (e.g., scola_admission/SPMB, scola_attendance) are always active. Do not attach featureFlag to these menu items. 2. Flag Name = Technical Module Name: - scola_accounting → scola_account - scola_people → scola_hr - scola_face_recognition → scola_hr_attendance - scola_rfid → Merged into scola_hr_attendance 3. Add-ons Default to false: Add-ons like scola_library or scola_inventory default to false and are enabled remotely when the backend reports the module is installed.

Always verify capabilities before defining feature flags, and defer to src/config/featureFlagFragments/moduleFeatureFlags.js for the canonical list.