Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The Workbench Module is designed to manage Master Data Management System (MDMS) data and localization data within the system. This module supports comprehensive CRUD operations (Create, Read, Update, Delete) for both MDMS data and localization settings, ensuring efficient and seamless data management across the application. When users interact with the Workbench Module to set up any module, the base Workbench fetches the required MDMS data, determines the number of masters that need to be configured, and loads them accordingly.
Workbench Home: Displays the main dashboard for MDMS and localization management features.
Setup MDMS: Provides functionality to configure and manage MDMS data structures and schemas.
Create MDMS Data: Allows the creation of new entries in the MDMS, including defining data attributes and relationships.
Edit MDMS Data: Enables the modification of existing MDMS entries, allowing updates to data attributes and relationships.
Manage Localization: Provides tools for managing localization data, including adding, editing, and deleting localized content.
Create Localization Data: Allows the addition of new localization entries for supported languages.
Edit Localization Data: Enables the editing of existing localization entries to ensure up-to-date and accurate translations.
Workbench Home:
Screen Route: /sandbox-ui/workbench/home
Data Fetch: Retrieves an overview of MDMS and localization data, including tenant-specific configurations and available datasets.
Client Store: Updates the client store with the fetched data for display on the dashboard.
Setup MDMS:
Screen Route: /sandbox-ui/workbench/mdms-setup
Data Fetch: Retrieves details on MDMS schemas, data structures, and related configurations from the MDMS.
Client Store: Updates the client store with setup details, enabling management of MDMS configurations.
Create MDMS Data:
Screen Route: Accessed via the Setup MDMS component.
Data Fetch: Fetches schema and structural data from MDMS to facilitate the creation of new entries.
Client Store: Updates the client store with new data after creation, ensuring the data is reflected across the system.
Edit MDMS Data:
Screen Route: Accessed via the Setup MDMS component.
Data Fetch: Retrieves existing MDMS data based on the selected entry for editing, including related schema details.
Client Store: Updates the client store with edited data upon submission, ensuring accurate data representation.
Manage Localization:
Screen Route: /sandbox-ui/workbench/localization-manage
Data Fetch: Retrieves existing localization data, including supported languages and current translations.
Client Store: Updates the client store with localization data for management and display.
Create Localization Data:
Screen Route: Accessed via the Manage Localization component.
Data Fetch: Fetches the list of supported languages and existing localization keys from the system.
Client Store: Updates the client store with newly created localization entries.
Edit Localization Data:
Screen Route: Accessed via the Manage Localization component.
Data Fetch: Retrieves existing localization data for editing, including language-specific entries.
Client Store: Updates the client store with edited localization data after submission.
The Workbench Module fetches tenant information from the host app to ensure data consistency.
Synchronizes tenant data and related configurations between the host app and the Workbench Module.
Workbench Home Screen: Displays a comprehensive dashboard for managing MDMS and localization features, with options to view, manage, create, or edit entries.
Setup MDMS Screen: Provides tools for managing MDMS data structures, including schema configuration and data entry points.
Create MDMS Data Screen: A form to define and submit new MDMS data entries.
Edit MDMS Data Screen: A form pre-populated with existing data for editing and submission.
Manage Localization Screen: Tools for managing localization entries, including viewing, adding, editing, or deleting localized content.
Create Localization Data Screen: A form to input new localization details, including translations for supported languages.
Edit Localization Data Screen: A form pre-filled with existing localization data for modification and submission.
The User Module handles the user authentication process, including signup, sign-in, OTP verification, and redirection to appropriate screens based on user actions and authentication status. This module also manages tenant information fetched from the host app.
Signup: Handles new user registration.
Enter OTP: Manages OTP entry for verification.
Successful Signup: Confirmation screen after successful signup.
SignIn: Manages user login.
Home Screen: Displays after successful sign-in or signup.
App Home Screen: Main application screen for authenticated users.
Signup Process:
The user enters signup details.
On form submission, the user is redirected to the OTP entry screen.
OTP Verification:
The user enters OTP.
On successful OTP verification, the user is redirected to the successful signup screen.
SignIn Process:
The user enters login credentials.
On form submission, the user is redirected to the OTP entry screen for verification.
Post Authentication:
After successful signup or sign-in, the user is redirected to the home screen.
The home screen displays the setup for the sandbox app drawer and a help/tutorial video based on BFF (Backend for Frontend) response.
Main Application:
Fetches application states from BFF.
Redirects authenticated users to the app home screen.
The following screens based on the default Tenant
Response screen will have the Client Sandbox Admin Portal Link
The following screens based on the Account/Client Tenant
The Account Management Module is responsible for handling tenant information within the application. It includes components for displaying tenant homes, managing tenants, creating new tenants, and editing existing tenants. This module interacts with the host app to fetch tenant details and perform CRUD operations.
Tenant Home: Displays the main tenant dashboard with a list of tenants.
Manage Tenant: Provides functionality to manage existing tenants.
Create Tenant: Allows the creation of new tenants.
Edit Tenant: Enables editing of existing tenant information.
Tenant Home:
Screen Route: /sandbox-ui/account/tenant-home
Data Fetch: Retrieves list of tenants from MDMS (Master Data Management System), tenant name, address, and other relevant details.
Client Store: Updates client store with fetched data for display.
Manage Tenant:
Screen Route: /sandbox-ui/account/tenant-manage
Data Fetch: Retrieves tenant details from MDMS, including home address and other necessary information.
Client Store: Updates client store with tenant details for management.
Create Tenant:
Screen Route: Accessed from Manage Tenant component.
Data Fetch: Fetches data from MDMS, including subdomain and tenant name.
Client Store: Updates client store with new tenant information upon creation.
Edit Tenant:
Screen Route: Accessed from Manage Tenant component.
Data Fetch: Retrieves existing tenant details from MDMS, including subdomain and other information for editing.
Client Store: Updates client store with edited tenant information.
The Tenant Management Module fetches the tenant from the host app.
Ensures synchronization between tenant data in the host app and the Tenant Management Module.
The Boundary Management Module is designed to manage Boundary data within the system. This includes components, setting up master data, creating new entries,
1. Boundary Home
Purpose: The main landing page for the Boundary Management module.
Components:
Navigation to other submodules.
Display of tenant information retrieved from the host app.
2. Boundary Hierarchy Type Selection/Creation
Purpose: Allows users to select or create a boundary hierarchy type.
Components:
Dropdown or list for selecting existing hierarchy types.
Button or form to create a new hierarchy type.
3. Create Hierarchy
Purpose: Interface for creating a new boundary hierarchy.
Components:
Form fields to input hierarchy details.
Validation and submission controls.
4. Create Boundary Data
Purpose: Interface for creating boundary data within the selected hierarchy.
Components:
Form fields to input boundary data.
Dropdowns or selectors for hierarchy levels.
Validation and submission controls.
5. View Boundary Upload Status
Purpose: Displays the status of boundary data uploads.
Components:
Table or list view to display upload statuses.
Filters and search functionality for easier navigation.
Users start at the Boundary Home.
From Boundary Home, they can navigate to Boundary Hierarchy Type Selection/Creation.
In Boundary Hierarchy Type Selection/Creation, they can either select an existing hierarchy or navigate to Create Hierarchy to create a new one.
After selecting or creating a hierarchy, users move to Create Boundary Data to input boundary details.
Finally, users can navigate to View Boundary Upload Status to check the status of their uploads.
The Application Management Module is designed to manage application features and settings within the system. This includes components for viewing the application home, managing features, setting up master data, creating new entries, and editing existing entries. The module interacts with the host app to fetch tenant information and performs CRUD operations on application-related data.
Application Home: Displays the main dashboard for application features.
Setup Master: Provides functionality to set up master data for the application.
Create Master: Allows the creation of new master data entries.
Edit Master: Enables editing of existing master data entries.
Application Home:
Screen Route: /sandbox-ui/application/app-home/module/{module-features}
Data Fetch: Retrieves application features from MDMS (Master Data Management System), including application details and tenant information.
Client Store: Updates client store with fetched data for display.
Setup Master:
Screen Route: /sandbox-ui/application/tenant-manage
Data Fetch: Retrieves master data setup details from MDMS, including subdomains and other relevant data.
Client Store: Updates client store with setup data for management.
Create Master:
Screen Route: Accessed from Setup Master component.
Data Fetch: Fetches data from MDMS, including subdomain and master data details.
Client Store: Updates client store with new master data information upon creation.
Edit Master:
Screen Route: Accessed from Setup Master component.
Data Fetch: Retrieves existing master data details from MDMS, including subdomain and other information for editing.
Client Store: Updates client store with edited master data information.
The Application Management Module fetches the tenant from the host app.
Ensures synchronization between tenant data in the host app and the Application Management Module.
Application Home Screen: Displays a list of application features with options to view, manage, create, or edit features.
Setup Master Screen: Provides options to manage master data setup, including viewing and editing.
Create Master Screen: Form to input new master data details and submit for creation.
Edit Master Screen: Form pre-filled with existing master data details for modification and submission.
Impact Changes Details On Client Apps
The DIGIT UI framework requires updates to support handling multiple tenants and integrate seamlessly with Sandbox environments. This involves modifications to the global configuration, core UI components, and various modules to ensure smooth functionality.
Current State:
The global configuration is designed to handle single-tenant information from the base application.
Required Changes:
Update Configuration: Modify the global configuration to support multiple tenants.
Configuration Structure: Redesign the configuration structure to include tenant-specific settings.
Dynamic Loading: Implement logic to dynamically load tenant configurations based on the tenant information received from the base application.
Impact:
Ensures the application can handle requests from multiple tenants simultaneously.
Improves scalability and flexibility of the Digit UI framework.
Current State:
Core UI components are designed to fetch and display data for a single tenant.
Access control logic is based on single-tenant information.
Required Changes:
Fetch Logic: Update the core UI components to fetch data based on the tenant context.
Tenant Context: Introduce a mechanism to pass tenant context to UI components.
Access Control: Revise the access control logic to consider multiple tenants.
Role-Based Access: Ensure role-based access control supports multiple tenants by updating the roles and permissions structure.
User Service: Integrate with the new User Service.
Impact:
Enhances the core UI components to be tenant-aware.
Ensures accurate data fetching and access control across multiple tenants.
Maintains security and proper access management in a multi-tenant environment.
Current State: Modules need to fetch the module tenant configuration and operate accordingly, either at the tenant or subtenant level. The same applies to boundary hierarchies, as the system will contain multiple boundary hierarchy definitions and datasets. Thus, the module should determine which hierarchy and level it should function within.
Required Changes:
Tenant Awareness: Make all modules tenant-aware by updating their internal logic to handle multiple tenants.
Module Initialization: Ensure modules initialize correctly with tenant-specific data.
Data Handling: Adapt data handling processes within modules to support multiple tenants.
Impact:
Enables modules to function correctly in a multi-tenant setup.
Ensures data integrity and consistency across different tenant contexts.
Complaints Modules following Master Data to be created, to enable it.
HRMS:
HRMS Modules following Master Data to be created, to enable it.
HCM:
Health Modules following Master Data to be created, to enable it.