@solidxai/core 0.1.10-beta.9 → 0.1.10

package/src/helpers/field-crud-managers/field-quality-check-fixes.md

@@ -0,0 +1,208 @@
+# Field Quality Checks And Fixes
+
+This checklist tracks backend issues and logical enhancements for each field type in `solid-core-module`.
+
+Use it for backend concerns only:
+
+- CRUD validation
+- transformation and normalization
+- persistence behavior
+- relation semantics
+- field-level correctness and consistency
+
+Frontend widget and rendering concerns belong in `solid-core-ui`.
+
+## `shortText`
+
+- [ ] Resolve the `length` versus `max` contract for `shortText` and document one clear meaning for each attribute.
+- [ ] Decide whether backend validation should also enforce `min`, so `shortText` constraints remain consistent even outside generated form flows.
+- [ ] Return the configured regex mismatch message when `regexPatternNotMatchingErrorMsg` is present instead of always using a generic regex error.
+- [ ] Clarify and implement the expected behavior for `defaultValue` when a create payload omits a `shortText` field.
+- [ ] Decide whether `shortText` should support optional normalization such as trimming or whitespace collapsing, and keep that decision consistent across comparable text field types.
+- [ ] Review whether uniqueness should receive any pre-save validation support at the CRUD layer or continue to rely entirely on persistence-layer constraints.
+- [ ] Add targeted coverage for partial update behavior, empty string versus null handling, regex validation, and max-length enforcement.
+- [ ] Review whether the text-oriented managers share enough behavior to justify a common validation utility or base manager without weakening field-specific semantics.
+
+## `longText`
+
+- [ ] Decide whether backend validation should also enforce `min` and `max`, so `longText` constraints remain consistent outside generated form flows.
+- [ ] Return the configured regex mismatch message when `regexPatternNotMatchingErrorMsg` is present instead of always using a generic regex error.
+- [ ] Clarify and implement the expected behavior for `defaultValue` when a create payload omits a `longText` field.
+- [ ] Decide whether `longText` should support optional normalization such as trimming trailing whitespace while preserving intentional line breaks.
+- [ ] Review whether uniqueness should receive any pre-save validation support at the CRUD layer or continue to rely entirely on persistence-layer constraints.
+- [ ] Add targeted coverage for multiline content, regex validation, partial updates, and empty string versus null handling.
+- [ ] Review whether the text-oriented managers share enough behavior to justify a common validation utility or base manager without weakening field-specific semantics.
+
+## `richText`
+
+- [ ] Decide whether backend validation should also enforce `min` and `max`, so `richText` constraints remain consistent outside generated form flows.
+- [ ] Return the configured regex mismatch message when `regexPatternNotMatchingErrorMsg` is present instead of always using a generic regex error.
+- [ ] Clarify and implement the expected behavior for `defaultValue` when a create payload omits a `richText` field.
+- [ ] Decide whether `richText` should support optional normalization or sanitization at save time, and define that behavior explicitly.
+- [ ] Review whether uniqueness should receive any pre-save validation support at the CRUD layer or continue to rely entirely on persistence-layer constraints.
+- [ ] Add targeted coverage for rich HTML-like content, regex validation, partial updates, and empty string versus null handling.
+- [ ] Review whether the text-oriented managers share enough behavior to justify a common validation utility or base manager without weakening field-specific semantics.
+
+## `json`
+
+- [ ] Clarify and implement the expected behavior for `defaultValue` when a create payload omits a `json` field.
+- [ ] Decide whether backend validation should accept only stringified JSON or also handle already-parsed object and array payloads more explicitly.
+- [ ] Review whether the current JSON validation error should distinguish between invalid JSON syntax and unsupported runtime value shapes.
+- [ ] Decide whether normalization or canonical stringification should happen before persistence for comparable JSON values.
+- [ ] Review whether uniqueness should receive any pre-save validation support at the CRUD layer or continue to rely entirely on persistence-layer constraints.
+- [ ] Add targeted coverage for object payloads, array payloads, stringified JSON payloads, invalid JSON, partial updates, and empty string versus null handling.
+
+## `int`
+
+- [ ] Fix the current min/max activation rule, because backend validation only applies numeric bounds when the configured value is greater than `0`, which skips valid `0` and negative thresholds.
+- [ ] Clarify and implement the expected behavior for `defaultValue` when a create payload omits an `int` field.
+- [ ] Decide whether the CRUD layer should normalize numeric strings into integers more explicitly before validation and persistence.
+- [ ] Review whether integer fields should reject decimal-shaped inputs more clearly when values arrive from metadata-driven clients as strings.
+- [ ] Review whether uniqueness should receive any pre-save validation support at the CRUD layer or continue to rely entirely on persistence-layer constraints.
+- [ ] Add targeted coverage for `0`, negative values, numeric strings, invalid decimal-like input, min/max bounds, and partial update behavior.
+
+
+## `bigint`
+
+- [ ] Clarify the authored support surface for `bigint`, because the CRUD manager contains numeric bound logic while the authored field surface does not currently present `min` and `max` in the same way as `int` and `decimal`.
+- [ ] Fix or clarify the current numeric-bound activation rule if bigint bounds are intended to be supported, since the logic only applies bounds when the configured value is greater than `0`.
+- [ ] Clarify and implement the expected behavior for `defaultValue` when a create payload omits a `bigint` field.
+- [ ] Decide what the canonical runtime contract should be for bigint inputs: native `bigint`, numeric strings, or finite JavaScript numbers.
+- [ ] Review whether accepting finite JavaScript numbers for bigint validation is sufficient when exact large-integer fidelity matters.
+- [ ] Review whether uniqueness should receive any pre-save validation support at the CRUD layer or continue to rely entirely on persistence-layer constraints.
+- [ ] Add targeted coverage for numeric strings, very large values, invalid numeric input, bound handling, null handling, and partial update behavior.
+
+
+## `decimal`
+
+- [ ] Fix the current min/max activation rule, because backend validation only applies numeric bounds when the configured value is greater than `0`, which skips valid `0` and negative thresholds.
+- [ ] Clarify and implement the expected behavior for `defaultValue` when a create payload omits a `decimal` field.
+- [ ] Decide whether the CRUD layer should normalize numeric strings into decimal numbers more explicitly before validation and persistence.
+- [ ] Review whether decimal fields need an explicit precision-and-scale contract instead of relying entirely on the persistence-layer `ormType`.
+- [ ] Review whether uniqueness should receive any pre-save validation support at the CRUD layer or continue to rely entirely on persistence-layer constraints.
+- [ ] Add targeted coverage for `0`, negative values, fractional values, numeric strings, invalid numeric input, min/max bounds, and partial update behavior.
+
+
+## `boolean`
+
+- [ ] Clarify and implement the expected behavior for `defaultValue` when a create payload omits a `boolean` field.
+- [ ] Decide whether boolean CRUD validation should accept only runtime booleans or also normalize `"true"` and `"false"` string payloads when they arrive from metadata-driven clients.
+- [ ] Review whether the required validation path should distinguish more clearly between an omitted value and an explicit `false` value, especially for partial updates.
+- [ ] Review whether uniqueness should receive any pre-save validation support at the CRUD layer or continue to rely entirely on persistence-layer constraints.
+- [ ] Add targeted coverage for `true`, `false`, null, empty string, string booleans, and partial update behavior.
+
+## `date`
+
+- [ ] Clarify and implement the expected behavior for `defaultValue` when a create payload omits a `date` field.
+- [ ] Review whether the CRUD layer should accept only runtime `Date` objects or also normalize common serialized date inputs more explicitly before validation.
+- [ ] Decide whether `date` and `datetime` should continue to share the same backend validation path or receive more distinct normalization and validation behavior.
+- [ ] Review whether uniqueness should receive any pre-save validation support at the CRUD layer or continue to rely entirely on persistence-layer constraints.
+- [ ] Add targeted coverage for `Date` objects, serialized date strings, null handling, invalid date inputs, and partial update behavior.
+
+## `datetime`
+
+- [ ] Clarify and implement the expected behavior for `defaultValue` when a create payload omits a `datetime` field.
+- [ ] Review whether the CRUD layer should accept only runtime `Date` objects or also normalize common serialized datetime inputs more explicitly before validation.
+- [ ] Decide whether `date` and `datetime` should continue to share the same backend validation path or receive more distinct normalization and validation behavior.
+- [ ] Review whether timezone normalization rules should be documented and enforced more explicitly at save time.
+- [ ] Review whether uniqueness should receive any pre-save validation support at the CRUD layer or continue to rely entirely on persistence-layer constraints.
+- [ ] Add targeted coverage for `Date` objects, serialized datetime strings, null handling, timezone-sensitive values, invalid datetime inputs, and partial update behavior.
+
+## `time`
+
+- [ ] Add an explicit CRUD-manager path for `SolidFieldType.time`, since the field currently has core UI support but is not routed through a dedicated backend field manager.
+- [ ] Clarify and implement the expected behavior for `defaultValue` when a create payload omits a `time` field.
+- [ ] Decide what canonical persisted shape `time` should use: pure time string, database-native time value, or a normalized timestamp-derived representation.
+- [ ] Review whether the CRUD layer should normalize common time inputs such as `HH:mm:ss`, ISO timestamps, and UI-submitted values more explicitly before validation and persistence.
+- [ ] Review whether uniqueness should receive any pre-save validation support at the CRUD layer or continue to rely entirely on persistence-layer constraints.
+- [ ] Add targeted coverage for `HH:mm:ss` inputs, ISO-style inputs, invalid time values, null handling, and partial update behavior.
+
+## `email`
+
+- [ ] Decide whether backend validation should also enforce `min`, so email constraints remain consistent outside generated form flows.
+- [ ] Return the configured regex mismatch message when `regexPatternNotMatchingErrorMsg` is present instead of always using a generic regex error.
+- [ ] Clarify and implement the expected behavior for `defaultValue` when a create payload omits an `email` field.
+- [ ] Decide whether email values should support optional normalization such as trimming and lowercasing before persistence.
+- [ ] Review whether uniqueness should receive any pre-save validation support at the CRUD layer or continue to rely entirely on persistence-layer constraints.
+- [ ] Add targeted coverage for max-length enforcement, regex overrides, invalid email formats, null handling, and partial update behavior.
+
+## `password`
+
+- [ ] Return the configured regex mismatch message when `regexPatternNotMatchingErrorMsg` is present instead of always using a generic password-regex error.
+- [ ] Review whether password validation should produce clearer error messages for min, max, regex, and confirm-password mismatch failures.
+- [ ] Clarify and implement the expected behavior for `defaultValue` on password fields, including whether it should be ignored entirely for secure create flows.
+- [ ] Review whether password hashing and password-update flows should share a more explicit single contract across create and update operations.
+- [ ] Decide whether password normalization should include trimming or whether exact raw user input should always be preserved before hashing.
+- [ ] Add targeted coverage for create-required behavior, update-optional behavior, confirm-password mismatch, hashing behavior, regex fallback behavior, and partial update behavior.
+
+## `selectionStatic`
+
+- [ ] Clarify and implement the expected behavior for `defaultValue` when a create payload omits a `selectionStatic` field, especially for multi-select fields.
+- [ ] Decide whether the CRUD layer should normalize single-select and multi-select payloads into one consistent stored shape before persistence.
+- [ ] Review whether the current `selectionStaticValues` parsing should validate malformed `value:label` entries more explicitly instead of assuming a valid authored format.
+- [ ] Add clearer error messaging when the submitted value has the wrong type versus when it is simply not part of the authored option set.
+- [ ] Review whether numeric selection values need more explicit normalization, especially when values can arrive as strings from metadata-driven clients.
+- [ ] Add targeted coverage for single-select string values, single-select numeric values, JSON-stringified multi-select arrays, invalid option tokens, malformed arrays, and partial update behavior.
+
+## `selectionDynamic`
+
+- [ ] Clarify and implement the expected behavior for `defaultValue` when a create payload omits a `selectionDynamic` field, especially for multi-select fields.
+- [ ] Review whether the CRUD layer should normalize single-select and multi-select payloads into one consistent stored shape before persistence.
+- [ ] Add clearer error messaging when the submitted value has the wrong type, when the provider rejects the value, and when the provider itself cannot be resolved.
+- [ ] Review whether numeric selection values need more explicit normalization, especially when values can arrive as strings from metadata-driven clients.
+- [ ] Clarify how `validateOnSave` in `selectionDynamicProviderCtxt` should be treated as part of the supported field contract and whether more provider-context keys should be validated.
+- [ ] Add targeted coverage for provider-backed single-select values, JSON-stringified multi-select arrays, invalid provider names, `validateOnSave: false`, invalid option values, and partial update behavior.
+
+## `many-to-one`
+
+- [ ] Clarify and document the preferred request contract for single relations, because accepting both `<fieldName>Id` and `<fieldName>UserKey` is useful but easy to apply inconsistently across clients.
+- [ ] Review whether the CRUD layer should normalize empty strings for `<fieldName>Id` and `<fieldName>UserKey` more explicitly before required validation runs.
+- [ ] Decide whether user-key-based lookup failures should return a more specific error message than generic required or invalid relation errors.
+- [ ] Review whether relation resolution should support optional fixed-filter enforcement at save time in addition to UI-level filtering.
+- [ ] Consider whether uniqueness on a `many-to-one` field should receive clearer pre-save validation when the authored intent effectively makes the relation one-to-one.
+- [ ] Add targeted coverage for id-based lookup, user-key-based lookup, missing required relations, invalid id shapes, invalid user keys, and partial update behavior.
+
+## `one-to-many`
+
+- [ ] Clarify and document the command contract for collection relations so `set`, `clear`, `link`, `unlink`, `create`, `update`, and `delete` are easier to use consistently from clients.
+- [ ] Review whether malformed or unsupported command values should return more specific validation errors than the current generic failure path.
+- [ ] Decide whether create-time and update-time collection mutation semantics should be normalized more explicitly, especially where some commands are intentionally update-only.
+- [ ] Review whether `relationCoModelFieldName` should be validated more aggressively, because this field is central to child binding and inverse resolution.
+- [ ] Consider whether `relationFieldFixedFilter` should be enforced during relation mutation so child records cannot be linked outside the authored collection scope.
+- [ ] Add targeted coverage for `set`, `clear`, `link`, `unlink`, `create`, `update`, `delete`, invalid command payloads, and partial update behavior.
+
+## `many-to-many`
+
+- [ ] Clarify and document owner-side versus inverse-side mutation semantics so clients understand which effective field names and id lists are honored during CRUD operations.
+- [ ] Review whether malformed owner-side metadata such as missing `isRelationManyToManyOwner` or mismatched inverse names should fail earlier and more clearly.
+- [ ] Decide whether `relationJoinTableName` and related ownership attrs need stronger validation at metadata authoring time to avoid ambiguous join behavior later.
+- [ ] Review whether `relationFieldFixedFilter` should be enforced during membership mutation so unsupported links cannot be created through direct payloads.
+- [ ] Consider whether create, update, and delete operations against related entities should be more clearly separated from plain membership operations such as `set`, `link`, and `unlink`.
+- [ ] Add targeted coverage for owner-side mutations, inverse-side mutations, `set`, `clear`, `link`, `unlink`, related-entity create/update/delete flows, and partial update behavior.
+
+## `mediaSingle`
+
+- [ ] Clarify and implement the expected behavior for `defaultValue` when a create payload omits a `mediaSingle` field, including whether the field should ever accept persisted references without a new upload.
+- [ ] Review whether media validation should normalize authored `mediaTypes` values more explicitly so unsupported tokens fail early and predictably.
+- [ ] Consider whether storage-provider resolution should fail with a clearer field-specific error when `mediaStorageProviderUserKey` is missing or invalid.
+- [ ] Review whether replace and delete semantics should be more explicit in the CRUD layer when an existing asset is being updated or removed.
+- [ ] Consider whether upload validation should be refactored into shared utilities so size, type, and required checks stay consistent across media field types.
+- [ ] Add targeted coverage for required create-time uploads, oversized files, unsupported media types, missing providers, replacement flows, and partial update behavior.
+
+## `mediaMultiple`
+
+- [ ] Align collection-level validation with the single-media path so `mediaTypes` and `mediaMaxSizeKb` are enforced consistently for every uploaded file.
+- [ ] Clarify and implement the expected behavior for `defaultValue` when a create payload omits a `mediaMultiple` field, including whether persisted media references should ever be accepted directly.
+- [ ] Review whether storage-provider resolution should fail with a clearer field-specific error when `mediaStorageProviderUserKey` is missing or invalid.
+- [ ] Decide what the canonical update semantics should be for attachment collections: append-only, replace-all, explicit remove, or a more command-style contract.
+- [ ] Consider whether media collection validation should report per-file errors more explicitly when one file fails and others succeed.
+- [ ] Add targeted coverage for required create-time collections, mixed valid and invalid uploads, oversized files, unsupported media types, missing providers, and partial update behavior.
+
+## `computed`
+
+- [ ] Clarify and document the supported provider contract more explicitly, including what a computed-field provider must return and how failures should be surfaced to callers.
+- [ ] Review whether `computedFieldValueProviderCtxt` should be validated as JSON earlier and with clearer error messaging before provider execution begins.
+- [ ] Decide whether inline computation should remain skipped on partial updates by default, or whether some computed fields need an opt-in recompute path during patch-style operations.
+- [ ] Review whether `computedFieldTriggerConfig` should be validated more aggressively so unsupported operations or malformed trigger definitions fail earlier.
+- [ ] Consider whether the CRUD layer should verify that the provider’s returned value matches `computedFieldValueType` before persistence.
+- [ ] Add targeted coverage for inline provider execution, malformed provider context, missing providers, trigger-configured fields, partial updates, and mismatched computed value types.

