**JSON Pointer:** `/moduleMetadata/models`
@@ -26,31 +22,28 @@ solidx_concerns: [create_model_with_fields, add_field_to_a_model, remove_field_f
## Overview
-SolidX Models represent the structure of your data within a module. Each model defines a specific type of data, all attributes / fields that a model is made of & its relationships with other models.
+Model metadata defines the strcuture of data that exist inside a SolidX module.
-Each model is a semantic, configurable data structure that forms the basis of adding custom business logic.
+Each model establishes persistence, naming, lifecycle behaviour, and runtime flags for one business entity. Generated APIs, layouts, permissions, relations, and code-generation flows all build on that model definition.
- If a module is a business domain, a model is one important noun inside that domain. Models do more than define storage. They become the anchor for generated APIs, permissions, layouts, relations, and backend behavior.
- - Think in terms of business records such as venue, institute, fee type, or booking.
- - Use model metadata to express identity, persistence, and lifecycle behavior.
- - Choose model boundaries carefully because many platform features build on top of them.
- So the intuition is: a model is the platform's unit of record and behavior inside a module.
+ If a module is a business domain, a model is one business record type inside that domain.
+
+ - Think in terms of records such as `venue`, `institute`, `feeType`, or `booking`.
+ - Use model metadata to express identity, persistence, and lifecycle behaviour.
+ - Choose model boundaries carefully because many platform features build on top of them.
-👉 For a conceptual overview of what a model is, see [Model Management Documentation](/docs/admin-docs/module-builder/model-management).
+For admin-side authoring workflows, see [Model Management Documentation](/docs/admin-docs/module-builder/model-management).
### Example: Institute Model
-
-
- Model Schema
-
+ Model schema example
```json
{
@@ -94,15 +87,11 @@ Each model is a semantic, configurable data structure that forms the basis of ad
},
... // Other metadata
}
-```
+```
-
-
-
-## Model Metadata Attributes
-
+## Model Metadata Attributes
### `singularName` *(string, required, unique)*
Unique identifier for the model (lowercase, underscores/dashes).
@@ -209,13 +198,6 @@ Indicates whether this model maps to a pre-existing legacy table and, if so, how
When set to `"existing_id"` or `"generated_id"`, at least one field must be marked as `isPrimaryKey: true`.
**Default:** `"none"`
-
-
-
-
-## Related Recipes (TODO)
-
-
+## Related Recipes
👉 [Model Type Recipes](../../admin-docs/module-builder/model-management#related-recipes)
-**Default:** `false`
diff --git a/content/docs/developer-docs/metadata_schema/module-metadata.mdx b/content/docs/developer-docs/metadata_schema/module-metadata.mdx
index 98e93dd..d65b804 100644
--- a/content/docs/developer-docs/metadata_schema/module-metadata.mdx
+++ b/content/docs/developer-docs/metadata_schema/module-metadata.mdx
@@ -2,7 +2,7 @@
title: Modules
icon: "package"
description: Overview of the module metadata schema used in SolidX.
-summary: This document explains the module metadata schema in SolidX, which represents the top-level building blocks for organizing applications. A module groups related models and functionality under a unified domain (like a Fees Portal module). The metadata includes properties such as module name, display name, description, default data source, menu icon, sequence number, and system flag. Examples demonstrate configuring module metadata for applications, and the document references the admin documentation for conceptual understanding of module management and the hierarchical relationship where modules contain models which contain fields.
+summary: Covers the top-level metadata used to define a SolidX module, including identity, data-source defaults, menu behavior, and module-level configuration.
json_pointer: "/moduleMetadata"
jsonpath: "$.moduleMetadata"
parent_component: root
@@ -11,10 +11,6 @@ items_attributes_doc: "#module-metadata-attributes"
solidx_concerns: [create_module]
---
-
-
-# Module Metadata
-
**JSON Pointer:** `/moduleMetadata`
@@ -23,30 +19,28 @@ solidx_concerns: [create_module]
-## Overview
+## Overview
+
+Module metadata defines the top-level boundary of a SolidX business domain.
-When creating a new module in SolidX, you're defining a **core building block** of your application.
-A module groups together related models and functionality under a **unified domain**.
+It identifies the module, establishes its default data-source behaviour, and provides the root container under which related models, views, menus, and other metadata records are organized.
- A module is the top-level business boundary in SolidX. It is not just a folder or namespace. It is the container that tells the platform which models, views, menu entries, and behaviors belong to one domain.
- - Start by asking: what business capability are we modelling?
- - Put closely related models inside the same module.
- - Use the module to define the identity of that domain inside the app.
- So the intuition is: a module is the platform's unit of business ownership.
+ A module is the top-level business boundary in SolidX. It is not just a folder or namespace.
+
+ - Start by asking which business capability the module owns.
+ - Group closely related models, views, actions, and menus inside that boundary.
+ - Use the module record to establish the identity of that domain across the platform.
-👉 For a conceptual overview of what a module is, see [Module Management Documentation](../../admin-docs/module-builder/module-management.md).
+For admin-side authoring workflows, see [Module Management Documentation](../../admin-docs/module-builder/module-management.md).
-### Example: Fees Portal Module
-Below is a module metadata example for a "Fees Portal" module that tracks fee collection requests.
+### Example: Fees Portal Module
+Below is a representative module record for a `fees-portal` domain.
-
-
- Module Schema
-
+ Module schema example
```json
{
@@ -65,17 +59,11 @@ Below is a module metadata example for a "Fees Portal" module that tracks fee co
```
+In this example, `defaultDataSource` is set to `default`, which points to the default TypeORM data source configured in your `app-default-database.module.ts` in your project `solid-api` src folder.
- The defaultDataSource is set to "default" here, which refers to the default data source configured in your SolidX instance. This is the TypeORM data source configured in your app-default.database.ts in your project `solid-api` src folder.
-
-
-
-
-
## Module Metadata Attributes
-
### `name` *(string, required, unique)*
diff --git a/content/docs/developer-docs/metadata_schema/predefined-searches.mdx b/content/docs/developer-docs/metadata_schema/predefined-searches.mdx
index 24a357a..e338e2b 100644
--- a/content/docs/developer-docs/metadata_schema/predefined-searches.mdx
+++ b/content/docs/developer-docs/metadata_schema/predefined-searches.mdx
@@ -2,7 +2,7 @@
title: Predefined Searches
icon: "search"
description: Metadata schema for defining predefined searches in SolidX list views.
-summary: This document describes predefined searches metadata in SolidX, which enables configuration of named search presets that appear by default in the search dialog on list views. Each predefined search has a name, an optional description, and a filter expression using query operators. The filters support dynamic placeholders such as {{search}} for user input. Examples demonstrate configuring searches for book titles and availability status. This is useful for surfacing common or business-critical search patterns without requiring users to build filters manually.
+summary: Covers named search presets for SolidX list views, including filter expressions, optional descriptions, and dynamic placeholders such as `{{search}}`.
json_pointer: "/views/{index}/layout/attrs/predefinedSearches"
jsonpath: "$.views[*].layout.attrs.predefinedSearches"
parent_component: views
@@ -11,7 +11,6 @@ items_type: "object"
items_attributes_doc: "#predefined-searches-attributes"
---
-# Predefined Searches
**JSON Pointer:** `/views/{index}/layout/attrs/predefinedSearches`
@@ -28,7 +27,8 @@ Each preset is displayed as a selectable option in the list view's search panel.
## Example: Predefined Searches Metadata
- Predefined Searches Schema
+
+Predefined searches schema example
``` json
{
@@ -72,12 +72,9 @@ Each preset is displayed as a selectable option in the list view's search panel.
]
}
```
-
-
-
+
## Predefined Searches Attributes
-
### `name` *(string, required, unique within view)*
The label displayed for this search preset in the search dialog. Users will see this name when selecting a search option from the list.
@@ -117,5 +114,4 @@ The filter expression applied when this search preset is selected. Uses the Soli
```
- The {"{{search}}"} placeholder is replaced at runtime with whatever the user types in the search input. If no placeholder is used, the filter acts as a static preset that does not depend on user input.
-
+The {"{{search}}"} placeholder is replaced at runtime with the value typed by the user in search input. If no placeholder is used, the filter behaves as a static preset that does not depend on user input.
diff --git a/content/docs/developer-docs/metadata_schema/roles-permissions-metadata.mdx b/content/docs/developer-docs/metadata_schema/roles-permissions-metadata.mdx
index 38a0130..d38d062 100644
--- a/content/docs/developer-docs/metadata_schema/roles-permissions-metadata.mdx
+++ b/content/docs/developer-docs/metadata_schema/roles-permissions-metadata.mdx
@@ -2,7 +2,7 @@
title: Roles & Permissions
icon: "shield"
description: Metadata schema for defining roles and permissions in SolidX applications.
-summary: This document explains roles and permissions metadata in SolidX, which provides role-based access control at a high level. Roles group permissions and can be assigned to users, while permissions are automatically discovered based on controller actions for fine-grained control. Each role has a name and description, with permissions specified as an array of controller method names (e.g., "InstituteController.create", "InstituteController.findMany"). The system includes a default Admin role with all permissions. Examples demonstrate creating custom roles like Institute Admin with specific permission sets for managing institute-related operations.
+summary: Covers the metadata used to define roles, assign permissions, and control high-level access in SolidX.
json_pointer: "/roles"
jsonpath: "$.roles"
parent_component: root
@@ -12,8 +12,6 @@ items_attributes_doc: "#roles-permissions-metadata-attributes"
solidx_concerns: [add_new_role_with_permission, modify_role]
---
-
-# Roles & Permissions
**JSON Pointer:** `/roles`
@@ -24,18 +22,19 @@ solidx_concerns: [add_new_role_with_permission, modify_role]
## Overview
-Roles in SolidX provide a way to group permissions and manage access control at a high level. Each role represents a set of permissions that can be assigned to users.
-Permissions in SOLID are automatically discovered based on controller actions and provide fine-grained control over what users can do within the system.
+Roles and permissions define high-level access control in SolidX.
+
+Permissions are discovered from backend controller methods and represent individual capabilities such as `InstituteController.findMany` or `InstituteController.update`. Roles package those capabilities into reusable access profiles that can be assigned to users.
-By Default `Admin` role is created with all permissions.
+By default, the `Admin` role is created with all discovered permissions.
- Roles and permissions in SolidX work as a two-layer access model. Permissions represent the fine-grained actions the platform knows about, while roles are the business-facing bundles you assign to users.
- - Think of permissions as capabilities discovered from the backend.
- - Think of roles as the practical packaging of those capabilities for real users.
- - Use roles to express job function, not just technical access flags.
- So the intuition is: permissions describe what the system can do, and roles describe who should be allowed to do it.
+Roles and permissions work as a two-layer access model.
+
+- Permissions describe what the system can do. Think of permissions as backend-discovered capabilities.
+- Roles describe who should be allowed to do it. Think of roles as the business-facing grouping of those capabilities.
+- Use roles to express job function, not only technical access flags.
@@ -43,7 +42,8 @@ By Default `Admin` role is created with all permissions.
### Example: Fee Portal Module Roles & Permissions Metadata
- Roles & Permissions Schema
+
+Roles and permissions schema example
```json
{
@@ -68,13 +68,10 @@ By Default `Admin` role is created with all permissions.
]
}
```
+
-
-
-
## Roles & Permissions Metadata Attributes
-
### `name` _(string, required, unique)_
@@ -96,6 +93,4 @@ An array of permission strings associated with the role. Each permission corresp
-Permissions are automatically discovered based on controller methods in the codebase. So for e.g., if you have a controller for managing institutes with methods like create, the permission `InstituteController.create` will be automatically created.
-
-
+Permissions are discovered from controller methods in the codebase. For example, a controller method such as `InstituteController.create` produces the permission `InstituteController.create`.
diff --git a/content/docs/developer-docs/metadata_schema/scheduled-jobs.mdx b/content/docs/developer-docs/metadata_schema/scheduled-jobs.mdx
index e4ffbb2..91dc59b 100644
--- a/content/docs/developer-docs/metadata_schema/scheduled-jobs.mdx
+++ b/content/docs/developer-docs/metadata_schema/scheduled-jobs.mdx
@@ -2,7 +2,7 @@
title: Scheduled Jobs
icon: "clock"
description: Metadata schema for defining scheduled jobs in SolidX applications.
-summary: This document describes scheduled jobs metadata in SolidX, which enables configuration of recurring tasks such as sending notifications, cleaning up records, data synchronization, or regular maintenance. The metadata includes schedule name, active status flag, frequency specification, days of week when the job should run, the job class name to execute, and associated module reference. Examples demonstrate configuring late fee calculation jobs that run at specified intervals. The document links to detailed guides on creating and managing scheduled jobs in the backend customization section.
+summary: Covers the metadata used to define recurring jobs in SolidX, including schedule name, frequency, active state, execution class, and module association.
json_pointer: "/scheduledJobs"
jsonpath: "$.scheduledJobs"
parent_component: root
@@ -21,13 +21,15 @@ solidx_concerns: [add_scheduled_job]
## Overview
-Scheduled jobs in SolidX allow you to run recurring tasks such as sending notifications, cleaning up records, syncing data, or performing regular maintenance.
+Scheduled jobs in SolidX let you run recurring background tasks such as sending notifications, cleaning up records, syncing data, or performing regular maintenance.
-For a guide on how to create and manage scheduled jobs in SolidX, refer to the [Creating Scheduled Jobs](/docs/developer-docs/extending/backend-customization/scheduled-jobs).
+Use this metadata to register the job class, define execution frequency, and control when the job is allowed to run. For a guide on how to create and manage scheduled jobs in SolidX, refer to the [Creating Scheduled Jobs](/docs/developer-docs/extending/backend-customization/scheduled-jobs).
## Example: Scheduled Jobs Metadata
+This example configures a scheduled job for late fee calculation.
- Scheduled Jobs Schema
+
+Scheduled jobs schema example
``` json
{
@@ -43,6 +45,7 @@ For a guide on how to create and manage scheduled jobs in SolidX, refer to the [
]
}
```
+
## Scheduled Jobs Metadata Attributes
@@ -102,12 +105,12 @@ The exact class name of the job implementation to execute (case-sensitive). This
**Example:** `"LateFeeCalculatorJob"`
-### `dayOfWeek` *(string, mandatory for Weekly frequency)*
-Days of the week on which the job should run (applicable for weekly frequency). This should be a JSON array of day names. Please ensure that the value is a valid JSON array string in stringified format.
+### `dayOfWeek` *(string, required for `Weekly` frequency)*
+Days of the week on which the job should run. This value should be provided as a JSON array of day names in stringified format.
**Example:** `["Monday", "Wednesday", "Friday"]`
**Applies to:** `Weekly` frequency
-Currently the configuration expects json configuration in stringified format.
+Currently this configuration expects a stringified JSON array.
### `dayOfMonth` *(number \| null, optional)*
Day of the month on which the job should run. Only enforced when `frequency` is `"Monthly"`.
diff --git a/content/docs/developer-docs/metadata_schema/security-rules.mdx b/content/docs/developer-docs/metadata_schema/security-rules.mdx
index 067f25f..3ca70e4 100644
--- a/content/docs/developer-docs/metadata_schema/security-rules.mdx
+++ b/content/docs/developer-docs/metadata_schema/security-rules.mdx
@@ -2,7 +2,7 @@
title: Security Rules
icon: "lock"
description: Metadata schema for defining security rules in SolidX applications.
-summary: This document explains security rules metadata in SolidX, which controls data access at the model level to ensure only authorized users can view sensitive information. Each rule includes a name, description, associated role, target model, and security rule configuration with filter conditions. The filter configuration supports complex query structures using operators like $eq with dynamic values such as $activeUserId for user-specific data filtering. Examples demonstrate restricting fee type visibility to institute users through relational filtering across associated models. The document links to detailed guides on creating and managing security rules in the backend customization section.
+summary: Covers the metadata used to define model-level access rules, role binding, and filter-based record visibility in SolidX.
json_pointer: "/securityRules"
jsonpath: "$.securityRules"
parent_component: root
@@ -12,7 +12,6 @@ items_attributes_doc: "#security-rules-metadata-attributes"
solidx_concerns: [add/update_security_record_rule]
---
-# Security Rules
**JSON Pointer:** `/securityRules`
@@ -30,17 +29,20 @@ Security rules are crucial for controlling access to data in SolidX. By defining
Roles and permissions decide whether a user can invoke an action at all. Security rules answer a second question: which records should that user actually be able to see or act on?
+
- Use permissions for action-level access.
- - Use security rules for record-level visibility and filtering.
- - Treat security rules as business visibility policy encoded in metadata.
- So the intuition is: security rules are the row-level guardrails layered on top of role-based access.
+ - Use security rules for record-level visibility and filtering.
+ - Treat security rules as business visibility policy encoded in metadata.
+
+Security rules are the row-level guardrails layered on top of role-based access.
For a guide on how to create and manage security rules in SolidX, refer to the [Creating Security Rules](../extending/backend-customization/security-rules).
## Example: Security Rules Metadata
- Security Rules Schema
+
+Security rules schema example
``` json
{
@@ -66,12 +68,9 @@ For a guide on how to create and manage security rules in SolidX, refer to the [
]
}
```
-
-
-
+
## Security Rules Metadata Attributes
-
@@ -92,8 +91,9 @@ The user key of the model (entity) to which this security rule applies. This hel
A JSON object defining the actual security rule configuration. This typically includes filters that determine which records are accessible based on the active user's context.
Contains a json object with a `filters` key that defines the filtering logic. The filters object is consistent with the filter structure used in queries, allowing for complex conditions and relationships.
-#### Further Reference
- - Understanding Filters: See [Filters Documentation](../rest-apis/retrieve) for details on constructing filter objects.
+#### Further Reference
+
+- Understanding Filters: See [Filters Documentation](../rest-apis/retrieve) for details on constructing filter objects.
diff --git a/content/docs/developer-docs/metadata_schema/sms-templates.mdx b/content/docs/developer-docs/metadata_schema/sms-templates.mdx
index 8736864..8f521f0 100644
--- a/content/docs/developer-docs/metadata_schema/sms-templates.mdx
+++ b/content/docs/developer-docs/metadata_schema/sms-templates.mdx
@@ -3,19 +3,16 @@ title: SMS
icon: "smartphone"
description: Metadata schema for populating SMS templates in SolidX applications.
-summary: This document describes SMS template metadata in SolidX, which allows creation and management of SMS templates with dynamic content using Handlebars syntax. Templates are stored in separate text files referenced by the metadata and support variables for personalization. Key attributes include template name, display name, body file reference, description, SMS provider template ID, active status, and type (text). The document provides examples of OTP login templates with dynamic variable substitution, file organization guidelines, and links to implementing custom SMS providers for integration with external SMS services like Twilio or AWS SNS.
+summary: Covers the metadata used to define SMS templates in SolidX, including body-file references, provider template IDs, activation flags, and text-template behavior.
json_pointer: "/smsTemplates"
jsonpath: "$.smsTemplates"
parent_component: root
type: array
items_type: "object"
-items_attributes_doc: "#email-templates-metadata-attributes"
+items_attributes_doc: "#sms-templates-metadata-attributes"
solidx_concerns: [create/update_sms_template, new_sms_provider]
-
-
-
---
-# SMS Templates
+
**JSON Pointer:** `/smsTemplates`
@@ -24,18 +21,16 @@ solidx_concerns: [create/update_sms_template, new_sms_provider]
-
-
## Overview
-SMS Templates in SOLID allow you to create and manage SMS templates with dynamic content.
+SMS templates in SolidX let you define and manage text-message templates with dynamic content.
+
+The template body is stored in a separate text file referenced by the `body` field. The file contains the actual SMS message and can include Handlebars placeholders for dynamic values.
### Example: SMS Templates Metadata
-Below is an example of configuring an SMS template which sends an OTP when a user logs in.
+This example defines an OTP template used during login. The `body` field points to a separate text template file.
+
-
-
- SMS Templates Schema
-
+ SMS templates schema example
``` json
{
@@ -56,26 +51,22 @@ Below is an example of configuring an SMS template which sends an OTP when a use
```
-### Example : SMS Template File
-Below is an example of the content of the SMS template file `otp-on-login-custom.handlebars.txt` referenced in the above metadata. This file contains the actual SMS message with dynamic placeholders.
+### Example: SMS Template File
+Below is an example of the content of the `otp-on-login-custom.handlebars.txt` file referenced by the metadata above.
+
-
-
- SMS Template File
-
+ SMS template file example
```text
Hi {{ firstName }}, Login to {{ solidAppName }}, using {{ mobileVerificationTokenOnLogin }} as your verification code.
```
-### Example : Sending SMS Using Template (TODO ticket)
-Below is a code snippet demonstrating how to send an SMS using the defined SMS templates via the `SmsServiceFactory`. This example shows how to send an OTP verification SMS to a user.
+### Example: Sending SMS Using a Template
+This snippet shows how an application service sends an OTP verification message to a user using an authored SMS template via `SmsServiceFactory`.
+
-
-
- SMS Sending Code Snippet
-
+ SMS sending code example
``` ts
import { SmsServiceFactory } from 'your-sms-service';
@@ -96,11 +87,7 @@ async sendOtpSms(user: { mobile: string; firstName?: string; username: string, m
```
-
-
-
## SMS Templates Metadata Attributes
-
### `name` *(string, required, unique)*
Unique name for the sms template. It should be in kebab-case format (e.g., `example-template-name`).
@@ -111,15 +98,16 @@ Display name for the sms template.
### `body` *(string, required)*
- - In the metadata json, the filename of the sms template is specified. The templates are searched for in the `module-metadata//sms-templates/` directory of the module.
- - The body is then replaced with the content of the sms template file. This will include plain text content. The body can include dynamic placeholders using Handlebars syntax (e.g., `{{placeholderName}}`), as shown in the [SMS Template file](#example--sms-template-file) above.
-#### Further Reference
- - **SMS Body Creation:** [SMS Templates Guide](../../admin-docs/notifications/sms-templates.md)
+- In metadata JSON, `body` holds the template filename.
+- SolidX resolves that file from `module-metadata//sms-templates/`.
+- The file content is plain text and can include Handlebars placeholders such as `{{placeholderName}}`.
+#### Further Reference
+- **SMS Body Creation:** [SMS Templates Guide](../../admin-docs/notifications/sms-templates.md)
- Please refer to the [Handlebars Documentation](https://handlebarsjs.com/) for more information on using Handlebars syntax in email templates.
+Please refer to the [Handlebars Documentation](https://handlebarsjs.com/) for more information on using Handlebars syntax in SMS templates.
### `smsProviderTemplateId` *(string, optional)*
@@ -135,4 +123,4 @@ Indicates whether the SMS template is active. Defaults to `true`.
### `type` *(string, optional)*
-Type of the SMS template. Currently supports `text` only.
\ No newline at end of file
+Type of the SMS template. Currently supports `text` only.
diff --git a/content/docs/developer-docs/metadata_schema/users-metadata.mdx b/content/docs/developer-docs/metadata_schema/users-metadata.mdx
index f0b432b..3b02be1 100644
--- a/content/docs/developer-docs/metadata_schema/users-metadata.mdx
+++ b/content/docs/developer-docs/metadata_schema/users-metadata.mdx
@@ -2,7 +2,7 @@
title: Users
icon: "users"
description: Metadata schema for populating users in SolidX applications.
-summary: This document describes how to populate initial users in SolidX using metadata configuration. Users can be created with attributes including full name, username, email, mobile number, and optional role assignments. If no password is provided, the system auto-generates secure passwords and emails them to the specified addresses. Users are created with the default role specified in the IAM_DEFAULT_ROLE environment variable, or the Public role if not set. The metadata supports specifying multiple roles per user and includes examples of creating users with different configurations.
+summary: Covers the metadata used to create initial users in SolidX, including identity fields, role assignment, and default-password behavior.
json_pointer: "/users"
jsonpath: "$.users"
parent_component: root
@@ -21,12 +21,15 @@ solidx_concerns: []
## Overview
-We can populate some initial users in the system using the `users` metadata. These users will be created with the default role that is specified in the environment variable `IAM_DEFAULT_ROLE` or `Public` role if the environment variable is not set.
+Use the `users` metadata section to populate initial user accounts in the platform.
-### Example: Fee Portal Module Users Metadata
-Below is an example of how to initialize users using the metadata configuration. The below example creates two users, "John Doe" and "Jane Smith", with their respective details. Since no passwords are provided, the system will auto-generate secure passwords for these users and mail them to the specified email addresses.
+Each user record can define identity fields such as full name, username, email, mobile number, and optional role assignments. If no roles are specified for a user, SolidX assigns the role defined by `IAM_DEFAULT_ROLE`. If that environment variable is not set, the `Public` role is used.
- Users Schema
+### Example: Seeded Users
+The example below creates two users with their basic account details. Because no passwords are provided, SolidX generates secure passwords and sends them to the configured email addresses.
+
+
+Users schema example
``` json
{
@@ -48,6 +51,7 @@ Below is an example of how to initialize users using the metadata configuration.
]
}
```
+
## Users Metadata Attributes
@@ -69,4 +73,5 @@ Mobile number of the user.
List of roles to be assigned to the user. If not provided, the user will be assigned the default role specified in the environment variable `IAM_DEFAULT_ROLE` or `Public` role if the environment variable is not set. Also note, if roles are provided and the `IAM_DEFAULT_ROLE` is present, it will be added to the list of roles assigned to the user.
## Further Reference
+
- [Users Management](../../admin-docs/iam/users.md)
diff --git a/content/docs/developer-docs/metadata_schema/view-metadata.mdx b/content/docs/developer-docs/metadata_schema/view-metadata.mdx
index f1476a6..8790669 100644
--- a/content/docs/developer-docs/metadata_schema/view-metadata.mdx
+++ b/content/docs/developer-docs/metadata_schema/view-metadata.mdx
@@ -14,7 +14,6 @@ solidx_concerns: [update_layout, add_field_to_existing_layout, remove_field_from
import { LayoutGrid, Shield, Gauge } from 'lucide-react';
-# View Metadata
**JSON Pointer:** `/views`
@@ -27,16 +26,16 @@ import { LayoutGrid, Shield, Gauge } from 'lucide-react';
View metadata defines how SolidX presents models and fields to end users.
-If field metadata answers "what does this field mean?", view metadata answers "how should this field appear here?"
+If field metadata answers "what does this field mean?", view metadata answers "how should this field appear in this runtime surface?"
This page is the primary reference for:
-- top-level view records
-- layout attrs
-- field-node attrs inside layouts
-- widget selection through `editWidget` and `viewWidget`
-- widget-specific attrs
-- real metadata examples for `form`, `list`, and `tree` rendering
+- Top-level view records
+- Layout attrs
+- Field-node attrs inside layouts
+- Widget selection through `editWidget` and `viewWidget`
+- Widget-specific attrs
+- Real metadata examples for `form`, `list`, and `tree` rendering
For field semantics, validation intent, persistence behavior, and field-level attrs, see [Field Metadata](./field-metadata).
@@ -267,8 +266,8 @@ In list and tree views, `richText` reuses the standard text-column path.
It does not currently have dedicated list or tree widgets of its own. In these views, it behaves like a text column and relies on the same shared truncation and search mechanics as other text-style scalar fields.
-
-
+
+
| Concern | How it works |
| --- | --- |
@@ -294,13 +293,10 @@ It does not currently have dedicated list or tree widgets of its own. In these v