Institute User Model

Business Purpose: An extension of the base User model, specific to an institute. It links a core system user to an institute and defines their role within that institute (e.g., "Institute Admin").

Core Concept: Extending the Built-in User

This design pattern is used to add application-specific information to the core user system without modifying it directly. Here’s how it works:

1. Core User Model: Your SolidX application has a built-in User model provided by the core framework. Its primary job is to handle authentication (i.e., verifying a user's identity with a username and password so they can log in).

2. InstituteUser Model: To give a user special permissions related to an institute, you create a new InstituteUser model. This model is defined as a "Child Model" of the core User model.

3. The Connection: The InstituteUser model doesn't replace the User model; it extends it. It holds additional information that is only relevant to your specific application, such as:

   • A link to the User it belongs to.
   • A link to the specific institute the user manages.
   • The user's role within that institute (e.g., "Institute Admin").

In simple terms: A person can log in because they exist in the central User table. The system then checks the InstituteUser table to see if that logged-in user is linked to an institute. If a link exists, the system knows they are an "Institute Admin" and grants them the necessary permissions.

This approach is a best practice because it keeps your application's logic separate from the core framework, making the system more modular, secure, and easier to upgrade.

Fields:

Key Fields Explained

• Child Model (isChild: true): This is a special type of model in SolidX. Notice the isChild: true and parentModelUserKey: "user" properties in the JSON. This tells SolidX that InstituteUser is not a standalone entity; instead, it extends the built-in User model from the Solid Core module.
• How it Works: When you create a new User in the system, you can now also create an associated InstituteUser record for them. This allows you to add institute-specific properties (like userType and the institute they belong to) to a core user, which is a powerful pattern for multi-tenancy. A single user could potentially have roles in multiple institutes by having multiple InstituteUser records.

Creation Steps

If you are following the manual "Guided Tour", follow these steps to create the Institute User model in the App Builder.

1. Navigate to Fees Portal > App Builder > Model and click Add.
2. Fill in the primary details for the model:
   • Singular Name: instituteUser
   • Plural Name: instituteUsers
   • Display Name: Institute User
   • Is Child Model: Check this box.
   • Parent Model: Select user from the dropdown.
3. Go to the Fields tab.
4. Click Add Field and create each field exactly as defined in the table above.
5. Click Save.

You're Done with Data Modeling! Once you have created this final model, you have finished the data modeling stage. The last step is to generate the code for all the new models you've created. In your solid-api terminal, run:

solid refresh-module -n fees-portal

This command will create all the necessary backend files for your new models. After it completes and the server restarts, you will see all your new models appear in the sidebar under the "Fees Portal" menu.

For the Fast Track: Model Metadata The JSON block below contains the complete metadata definition for the Institute User model.

This definition is structured with top-level properties for the model itself (like singularName, pluralName, tableName) and a fields array that defines every attribute you see in the table above.

You can use this metadata as part of the "Fast Track" approach by including it in the main fees-portal-metadata.json file.

{
  "singularName": "instituteUser",
  "pluralName": "instituteUsers",
  "displayName": "Institute User",
  "description": "This table allows us to store institute user records",
  "dataSource": "default",
  "dataSourceType": "postgres",
  "tableName": "fees_portal_institute_user",
  "isChild": true,
  "parentModelUserKey": "user",
  "enableAuditTracking": true,
  "enableSoftDelete": false,
  "draftPublishWorkflow": false,
  "internationalisation": false,
  "fields": [
    {
      "name": "userType",
      "displayName": "User Type",
      "description": null,
      "type": "selectionStatic",
      "ormType": "varchar",
      "isSystem": false,
      "defaultValue": "Institute Admin",
      "selectionStaticValues": [
        "Institute Admin:Institute Admin"
      ],
      "selectionValueType": "string",
      "required": true,
      "unique": false,
      "index": false,
      "private": false,
      "encrypt": false,
      "encryptionType": null,
      "decryptWhen": null,
      "columnName": null,
      "enableAuditTracking": true,
      "isMultiSelect": false
    },
    {
      "name": "institute",
      "displayName": "Institute",
      "description": null,
      "type": "relation",
      "ormType": "integer",
      "isSystem": false,
      "relationType": "many-to-one",
      "relationCoModelFieldName": "instituteUsers",
      "relationCreateInverse": true,
      "relationCoModelSingularName": "institute",
      "relationCoModelColumnName": null,
      "relationModelModuleName": "fees-portal",
      "relationCascade": "cascade",
      "required": false,
      "unique": false,
      "index": false,
      "private": false,
      "encrypt": false,
      "encryptionType": null,
      "decryptWhen": null,
      "columnName": null,
      "relationJoinTableName": null,
      "isRelationManyToManyOwner": null,
      "relationFieldFixedFilter": "",
      "enableAuditTracking": true
    }
  ]
}