package/src/helpers/microsoft-active-directory-oauth.helper.ts

@@ -0,0 +1,83 @@
+export type MicrosoftActiveDirectoryAuthConfiguration = {
+  clientID: string;
+  clientSecret: string;
+  tenant: string;
+  callbackURL: string;
+  redirectURL: string;
+};
+
+export const DEFAULT_MICROSOFT_ACTIVE_DIRECTORY_OAUTH_TENANT = "common";
+export const MICROSOFT_ACTIVE_DIRECTORY_OAUTH_SCOPES = [
+  "openid",
+  "profile",
+  "email",
+  "User.Read",
+];
+
+type MicrosoftActiveDirectoryOauthProfileValue = {
+  value?: string;
+};
+
+export type MicrosoftActiveDirectoryOauthProfile = {
+  id?: string;
+  displayName?: string;
+  emails?: MicrosoftActiveDirectoryOauthProfileValue[];
+  photos?: MicrosoftActiveDirectoryOauthProfileValue[];
+  _json?: {
+    id?: string;
+    displayName?: string;
+    mail?: string;
+    userPrincipalName?: string;
+    email?: string;
+    preferred_username?: string;
+    picture?: string;
+  };
+};
+
+export const isMicrosoftActiveDirectoryOAuthConfigured = (
+  config: MicrosoftActiveDirectoryAuthConfiguration,
+): boolean => {
+  return !!(
+    config.clientID &&
+    config.clientSecret &&
+    config.tenant &&
+    config.callbackURL &&
+    config.redirectURL
+  );
+};
+
+export const getMicrosoftActiveDirectoryOAuthProfileId = (
+  profile: MicrosoftActiveDirectoryOauthProfile,
+): string | null => {
+  return profile.id || profile._json?.id || null;
+};
+
+export const getMicrosoftActiveDirectoryOAuthEmail = (
+  profile: MicrosoftActiveDirectoryOauthProfile,
+): string | null => {
+  const email =
+    profile.emails?.find((item) => !!item.value)?.value ||
+    profile._json?.mail ||
+    profile._json?.userPrincipalName ||
+    profile._json?.email ||
+    profile._json?.preferred_username ||
+    null;
+
+  return email?.trim().toLowerCase() || null;
+};
+
+export const getMicrosoftActiveDirectoryOAuthDisplayName = (
+  profile: MicrosoftActiveDirectoryOauthProfile,
+): string | null => {
+  return profile.displayName || profile._json?.displayName || null;
+};
+
+export const getMicrosoftActiveDirectoryOAuthPicture = (
+  profile: MicrosoftActiveDirectoryOauthProfile,
+): string | null => {
+  return (
+    profile.photos?.find((item) => !!item.value)?.value ||
+    profile._json?.picture ||
+    null
+  );
+};

