Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/CodexaCP/DG_WEB/llms.txt

Use this file to discover all available pages before exploring further.

Dragon Guard WMS Web is an Angular 15 + PrimeNG 15 administrative frontend built on a Sakai shell and branded for Grupo MAS. It owns the document-management surface of the Warehouse Management System — creating and maintaining items, receipts, shipments, movements, and sales orders — while physical execution (posting received goods, confirming shipments on the floor) is exclusively the responsibility of the MAUI handheld application. The backend (.NET Wms.Api) is the single source of truth shared by both clients.

​
Three-Tier Ecosystem

┌─────────────────────────┐     REST / JSON     ┌──────────────────────┐
│  Dragon Guard WMS Web   │ ──────────────────► │     Wms.Api (.NET)   │
│  Angular 15 + PrimeNG   │ ◄────────────────── │   Business Logic &   │
│  Administrative UI      │                     │   Authorization      │
└─────────────────────────┘                     └──────────┬───────────┘
                                                           │ REST / JSON
                                                           ▼
                                                ┌──────────────────────┐
                                                │   MAUI Handheld App  │
                                                │  Physical Execution  │
                                                │  (Post/Scan/Confirm) │
                                                └──────────────────────┘
The web frontend never calls handheld-only posting endpoints. Stock manipulation, receipt posting, and shipment confirmation are MAUI responsibilities. This boundary is enforced both by convention and by the API contract.

​
Folder Structure

The entire application lives under src/app/. Each top-level folder has a single, well-scoped concern: 
src/app/
├── core/           # AuthService, route guards, JWT interceptor, i18n
├── layout/         # Shell: topbar, sidebar, menu + WmsService (central API)
├── auth/           # Login and password-change screens
├── pages/          # Business modules: items, customers, shipments,
│                   #   receipts, inventory, audit
├── receipts/       # Receipts lazy module
├── sales/          # Commercial: sales orders, purchase orders,
│                   #   customers, sellers
├── admin/          # Admin: warehouse-setup, RFID, config-packages,
│                   #   tenant-users
├── supreme/        # Super-admin: multi-tenant, companies, plans
└── shared/         # Shared components, pipes, directives
The supreme/ module is only ever loaded for users with the SUPERADMIN_SUPREMO role. Company admins never see this module, and the route guard rejects direct-URL access even if a user somehow navigates there.

​
Lazy Module Loading

All business areas are lazy-loaded from the root router, which keeps the initial bundle small and isolates each domain: 
// src/app/app-routing.module.ts (simplified)
{
  path: 'dashboard',
  canActivate: [authGuard],
  children: [
    { path: 'receipts',  loadChildren: () => import('./receipts/receipts.module') },
    { path: 'shipments', loadChildren: () => import('./pages/shipments/…') },
    { path: 'items',     loadChildren: () => import('./pages/items/…') },
    { path: 'inventory', loadChildren: () => import('./pages/inventory/…') },
    { path: 'sales',     loadChildren: () => import('./sales/sales.module') },
    { path: 'admin',     canActivate: [adminGuard],   loadChildren: () => import('./admin/…') },
    { path: 'supreme',   canActivate: [supremeGuard], loadChildren: () => import('./supreme/…') },
  ]
}
Every route under /dashboard requires at minimum a valid authenticated session (authGuard). Privileged sub-trees layer additional guards on top.

​
Central Service Rule

All outbound HTTP calls must go through WmsService (located at src/app/layout/service/wms.service.ts). This service:
  • Reads the base URL from environment.apiUrl
  • Resolves companyId from the authenticated session automatically
  • Provides typed methods for every backend resource
No component or feature module should instantiate its own HttpClient calls directly. Centralising HTTP in one place makes it straightforward to update base URLs, add request transforms, and trace all API traffic in a single file. 
// Pattern enforced across all feature modules
constructor(private wms: WmsService) {}

loadReceipts() {
  // WmsService resolves companyId and apiUrl internally
  return this.wms.getReceivingHeaders();
}
The SupremeService is the only sanctioned exception — it handles api/supreme/* endpoints for the SUPERADMIN_SUPREMO role. See the Multitenancy page for details.

​
Authentication Flow

1

User submits credentials

The login screen calls POST /api/Auth/login via AuthService (src/app/core/service/auth.service.ts). No JWT interceptor is applied to this call.
2

Token stored in sessionStorage

On success, the JWT and session metadata (active_company_id, active_role, is_supreme_admin) are written to sessionStorage. localStorage is never used — tokens are cleared automatically when the browser tab closes.
3

JWT interceptor attaches Bearer header

An HttpInterceptor in core/ reads the token from sessionStorage and appends Authorization: Bearer <token> to every subsequent request. The interceptor skips the login endpoint to avoid circular headers.
4

Role-based redirect

After login, AuthService inspects is_supreme_admin. SUPERADMIN_SUPREMO users are redirected to /dashboard/supreme; all others land on /dashboard.
5

Token expiry

The backend returns 401 Unauthorized when the token expires. The interceptor (or a response handler) clears sessionStorage and redirects to /auth/login.

​
Route Guards

GuardApplied toRequired condition
authGuard/dashboard/**Valid JWT in sessionStorage
adminGuard/dashboard/admin/**Role ADMIN or higher
supremeGuard/dashboard/supreme/**Role SUPERADMIN_SUPREMO
Guards are frontend enforcement only. The backend applies its own authorization checks on every request. A user who bypasses a frontend guard still cannot access protected data — the API will return 401 or 403.
Do not rely on frontend guards as a security boundary. They exist for UX (preventing unnecessary navigation) not for data protection. All authorization must be enforced server-side in Wms.Api.

​
Key Architectural Constraint: No Posting from Web

The web application is strictly a document-management client. Physical warehouse operations — receiving goods against a receipt, confirming shipment lines, performing cycle counts — are executed exclusively by the MAUI handheld application. The following actions are forbidden from the Angular frontend:
  • Calling any stock-manipulation endpoint
  • Calling any posting or confirmation endpoint
  • Bypassing backend validation with client-side pre-processing
  • Accessing data belonging to another company (cross-tenant reads)
This division of responsibility keeps the web UI simple and prevents accidental stock corruption from administrative screens.

Multitenancy

How Dragon Guard separates tenant-scoped WMS screens from the global SaaS surface, including session keys, service split, and role-based routing.

API Contracts

Endpoint inventory, contract stability rules, error codes, and the versioning strategy shared by the Angular frontend, .NET backend, and MAUI handheld.

Build docs developers (and LLMs) love

Get started for freeTalk to us