@solidxai/core 0.1.11-beta.6 → 0.1.11-beta.8

package/docs/dashboards/delete-legacy-dashboard-metadata.sql

@@ -1,172 +0,0 @@
-BEGIN;
-
--- 0) Scope: solid-core dashboard legacy keys
--- Models:
---   dashboard, dashboardVariable, dashboardQuestion, dashboardQuestionSqlDatasetConfig, dashboardLayout
--- Actions:
---   dashboard-list-action, dashboardVariable-list-action, dashboardQuestion-list-action,
---   dashboardLayout-list-action, dashboardQuestionSqlDatasetConfig-list-action
--- Menus:
---   dashboardManagement-menu-item, dashboard-menu-item, dashboardQuestion-menu-item, dashboardLayout-menu-item
--- Views:
---   dashboard-list-view, dashboard-form-view,
---   dashboardVariable-list-view, dashboardVariable-form-view,
---   dashboardQuestion-list-view, dashboardQuestion-form-view,
---   dashboardQuestionSqlDatasetConfig-list-view, dashboardQuestionSqlDatasetConfig-form-view,
---   dashboardLayout-list-view, dashboardLayout-form-view
-
--- 1) Remove role<->permission joins for dashboard controller permissions
--- (table name may vary by naming strategy; this is the common one)
-DELETE FROM ss_role_metadata_permissions_ss_permission_metadata
-WHERE ss_permission_metadata_id IN (
-  SELECT id
-  FROM ss_permission_metadata
-  WHERE name IN (
-    'DashboardController.getDefinition',
-    'DashboardController.getWidgetData',
-    'DashboardController.getDashboardData',
-    'DashboardController.getVariableOptions',
-    'DashboardController.getLayout',
-    'DashboardController.saveLayout'
-  )
-);
-
--- 2) Remove dashboard permissions
-DELETE FROM ss_permission_metadata
-WHERE name IN (
-  'DashboardController.getDefinition',
-  'DashboardController.getWidgetData',
-  'DashboardController.getDashboardData',
-  'DashboardController.getVariableOptions',
-  'DashboardController.getLayout',
-  'DashboardController.saveLayout'
-);
-
--- 3) Remove menu<->role joins for dashboard menus
-DELETE FROM ss_menu_item_metadata_roles_ss_role_metadata
-WHERE ss_menu_item_metadata_id IN (
-  SELECT m.id
-  FROM ss_menu_item_metadata m
-  WHERE m.name IN (
-    'dashboardManagement-menu-item',
-    'dashboard-menu-item',
-    'dashboardQuestion-menu-item',
-    'dashboardLayout-menu-item'
-  )
-);
-
--- 4) Remove dashboard menus
-DELETE FROM ss_menu_item_metadata
-WHERE name IN (
-  'dashboardManagement-menu-item',
-  'dashboard-menu-item',
-  'dashboardQuestion-menu-item',
-  'dashboardLayout-menu-item'
-);
-
--- 5) Remove dashboard actions
-DELETE FROM ss_action_metadata
-WHERE name IN (
-  'dashboard-list-action',
-  'dashboardVariable-list-action',
-  'dashboardQuestion-list-action',
-  'dashboardLayout-list-action',
-  'dashboardQuestionSqlDatasetConfig-list-action'
-);
-
--- 6) Remove user-specific view overrides for dashboard views
-DELETE FROM ss_user_view_metadata
-WHERE view_metadata_id IN (
-  SELECT v.id
-  FROM ss_view_metadata v
-  WHERE v.name IN (
-    'dashboard-list-view',
-    'dashboard-form-view',
-    'dashboardVariable-list-view',
-    'dashboardVariable-form-view',
-    'dashboardQuestion-list-view',
-    'dashboardQuestion-form-view',
-    'dashboardQuestionSqlDatasetConfig-list-view',
-    'dashboardQuestionSqlDatasetConfig-form-view',
-    'dashboardLayout-list-view',
-    'dashboardLayout-form-view'
-  )
-);
-
--- 7) Remove saved filters tied to dashboard models/views
-DELETE FROM ss_saved_fitlers
-WHERE model_id IN (
-  SELECT m.id
-  FROM ss_model_metadata m
-  JOIN ss_module_metadata mm ON mm.id = m.module_id
-  WHERE mm.name = 'solid-core'
-    AND m.singular_name IN (
-      'dashboard',
-      'dashboardVariable',
-      'dashboardQuestion',
-      'dashboardQuestionSqlDatasetConfig',
-      'dashboardLayout'
-    )
-)
-OR view_id IN (
-  SELECT v.id
-  FROM ss_view_metadata v
-  WHERE v.name IN (
-    'dashboard-list-view',
-    'dashboard-form-view',
-    'dashboardVariable-list-view',
-    'dashboardVariable-form-view',
-    'dashboardQuestion-list-view',
-    'dashboardQuestion-form-view',
-    'dashboardQuestionSqlDatasetConfig-list-view',
-    'dashboardQuestionSqlDatasetConfig-form-view',
-    'dashboardLayout-list-view',
-    'dashboardLayout-form-view'
-  )
-);
-
--- 8) Remove security rules attached to dashboard models (if any)
-DELETE FROM ss_security_rule
-WHERE model_metadata_id IN (
-  SELECT m.id
-  FROM ss_model_metadata m
-  JOIN ss_module_metadata mm ON mm.id = m.module_id
-  WHERE mm.name = 'solid-core'
-    AND m.singular_name IN (
-      'dashboard',
-      'dashboardVariable',
-      'dashboardQuestion',
-      'dashboardQuestionSqlDatasetConfig',
-      'dashboardLayout'
-    )
-);
-
--- 9) Remove dashboard views
-DELETE FROM ss_view_metadata
-WHERE name IN (
-  'dashboard-list-view',
-  'dashboard-form-view',
-  'dashboardVariable-list-view',
-  'dashboardVariable-form-view',
-  'dashboardQuestion-list-view',
-  'dashboardQuestion-form-view',
-  'dashboardQuestionSqlDatasetConfig-list-view',
-  'dashboardQuestionSqlDatasetConfig-form-view',
-  'dashboardLayout-list-view',
-  'dashboardLayout-form-view'
-);
-
--- 10) Remove dashboard models (fields should cascade via model_id FK)
-DELETE FROM ss_model_metadata
-WHERE singular_name IN (
-  'dashboard',
-  'dashboardVariable',
-  'dashboardQuestion',
-  'dashboardQuestionSqlDatasetConfig',
-  'dashboardLayout'
-)
-AND module_id IN (
-  SELECT id FROM ss_module_metadata WHERE name = 'solid-core'
-);
-
-COMMIT;

