====== Modules Table - Complete Guide ====== This guide provides a step-by-step approach to correctly fill the Modules table in your database. The Modules table stores information about different functional modules available in the system, allowing you to: - Activate or deactivate modules per client - Create a parent-child module structure - Set a default module per client - Upload logos and icons for each module - Control the display order of modules You can find the detailed structure of the Modules table here: [[modules|Modules Table Structure]] ===== Modules Table Structure Overview ===== Here’s a quick overview of the Modules Table Schema: ^ Field Name ^ Type ^ Description ^ | id | Primary Key | Auto-incremented unique ID for each module | | clientid | Foreign Key | ID of the client associated with the module | | modulename | varchar(50) | Name of the module visible in the front-end and back-end | | parentmoduleid | int | ID of the parent module if this module is a sub-module | | defaultmodule | int | Whether this is the default module 1=Yes, 0=No | | dependentmodules | varchar(200) | Comma-separated list of module IDs that this module depends on | | ord | int | Defines the display order of modules in the app. Lower numbers appear first | | modulelogo | blob | Binary image data for the module's logo | | appiconname | varchar(250) | Name of the icon file displayed in the app | | status | int | Module status 1=Active, 0=Inactive | ==== Step 1: Add the Module ID (id) ==== The id column acts as the Primary Key for the Modules table. - It is auto-incremented, meaning the database automatically generates a unique ID for each module. - You do not need to enter this manually. **Example:** ^ Scenario ^ id ^ | First Module | 1 | | Second Module | 2 | ==== Step 2: Link the Module to a Client (clientid) ==== The clientid column acts as a Foreign Key linking the module to a specific client. - This is crucial when working in multi-client environments where different clients may have different modules. - It ensures that each client has specific modules. - Clients will only see the modules assigned to them. **Example:** ^ Client ^ clientid ^ | Client A | 101 | | Client B | 102 | If creating a module for Client A, set: clientid = 101 If creating a module for Client B, set: clientid = 102 ==== Step 3: Set the Module Name (modulename) ==== The modulename column contains the visible name of the module that appears in: - The back-end (admin panel) - The front-end (client panel) **Example:** ^ Module Name ^ modulename ^ | Reports | Reports | | User Management | User Management | **Note:** Ensure the module name is unique per client. ==== Step 4: Set the Parent Module ID (parentmoduleid) ==== The parentmoduleid column is used to establish a parent-child relationship between modules. - If the module has a parent module, enter the id of the parent module. - If the module is independent, set this value to NULL. **Why Use a Parent Module?** - It creates a hierarchical structure like Reports > Sales Reports. - The sub-modules only appear when the parent module is enabled. **Example:** ^ Module Name ^ id ^ parentmoduleid ^ | Reports | 1 | NULL | | Sales Reports | 2 | 1 | This means Sales Reports will only appear if Reports is enabled. ==== Step 5: Mark the Default Module (defaultmodule) ==== The defaultmodule column specifies if this module is the default landing page for the client. 1 = Default Module\\ 0 = Not Default Only one module can be marked as default per client. **Example:** ^ Module Name ^ defaultmodule ^ | Dashboard | 1 | | Reports | 0 | If no module is marked as default, the system will load the first active module. ==== Step 6: Add Dependent Modules (dependentmodules) ==== The dependentmodules column stores a comma-separated list of module IDs that depend on this module. **Why Use This Field?** If Module A relies on Module B, you can enforce that Module A only works if Module B is enabled. **Example:** ^ Module Name ^ dependentmodules ^ | Sales Reports | 1 | | User Management | 2,3,5 | Leave this blank if no modules depend on this. ==== Step 7: Set the Module Order (ord) ==== The ord column controls the display order of the modules in the app. Modules with lower values appear first.\\ Modules with higher values appear last. **Example:** ^ Module Name ^ ord ^ | Dashboard | 1 | | Reports | 2 | | Settings | 3 | **Best practice:** Always set a unique order value. ==== Step 8: Upload the Module Logo (modulelogo) ==== The modulelogo column stores the module’s logo in binary format (BLOB). **Supported Image Types:** PNG\\ JPG\\ SVG **Maximum Dimensions:** 100x100 pixels You can upload the logo from the admin panel or via SQL. ==== Step 9: Add the App Icon Name (appiconname) ==== The appiconname column allows you to specify the name of the icon file shown in the mobile app or web app. **Example:** ^ Module Name ^ appiconname ^ | Reports | reports_icon.png | | User Management | user_icon.svg | **Note:** This is only the file name, not the image itself. ==== Step 10: Set the Module Status (status) ==== The status column determines if the module is active or inactive. **Status Values:** ^ Value ^ Status ^ | 1 | Active | | 0 | Inactive | If a module is inactive, it will be hidden from both the client panel and admin panel. **Example:** ^ Module Name ^ status ^ | Reports | 1 | | User Management | 0 | ==== Final Example Record (Complete Module) ==== Here’s how a complete module record would look: ^ id ^ clientid ^ modulename ^ parentmoduleid ^ defaultmodule ^ dependentmodules ^ ord ^ modulelogo ^ appiconname ^ status ^ | 1 | 101 | Reports | NULL | 0 | | 1 | reports_icon.png | reports_icon.png | 1 | | 2 | 101 | Sales Reports | 1 | 0 | 1 | 2 | sales_icon.png | sales_icon.png | 1 | ==== Important Notes ==== - Always assign a unique order (ord) to prevent display conflicts. - Avoid setting more than one default module per client. - Parent-child module relationships are only visible if the parent module is active.