The Supreme Admin module (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.
src/app/supreme/) is the global SaaS management layer of Dragon Guard WMS, reserved exclusively for Grupo MAS platform operators. From a single interface, a SUPERADMIN_SUPREMO user can provision and configure tenant companies, assign subscription plans, bootstrap tenant administrators, and fine-tune per-tenant RFID behavior — all without touching the tenant-facing Admin module that company admins use day to day. The two modules are fully isolated: changes in Supreme Admin do not surface inside any tenant’s admin panel, and tenant admins cannot access Supreme Admin routes.
Access Control
| Mechanism | Detail |
|---|---|
| Guard | supremeGuard — applied to the entire /dashboard/supreme route tree |
| Role Check | AuthService.isSupremeAdmin() must return true |
| Menu Visibility | The Supreme Admin menu items are rendered only when isSupremeAdmin() is true; they are completely absent from the navigation for all other roles |
| Login Redirect | SUPERADMIN_SUPREMO is redirected to /dashboard/supreme on successful login |
Available Routes
SaaS Dashboard
App route
/dashboard/supreme — Top-level summary dashboard powered by SupremeService. Displays aggregate metrics across all registered tenant companies.Companies
App route
/dashboard/supreme/companies — Full company list with create and edit flows at /companies/new and /companies/:id.Subscription Plans
App route
/dashboard/supreme/plans — Manage available SaaS subscription plans that can be assigned to tenant companies.Users
App route
/dashboard/supreme/users — Cross-tenant user management, including the tenant admin bootstrapping workflow.SupremeService
SupremeService is the single Angular service that backs all Supreme Admin screens. It manages data fetching and mutation for the following domain objects:
| Domain | Description |
|---|---|
| Dashboard Summary | Aggregate stats displayed on the SaaS dashboard |
| Companies | Tenant company records — CRUD operations |
| Plans | Subscription plan definitions |
| Tenant Users | User accounts scoped to a specific tenant company |
| RFID Tenant Settings | Global RFID on/off and mode configuration per tenant |
| RFID Tenant Policies | Per-module RFID behavioral rules per tenant |
| RFID Tenant Events | RFID scan events viewed in the context of a specific company |
Tenant User Bootstrapping
The Users screen includes a bootstrapping workflow for creating the initial administrator account of a new tenant company:Select the target company
Navigate to
/dashboard/supreme/users and select the company for which you need to create the first admin.Trigger admin creation
Use the Bootstrap Admin action. Provide the required user fields (name, email, and any company-specific attributes).
Capture the temporary password
If the backend creates a net-new user, a generated temporary password is displayed once in the UI immediately after the response. Copy it before closing the dialog — it will not be shown again.
Per-Tenant RFID Configuration
RFID configuration for a tenant company is managed from the Company Detail screen (/dashboard/supreme/companies/:id), under the integration panel. It is split into two layers: global settings and per-module policies.
Global RFID Settings (rfidSettings)
These settings apply tenant-wide and control whether RFID is active at all.
| Field | Type | Description |
|---|---|---|
enabled | boolean | Master switch — enables or disables RFID functionality for the entire tenant |
mode | enum | Global operating mode (e.g., strict enforcement, advisory, disabled) |
| Module Scopes | — | Per-module toggles to enable RFID within specific WMS workflows |
| Scope | Workflow |
|---|---|
inquiry | Item Inquiry / EPC resolution lookups |
receipts | Receiving / inbound operations |
shipments | Shipping / outbound operations |
movements | Internal warehouse movements and transfers |
Per-Module RFID Policies (rfidPolicies)
Each module scope can have an independent policy record that controls how the backend behaves when an RFID scan event occurs in that context.
| Policy Field | Description |
|---|---|
| Manual Fallback | Whether the operator is allowed to fall back to manual entry when a scan fails to resolve |
| Barcode Fallback | Whether a barcode scan is accepted as a fallback when RFID resolution fails |
| Exact Match | Whether the resolved item must exactly match the expected document line, or if fuzzy matching is permitted |
| Duplicate Read Window | Time window (in seconds or milliseconds) within which repeated reads of the same EPC are suppressed |
| Evidence Flags | Controls which evidence artifacts (device snapshot, location snapshot, etc.) are captured and stored per event |
| Audit Flags | Controls which events are written to the persistent RFID audit log |
If no policy has been saved for a module yet, the UI renders the policy form using frontend defaults rather than leaving the form blank. The defaults are not persisted until the operator explicitly saves the policy for that module.
RFID Endpoints for Supreme Admin
All RFID configuration endpoints for Supreme Admin are distinct from the tenant-facing RFID APIs.| Method | Endpoint | Description |
|---|---|---|
PATCH | /api/supreme/companies/{id}/integration/rfid-settings | Update global RFID settings for a specific tenant company |
GET | /api/supreme/companies/{id}/integration/rfid-policies | Retrieve all per-module RFID policies for a tenant |
PUT | /api/supreme/companies/{id}/integration/rfid-policies | Replace all per-module RFID policies for a tenant |
GET | /api/rfid/events?companyId={id} | Retrieve RFID scan events scoped to a specific tenant company |
Company Integration Panel
Each company detail screen (/dashboard/supreme/companies/:id) includes an Integration panel where the platform operator configures the connector between Dragon Guard WMS and the tenant’s backend ERP or fulfillment system.
Connector Selection
Before configuring any integration fields, the operator must select a connector type. The available fields, their labels, and their visibility rules are determined by the selected connector.Field Visibility Rules
The integration panel organizes fields into the following categories to guide the operator:| Category | Meaning |
|---|---|
| Required | Must be filled before the connector can function |
| Recommended | Strongly advised for full functionality; not strictly required |
| Optional | Available for advanced configuration; can be left blank |
| Old / Legacy | Deprecated fields retained for backward compatibility; shown with a visual indicator |
GrupoMASNative Connector
When the GrupoMASNative connector is selected, the following field rules apply:| Field | Category | Notes |
|---|---|---|
| Company Code | Required | The tenant’s internal company identifier in the Grupo MAS system |
| Base URL | Required | Root URL of the Grupo MAS native API endpoint |
| API Key | Optional | Value is masked in the UI; displayed as a password-type input |
| Bearer Token | Optional | Value is masked in the UI; displayed as a password-type input |
| X-Api-Key (Legacy) | Legacy | The older API key header; shown in a separate legacy block, distinct from the delegated login flow |
The delegated login flow and the legacy X-Api-Key block are rendered as separate sections in the integration panel for GrupoMASNative. The legacy block is clearly labeled to indicate it should be used only for backward-compatible integrations that cannot be migrated to the delegated authentication model.
AdminModule vs. SupremeModule
| Module | Audience | Route Prefix | Guard |
|---|---|---|---|
AdminModule | Tenant company admins | /dashboard/admin | Standard role guard |
SupremeModule | SUPERADMIN_SUPREMO only | /dashboard/supreme | supremeGuard |
Edge Cases
Company with no subscription plan assigned
Company with no subscription plan assigned
If a tenant company has not been assigned a subscription plan, the company list and detail screens display ‘Sin plan’ in the plan column. The company remains functional at the platform level; plan assignment is an administrative step, not a technical requirement for the company record to exist.
Tenant admin already exists during bootstrapping
Tenant admin already exists during bootstrapping
When triggering the Bootstrap Admin flow for a company whose email is already registered, the backend may return the existing user record instead of creating a new one. No temporary password is generated in this case. The UI will not display a password field. Confirm with the tenant admin that they can still access their account before assuming the bootstrapping step needs to be repeated.
No persisted RFID policy for a module
No persisted RFID policy for a module
If a module (e.g., Receipts) has never had its RFID policy saved, the policy form renders with frontend-defined default values. These defaults are not written to the backend until the operator clicks Save. Until then, the backend falls back to its own internal defaults for that module. Ensure you save each module policy explicitly after reviewing the defaults.
Backend returns ignoreDuplicateReadsWithinWindow
Backend returns ignoreDuplicateReadsWithinWindow
When this flag is true on a retrieved policy, the duplicate tag behavior dropdown in the policy form is rendered in a disabled state. The UI infers that the backend is managing duplicate suppression at the window level and does not allow a conflicting manual override.
RFID event with no CorrelationId, SessionId, or valid JSON metadata
RFID event with no CorrelationId, SessionId, or valid JSON metadata
Events viewed from the company detail RFID events panel follow the same rendering rules as the tenant RFID Events screen. Missing CorrelationId or SessionId display as dashes. Invalid or plain-text MetadataJson renders as raw text. The detail dialog remains stable in all cases.