Samir Boulahtit
d7a0ff8818
This commit completes the migration to a fully module-driven architecture: ## Models Migration - Moved all domain models from models/database/ to their respective modules: - tenancy: User, Admin, Vendor, Company, Platform, VendorDomain, etc. - cms: MediaFile, VendorTheme - messaging: Email, VendorEmailSettings, VendorEmailTemplate - core: AdminMenuConfig - models/database/ now only contains Base and TimestampMixin (infrastructure) ## Schemas Migration - Moved all domain schemas from models/schema/ to their respective modules: - tenancy: company, vendor, admin, team, vendor_domain - cms: media, image, vendor_theme - messaging: email - models/schema/ now only contains base.py and auth.py (infrastructure) ## Routes Migration - Moved admin routes from app/api/v1/admin/ to modules: - menu_config.py -> core module - modules.py -> tenancy module - module_config.py -> tenancy module - app/api/v1/admin/ now only aggregates auto-discovered module routes ## Menu System - Implemented module-driven menu system with MenuDiscoveryService - Extended FrontendType enum: PLATFORM, ADMIN, VENDOR, STOREFRONT - Added MenuItemDefinition and MenuSectionDefinition dataclasses - Each module now defines its own menu items in definition.py - MenuService integrates with MenuDiscoveryService for template rendering ## Documentation - Updated docs/architecture/models-structure.md - Updated docs/architecture/menu-management.md - Updated architecture validation rules for new exceptions ## Architecture Validation - Updated MOD-019 rule to allow base.py in models/schema/ - Created core module exceptions.py and schemas/ directory - All validation errors resolved (only warnings remain) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
52 lines
1.6 KiB
Python
52 lines
1.6 KiB
Python
# app/modules/enums.py
|
|
"""
|
|
Module system enums.
|
|
|
|
This file contains enums used by the module system that need to be
|
|
importable without triggering database model imports.
|
|
|
|
The FrontendType enum is defined here to break a circular import:
|
|
- app.modules.base imports FrontendType
|
|
- Previously FrontendType was in models.database.admin_menu_config
|
|
- Importing from models.database triggers model discovery
|
|
- Model discovery imports module definitions
|
|
- Module definitions import from app.modules.base → CIRCULAR
|
|
|
|
By defining FrontendType here, we break this cycle.
|
|
"""
|
|
|
|
import enum
|
|
|
|
|
|
class FrontendType(str, enum.Enum):
|
|
"""Frontend types that can have menu configuration."""
|
|
|
|
PLATFORM = "platform" # Public marketing pages (pricing, signup, about)
|
|
ADMIN = "admin" # Admin panel (super admins, platform admins)
|
|
VENDOR = "vendor" # Vendor dashboard
|
|
STOREFRONT = "storefront" # Customer-facing shop
|
|
|
|
|
|
# Menu items that cannot be hidden - always visible regardless of config
|
|
# Organized by frontend type
|
|
# NOTE: This will be deprecated in favor of MenuItemDefinition.is_mandatory
|
|
MANDATORY_MENU_ITEMS = {
|
|
FrontendType.ADMIN: frozenset({
|
|
"dashboard", # Default landing page after login
|
|
"companies",
|
|
"vendors",
|
|
"admin-users",
|
|
"settings",
|
|
"my-menu", # Super admin menu config - must always be accessible
|
|
}),
|
|
FrontendType.VENDOR: frozenset({
|
|
"dashboard", # Default landing page after login
|
|
"settings",
|
|
}),
|
|
FrontendType.PLATFORM: frozenset(),
|
|
FrontendType.STOREFRONT: frozenset(),
|
|
}
|
|
|
|
|
|
__all__ = ["FrontendType", "MANDATORY_MENU_ITEMS"]
|