package/docs/datasource-introspection-ddl-analysis.md

@@ -1,326 +0,0 @@
-# Datasource Introspection DDL Analysis
-
-## Scope
-- Compared the current `mswipe-erp-solidx` DDL exports under [mswipe-erp-solidx/sql-ddl-statements](/Users/harishpatel/Code/javascript/mswipe-erp-solidx/sql-ddl-statements) against:
-  - generated TypeORM entities in [mswipe-erp-solidx/solid-api/src](/Users/harishpatel/Code/javascript/mswipe-erp-solidx/solid-api/src)
-  - model metadata JSON files in the same modules
-- Focused on the six SolidX modules currently represented in metadata:
-  - `cpm`
-  - `frms`
-  - `mswipe-masters`
-  - `onboarding`
-  - `peoples`
-  - `reports`
-
-## DDL Coverage
-- DDL files available:
-  - `mSwipe_SolidXCore.sql`
-  - `mSwipe_Applications_script.sql`
-  - `mSwipe_Live_Dev_script.sql`
-  - `mSwipe_Masters_script.sql`
-  - `mSwipe_ERP_Live_Dev_script.sql`
-- Datasource-to-DDL mapping used for this analysis:
-  - `default` -> `mSwipe_SolidXCore.sql`
-  - `applications` -> `mSwipe_Applications_script.sql`
-  - `amextxn` -> `mSwipe_Live_Dev_script.sql`
-  - `masters` -> `mSwipe_Masters_script.sql`
-  - `dbmtxn` -> `mSwipe_ERP_Live_Dev_script.sql`
-- Total metadata models checked: `114`
-- Models with matching DDL table found: `109`
-- Models without matching DDL table found: `5`
-  - `onboarding/mob3PoApplicationService`
-  - `onboarding/mob3PoApplBankMaster`
-  - `onboarding/mob3PoApplTerminalMaster`
-  - `onboarding/mob3PoApplLocationMaster`
-  - `onboarding/mob3PoApplicationMaster`
-
-## Method Used
-- For legacy strategy analysis, I inferred the table style directly from the DDL:
-  - `existing_id` if the table contains `ss_created_at`/other `ss_*` system columns but no `ss_id`
-  - `generated_id` if the table contains `ss_*` system columns and `ss_id`
-  - `none` if neither legacy pattern is present
-- For field comparison, I used metadata fields that actually carry a `columnName`.
-  - This matters because some physical columns are represented as `relation` or `computed` fields, not just scalar fields.
-- I compared:
-  - metadata `legacyTableType`
-  - entity superclass choice
-  - column presence
-  - `ormType`
-  - `required`
-  - `isPrimaryKey`
-
-## High-Level Findings
-
-### 1. The DDL strongly validates the three superclass meanings
-- `LegacyCommonEntityWithExistingId` is physically visible in DDL as:
-  - legacy business columns
-  - `ss_created_at`, `ss_updated_at`, `ss_deleted_at`, `ss_deleted_tracker`, `ss_published_at`, `ss_locale_name`, `ss_default_entity_locale_id`, `ss_created_by_id`, `ss_updated_by_id`
-  - no `ss_id`
-- `LegacyCommonEntityWithGeneratedId` is physically visible in DDL as:
-  - the same `ss_*` columns
-  - plus `ss_id`
-- `CommonEntity` / `legacyTableType = none` is visible as:
-  - no `ss_*` system columns
-
-### 2. Entity code matches the DDL much better than metadata JSON does
-- Metadata `legacyTableType` mismatches against DDL: `34`
-- Entity superclass mismatches against DDL: `1`
-- This is the single most important finding for the introspection feature.
-- Conclusion:
-  - the entity superclass pattern is currently a more trustworthy signal than historical metadata JSON
-  - introspection should derive legacy strategy from the actual table shape, not from old metadata files
-
-### 3. One table clearly shows live DB drift from generated code
-- [SendOTPDetails entity](/Users/harishpatel/Code/javascript/mswipe-erp-solidx/solid-api/src/onboarding/entities/send-otp-details.entity.ts) extends `LegacyCommonEntityWithExistingId`
-- metadata also says `legacyTableType = existing_id`
-- but the DDL table `SendOTPDetails` has no `ss_*` columns at all
-- This means:
-  - the database still looks `none`
-  - the codebase has already been moved to the legacy wrapper convention
-- This is the clearest example that code and database are not always in lockstep.
-
-## Representative Table Readings
-
-### `existing_id` pattern confirmed by DDL
-- [Account_Categories in mSwipe_Masters_script.sql](/Users/harishpatel/Code/javascript/mswipe-erp-solidx/sql-ddl-statements/mSwipe_Masters_script.sql)
-  - business PK: `AcCat_code`
-  - legacy fields like `Created_By`, `Created_On`, `RowId`, `Row_Version`
-  - SolidX legacy system fields: `ss_created_at` ... `ss_updated_by_id`
-  - no `ss_id`
-- [ReportMaster entity](/Users/harishpatel/Code/javascript/mswipe-erp-solidx/solid-api/src/reports/entities/report-master.entity.ts)
-  - extends `LegacyCommonEntityWithExistingId`
-- [ReportMaster metadata](/Users/harishpatel/Code/javascript/mswipe-erp-solidx/solid-api/src/reports/metadata/reports-metadata.json)
-  - correctly uses `legacyTableType = existing_id`
-
-### `generated_id` pattern confirmed by DDL
-- `frms_lead` in [mSwipe_SolidXCore.sql](/Users/harishpatel/Code/javascript/mswipe-erp-solidx/sql-ddl-statements/mSwipe_SolidXCore.sql)
-  - has `ss_*` system fields
-  - has `ss_id`
-- `Plan_Master` in the same DDL file also follows that pattern
-- [FrmsLead entity](/Users/harishpatel/Code/javascript/mswipe-erp-solidx/solid-api/src/frms/entities/frms-lead.entity.ts)
-  - extends `LegacyCommonEntityWithGeneratedId`
-- [ItemMaster entity](/Users/harishpatel/Code/javascript/mswipe-erp-solidx/solid-api/src/mswipe-masters/entities/item-master.entity.ts)
-  - also extends `LegacyCommonEntityWithGeneratedId`
-
-### `none` pattern confirmed by DDL
-- `SendOTPDetails` in [mSwipe_Applications_script.sql](/Users/harishpatel/Code/javascript/mswipe-erp-solidx/sql-ddl-statements/mSwipe_Applications_script.sql)
-  - no `ss_*` columns
-  - plain identity PK on `Id`
-- This table is important because it proves we cannot assume every entity already matches the live database convention.
-
-## Legacy Strategy Mismatch Summary
-
-### Metadata says `none`, but DDL clearly says legacy table
-- Common examples:
-  - `peoples/employee`
-  - `frms/frmsLead`
-  - `mswipe-masters/itemMaster`
-  - `onboarding/preapplMaster`
-  - `onboarding/bankUpiMasterVtb`
-  - `cpm/customerTerminal`
-- These are mostly incomplete historical metadata entries rather than DDL ambiguity.
-
-### Metadata says legacy, but DDL says `none`
-- Main example:
-  - `onboarding/sendOtpDetails`
-- This looks like real drift between live database and generated code.
-
-## Column Coverage Findings
-
-### Overall
-- Models with at least one physical column gap between DDL and metadata: `51`
-- This is not evenly distributed.
-- Most drift sits in `onboarding`, `frms`, and parts of `cpm`.
-
-### Modules with the most drift
-- `onboarding`
-  - `64` models total
-  - `59` with DDL available
-  - `26` legacy-strategy mismatches
-  - `34` models with physical column gaps
-- `frms`
-  - all `14` models have DDL
-  - all `14` show some column gap
-  - much of this is because metadata enriches physical columns into `relation` or `computed` fields
-- `cpm`
-  - only `1` legacy-strategy mismatch
-  - but `17` models have required/nullability drift
-
-### Real DDL columns missing from metadata
-- [Employees metadata](/Users/harishpatel/Code/javascript/mswipe-erp-solidx/solid-api/src/peoples/metadata/peoples-metadata.json)
-  - DDL has extra columns not mapped in metadata:
-    - `photo`
-    - `VPNUserId`
-    - `youareawesome_ch_allow_post`
-    - `emergency_name`
-    - `emergency_mobile_no`
-    - `fse_opt_address`
-    - `fse_opt_pincode`
-    - `solid_user_id`
-- `Application_Master`
-  - extra DDL columns such as `ZigramEntityId`, `CKYC_ReqId`, `MCC_Code_Display_Value`, `mcc_display_value`, `ZigramAMLDetailsS3URL`, `Modified_through`
-- `bank_file_import`
-  - extra DDL columns such as `source_by`, `product`, `plan_desc`, `bank_source_id`, `sim`, `sim_required`
-- `bulk_customer_industries`
-  - extra DDL columns such as `sample_file_url`, `action`, `approved_by`, `approved_on`, `remarks`, `status`, `is_verified`
-
-### Metadata columns missing from DDL
-- Most of the very large misses come from the five missing `MOB3PO_*` tables, so those are blocked until the matching amextxn DDL exists.
-- Outside of that, there are a few genuine metadata issues:
-  - [onboarding metadata around `meAcnoHb`](/Users/harishpatel/Code/javascript/mswipe-erp-solidx/solid-api/src/onboarding/metadata/onboarding-metadata.json:1936)
-    - `columnName` is incorrectly stored as `"shortText"`
-    - it should clearly be `ME_Acno_HB`
-  - `customerIndustries` carries `legacy_id`
-  - `customerIndustriesLimit` carries `IsVISAEx`
-- There are also media fields in metadata without a direct physical column mapping, which should not be treated as DDL errors for introspection.
-
-## Type Mapping Findings
-
-### Overall
-- Models with at least one `ormType` mismatch: `17`
-
-### The mismatches are mostly normalization choices, not deep incompatibilities
-- `numeric` in DDL is frequently modeled as `decimal` in metadata
-- `char` in DDL is frequently widened to `varchar` in metadata
-- `varchar(max)` / `nvarchar(max)` often collapse to the base text family in metadata
-- `varbinary(max)` is sometimes abstracted more semantically
-
-### Representative examples
-- `Customer_MDR`
-  - several `char` columns are modeled as `varchar`
-- `PreApplication_Master`
-  - several `numeric` columns are modeled as `decimal`
-  - `varchar(MAX)` is collapsed into plain `varchar`
-- `frms_whatsapp_template`
-  - metadata uses `simple-json` where DDL exposes `ntext`
-
-### Implication for introspection
-- The mapper should normalize DDL types into SolidX-friendly metadata types.
-- We should not try to preserve every SQL type string literally.
-
-## Required / Nullable Findings
-
-### Overall
-- Models with at least one `required` mismatch: `59`
-
-### This is a major pattern, especially in legacy modules
-- `Customer_MDR`: `46` required mismatches
-- `Customer_Terminal`: `40`
-- `Customer_Bank`: `21`
-- `Customer_Location`: `14`
-- many other `cpm` and `onboarding` models follow the same pattern
-
-### Interpretation
-- Current hand-curated metadata is often more permissive than the live DDL.
-- In other words:
-  - DDL says `NOT NULL`
-  - metadata still says `required = false`
-- This is likely deliberate in at least some cases, especially for legacy tables and import workflows.
-
-### Implication for introspection
-- We should not hardcode a single policy.
-- Recommended default:
-  - use DDL nullability as the initial suggestion
-  - allow the session-level mapping settings to relax `required` flags for legacy imports
-- This is a good candidate for one of the frontend session options.
-
-## Primary Key Findings
-
-### Overall
-- Models with PK mismatches: `3`
-
-### These are important because they affect superclass choice and model identity
-- `frmsLead`
-  - physical `lead_id` exists
-  - metadata models it as a `computed` field and does not stamp it as primary
-  - this is a semantic enrichment that the DDL alone cannot infer
-- `Appl_Bank_Master`
-  - DDL primary key is composite: `Appl_No` + `Bank_Code`
-  - entity models both as `PrimaryColumn`
-  - metadata only marks `Appl_No` as primary
-- `ERP_Appl_SubCategory_Master`
-  - metadata marks `SubCat_Code` as primary
-  - DDL does not agree
-
-### Implication for introspection
-- Composite PK handling must be explicit in the backend interface.
-- We also need a separate concept of:
-  - physical primary key
-  - chosen user key
-  - chosen SolidX framework identity strategy
-
-## Important Semantic Enrichment Findings
-
-### Some physical columns are intentionally represented as `relation` fields
-- [frmsLead metadata](/Users/harishpatel/Code/javascript/mswipe-erp-solidx/solid-api/src/frms/metadata/frms-metadata.json:500)
-  - `stage_id` is represented as a `relation`
-  - `disposition_id` is represented as a `relation`
-- This is not a DDL mismatch.
-- It is a semantic upgrade beyond DDL.
-
-### Some physical columns are intentionally represented as `computed` fields
-- `frmsLead.leadId`
-  - physically stored in `lead_id`
-  - metadata marks it as `computed`
-  - value provider: `AlphaNumExternalIdComputationProvider`
-- This is another example of behavior that DDL cannot infer on its own.
-
-### Implication
-- The first version of datasource introspection should aim to produce safe, physical metadata.
-- Semantic enrichment such as:
-  - computed IDs
-  - relation promotion
-  - media field promotion
-  - special selection fields
-  should be a second-stage review/edit step, not an implicit guess from raw DDL.
-
-## Additional Metadata Hygiene Findings
-- `dataSource` casing is inconsistent in at least one place:
-  - `Applications` vs `applications`
-- There are malformed metadata entries such as:
-  - `columnName: "shortText"` for `meAcnoHb`
-- These existing inconsistencies reinforce the idea that introspection should write normalized metadata rather than imitating every historical quirk.
-
-## What This Means For The Introspection Design
-
-### 1. Legacy strategy should be derived from the table, not copied from old metadata
-- Detect:
-  - no `ss_*` -> `none`
-  - `ss_*` without `ss_id` -> `existing_id`
-  - `ss_*` with `ss_id` -> `generated_id`
-
-### 2. Model generation should happen in two stages
-- Stage 1: physical mapping
-  - tables
-  - columns
-  - DDL types
-  - nullability
-  - PK / unique / indexes
-- Stage 2: semantic enrichment
-  - relation promotion
-  - computed field upgrades
-  - media field decisions
-  - user-key selection
-  - required-flag relaxation
-
-### 3. Session-level settings are justified
-- Based on the DDL-vs-metadata drift, the frontend should carry per-session settings for:
-  - strict vs relaxed `required` derivation
-  - whether to try relation inference
-  - whether to preserve numeric as `decimal`
-  - how to treat blob/image columns
-  - how to choose user key vs generated legacy id
-
-### 4. Metadata normalization utility will be useful
-- The feature will likely benefit from a small normalization pass that can:
-  - stamp missing `legacyTableType`
-  - fix obvious malformed `columnName` values
-  - standardize datasource casing
-
-## Recommended Next Step
-- We now have enough evidence to proceed with the backend design using:
-  - DDL-driven legacy strategy detection
-  - a provider interface per database engine
-  - a two-stage mapping pipeline
-- Before writing the first implementation, the next design choice to lock down is:
-  - how conservative the first auto-mapped metadata output should be for `required`, `relation`, and `computed` fields