package/src/helpers/model-metadata-helper.service.ts

@@ -3,6 +3,7 @@
 import { forwardRef, Inject, Injectable, Logger } from "@nestjs/common";
 import { _ } from "lodash";
 import { LEGACY_TABLE_FIELDS_PREFIX } from "src/entities/legacy-common.entity";
+import { LegacyTableType } from "src/enums/legacy-table-type.enum";
 import { ModelMetadataRepository } from "src/repository/model-metadata.repository";
 import { SolidRegistry } from "./solid-registry";
 
@@ -19,12 +20,12 @@ export class ModelMetadataHelperService {
     ) {
     }
 
-    getSystemFieldsMetadata(isLegacyTable: boolean=false, isLegacyTableWithId: boolean=false): any[] {
+    getSystemFieldsMetadata(legacyTableType: LegacyTableType = LegacyTableType.NONE): any[] {
         let systemFieldsMetadata: any[];
-        if (isLegacyTableWithId) {
+        if (legacyTableType === LegacyTableType.GENERATED_ID) {
             systemFieldsMetadata = this.getSystemFieldsMetadataMappingForLegacyTable(true);
         }
-        else if (isLegacyTable) {
+        else if (legacyTableType === LegacyTableType.EXISTING_ID) {
             systemFieldsMetadata = this.getSystemFieldsMetadataMappingForLegacyTable(false);
         }
         else {

package/src/helpers/module-metadata-helper.service.ts

@@ -37,41 +37,54 @@ export class ModuleMetadataHelperService {
         return path.resolve(process.cwd(), 'src', moduleName);
     }
 
+    async getSolidUiModulePath(moduleName: string): Promise<string> {
+        if (!moduleName) {
+            return '';
+        }
+
+        const dashModuleName = kebabCase(moduleName);
+        return path.resolve(process.cwd(), '..', 'solid-ui', 'src', dashModuleName);
+    }
+
+    private resolveModuleMetadataFolderPath(moduleName: string): string {
+        const dashModuleName = kebabCase(moduleName);
+        return path.resolve(process.cwd(), 'src', dashModuleName, 'metadata');
+    }
+
     async getModuleMetadataFilePath(moduleName: string): Promise<string> {
         if (!moduleName) {
             return '';
         }
         const dashModuleName = kebabCase(moduleName);
-        const folderPath = path.resolve(process.cwd(), 'module-metadata', dashModuleName);
-        const filePath = path.join(folderPath, `${dashModuleName}-metadata.json`);
-        // Check if filePath exists
-        const fileExists = await this.fileService.exists(filePath);
-        // this.logger.debug(`File exists: ${fileExists} at ${filePath}`);
-        if (!fileExists) {
-            // If the module is solid-core, try the fallback path, in case the current root directory is the solid core project
-            if (dashModuleName === SOLID_CORE_MODULE_NAME) {
-                const fallbackPath = path.resolve(process.cwd(), 'src', 'seeders', 'seed-data', `${dashModuleName}-metadata.json`);
+        const filePath = path.join(
+            this.resolveModuleMetadataFolderPath(dashModuleName),
+            `${dashModuleName}-metadata.json`,
+        );
+
+        if (dashModuleName === SOLID_CORE_MODULE_NAME) {
+            const fallbackPath = path.resolve(process.cwd(), 'src', 'seeders', 'seed-data', `${dashModuleName}-metadata.json`);
+            const fallbackExists = await this.fileService.exists(fallbackPath);
+            if (fallbackExists) {
                 this.logger.debug(`Fallback path: ${fallbackPath}`);
                 return fallbackPath;
             }
+
+            const consumingProjectFallbackPath = path.resolve(process.cwd(), 'node_modules', '@solidxai', 'core', 'src', 'seeders', 'seed-data', `${dashModuleName}-metadata.json`);
+            const consumingProjectFallbackExists = await this.fileService.exists(consumingProjectFallbackPath);
+            if (consumingProjectFallbackExists) {
+                this.logger.debug(`Fallback path: ${consumingProjectFallbackPath}`);
+                return consumingProjectFallbackPath;
+            }
         }
+
         return filePath;
     }
+
     async getModuleMetadataFolderPath(moduleName: string): Promise<string> {
         if (!moduleName) {
             return '';
         }
-
-        const dashModuleName = kebabCase(moduleName);
-
-        const folderPath = path.resolve(
-            process.cwd(),
-            'module-metadata',
-            dashModuleName,
-        );
-
-        const exists = await this.fileService.exists(folderPath);
-        return exists ? folderPath : '';
+        return this.resolveModuleMetadataFolderPath(moduleName);
     }
 
 }

package/src/helpers/module.helper.ts

@@ -38,26 +38,29 @@ export const getDynamicModuleNames = (): string[] => {
 export const getDynamicModuleNamesBasedOnMetadata = (): string[] => {
   const dynamicModulesToExclude = process.env.SOLID_DYNAMIC_MODULES_TO_EXCLUDE?.split(',') || [];
 
-  // Find a path that is ../${srcPath}/module-metadata save it in a variable.
-  // const srcPath = path.join(process.cwd(), 'src');
-  const moduleMetadataPath = path.join(process.cwd(), 'module-metadata');
+  const srcPath = path.join(process.cwd(), 'src');
   const coreModuleNames = getCoreModuleNames();
   const allExcludedModules = [...new Set([...coreModuleNames, ...dynamicModulesToExclude])];
 
-  // if module-metadata path does not exist, return empty array
-  if (!fs.existsSync(moduleMetadataPath)) {
-    logger.warn(`Module metadata path does not exist: ${moduleMetadataPath}`);
+  if (!fs.existsSync(srcPath)) {
+    logger.warn(`Source path does not exist: ${srcPath}`);
     return [];
   }
 
-  const moduleMetadataDirectories = fs.readdirSync(moduleMetadataPath, { withFileTypes: true });
-  const enabledModules = moduleMetadataDirectories
+  const moduleDirectories = fs.readdirSync(srcPath, { withFileTypes: true });
+  const enabledModules = moduleDirectories
     .filter(dirent => {
       const isValidDirectory = dirent.isDirectory() && !allExcludedModules.includes(dirent.name);
 
       if (!isValidDirectory) return false;
 
-      const fullPath = path.join(moduleMetadataPath, dirent.name, `${dirent.name}-metadata.json`);
+      // const moduleManifestPath = path.join(srcPath, dirent.name, `${dirent.name}.module.ts`);
+      // const moduleManifestStats = fs.statSync(moduleManifestPath, { throwIfNoEntry: false });
+      // if (!moduleManifestStats || !moduleManifestStats.isFile()) {
+      //   return false;
+      // } // Commenting this out, since we want to rely solely on the presence of metadata files and be able to load this as a dynamic module
+
+      const fullPath = path.join(srcPath, dirent.name, 'metadata', `${dirent.name}-metadata.json`);
 
       const stats = fs.statSync(fullPath, { throwIfNoEntry: false });
       return !!stats && stats.isFile();

package/src/helpers/solid-registry.ts

@@ -7,7 +7,7 @@ import { CommonEntity } from 'src/entities/common.entity';
 import { Locale } from 'src/entities/locale.entity';
 import { SecurityRule } from 'src/entities/security-rule.entity';
 import { IScheduledJob } from 'src/services/scheduled-jobs/scheduled-job.interface';
-import { IDashboardQuestionDataProvider, IDashboardVariableSelectionProvider, IErrorCodeProvider, ISecurityRuleConfigProvider, ISelectionProvider, ISelectionProviderContext, ISolidDatabaseModule } from "../interfaces";
+import { IDashboardWidgetDataProvider, IErrorCodeProvider, ISecurityRuleConfigProvider, ISelectionProvider, ISelectionProviderContext, ISolidDatabaseModule } from "../interfaces";
 import { ObjectLiteral } from 'typeorm';
 
 type ControllerMetadata = {
@@ -71,6 +71,7 @@ export class SolidRegistry {
   private seeders: Set<InstanceWrapper> = new Set();
   private scheduledJobProviders: Set<InstanceWrapper> = new Set();
   private selectionProviders: Set<InstanceWrapper> = new Set();
+  private dashboardWidgetDataProviders: Set<InstanceWrapper> = new Set();
   private computedFieldProviders: Set<InstanceWrapper> = new Set();
   private solidDatabaseModules: Set<InstanceWrapper> = new Set();
   private controllers: Set<ControllerMetadata> = new Set();
@@ -78,8 +79,6 @@ export class SolidRegistry {
   private securityRules: SecurityRule[] = [];
   private locales: Locale[] = [];
   private computedFieldMetadata: ComputedFieldMetadata[] = [];
-  private dashboardVariableSelectionProviders: Set<InstanceWrapper> = new Set();
-  private dashboardQuestionDataProviders: Set<InstanceWrapper> = new Set();
   private mailProviders: Set<InstanceWrapper> = new Set();
   private whatsappProviders: Set<InstanceWrapper> = new Set();
   private smsProviders: Set<InstanceWrapper> = new Set();
@@ -138,12 +137,8 @@ export class SolidRegistry {
     this.selectionProviders.add(selectionProvider);
   }
 
-  registerDashboardVariableSelectionProvider(dashboardSelectionProvider: InstanceWrapper): void {
-    this.dashboardVariableSelectionProviders.add(dashboardSelectionProvider);
-  }
-
-  registerDashboardQuestionDataProvider(dashboardQuestionDataProvider: InstanceWrapper): void {
-    this.dashboardQuestionDataProviders.add(dashboardQuestionDataProvider);
+  registerDashboardWidgetDataProvider(provider: InstanceWrapper): void {
+    this.dashboardWidgetDataProviders.add(provider);
   }
 
   registerComputedFieldProvider(computedFieldProvider: InstanceWrapper): void {
@@ -232,6 +227,10 @@ export class SolidRegistry {
     return Array.from(this.selectionProviders);
   }
 
+  getDashboardWidgetDataProviders(): Array<InstanceWrapper> {
+    return Array.from(this.dashboardWidgetDataProviders);
+  }
+
   getSelectionProviderInstance<T extends ISelectionProviderContext>(name: string): ISelectionProvider<T> {
     const selectionProviders = this.getSelectionProviders();
 
@@ -243,19 +242,15 @@ export class SolidRegistry {
     }
   }
 
-  getDashboardVariableSelectionProviders(): Array<InstanceWrapper> {
-    return Array.from(this.dashboardVariableSelectionProviders);
-  }
-
-  getDashboardVariableSelectionProviderInstance<T extends ISelectionProviderContext>(name: string): IDashboardVariableSelectionProvider<T> {
-    const dashboardSelectionProviders = this.getDashboardVariableSelectionProviders();
-
-    for (let i = 0; i < dashboardSelectionProviders.length; i++) {
-      const dashboardSelectionProvider = dashboardSelectionProviders[i];
-      if (dashboardSelectionProvider.instance.name() === name) {
-        return dashboardSelectionProvider.instance;
+  getDashboardWidgetDataProviderInstance(name: string): IDashboardWidgetDataProvider | undefined {
+    const providers = this.getDashboardWidgetDataProviders();
+    for (let i = 0; i < providers.length; i++) {
+      const provider = providers[i];
+      if (provider?.instance?.name?.() === name || provider?.name === name) {
+        return provider.instance as IDashboardWidgetDataProvider;
       }
     }
+    return undefined;
   }
 
   getErrorCodeProviders(): Array<InstanceWrapper> {
@@ -271,21 +266,6 @@ export class SolidRegistry {
     return undefined;
   }
 
-  getDashboardQuestionDataProviders(): Array<InstanceWrapper> {
-    return Array.from(this.dashboardQuestionDataProviders)
-  }
-
-  getDashboardQuestionDataProviderInstance<TContext, TData>(name: string): IDashboardQuestionDataProvider<TContext, TData> {
-    const dashboardQuestionDataProviders = this.getDashboardQuestionDataProviders();
-
-    for (let i = 0; i < dashboardQuestionDataProviders.length; i++) {
-      const dasbhoardQuestionDataProvider = dashboardQuestionDataProviders[i];
-      if (dasbhoardQuestionDataProvider.instance.name() === name) {
-        return dasbhoardQuestionDataProvider.instance;
-      }
-    }
-  }
-
   getComputedFieldProviders(): Array<InstanceWrapper> {
     return Array.from(this.computedFieldProviders);
   }
@@ -380,4 +360,3 @@ export class SolidRegistry {
     }
   }
 }
-