@solidxai/core 0.1.9-beta.1 → 0.1.9-beta.11

package/src/testing/steps/ui/assertions.step.ts

@@ -22,6 +22,15 @@ export function registerAssertionSteps(registry: StepRegistry): void {
     await page.waitForSelector(input.selector, { state: "visible" });
   });
 
+  registry.register("ui.expectHidden", async (ctx: TestContext, step: OpStep) => {
+    const page = requirePage(ctx, "ui.expectHidden");
+    const input = (step.with ?? {}) as VisibleInput;
+    if (!input.selector) {
+      throw new Error('Missing "selector" in step.with for op "ui.expectHidden"');
+    }
+    await page.waitForSelector(input.selector, { state: "hidden" });
+  });
+
   registry.register("ui.expectText", async (ctx: TestContext, step: OpStep) => {
     const page = requirePage(ctx, "ui.expectText");
     const input = (step.with ?? {}) as ExpectTextInput;

package/src/testing/steps/ui/form.step.ts

@@ -1,9 +1,12 @@
+import * as path from "path";
+
 import type { TestContext } from "../../contracts/runtime-context.types";
 import type { OpStep } from "../../contracts/testing-metadata.types";
 import { StepRegistry } from "../../core/step-registry";
 
 type FillInput = { selector: string; value: string };
 type SelectInput = { selector: string; value: string };
+type UploadFileInput = { selector: string; filePath: string | string[] };
 
 function requirePage(ctx: TestContext, op: string) {
   if (!ctx.ui || !ctx.ui.page) {
@@ -36,4 +39,20 @@ export function registerFormSteps(registry: StepRegistry): void {
     }
     await page.selectOption(input.selector, String(input.value));
   });
+
+  registry.register("ui.uploadFile", async (ctx: TestContext, step: OpStep) => {
+    const page = requirePage(ctx, "ui.uploadFile");
+    const input = (step.with ?? {}) as UploadFileInput;
+    if (!input.selector) {
+      throw new Error('Missing "selector" in step.with for op "ui.uploadFile"');
+    }
+    if (input.filePath === undefined || input.filePath === null) {
+      throw new Error('Missing "filePath" in step.with for op "ui.uploadFile"');
+    }
+    const cwd = process.cwd();
+    const resolved = Array.isArray(input.filePath)
+      ? input.filePath.map((p) => path.resolve(cwd, String(p)))
+      : path.resolve(cwd, String(input.filePath));
+    await page.setInputFiles(input.selector, resolved);
+  });
 }

package/src/winston.logger.ts

@@ -7,7 +7,7 @@ import * as winston from 'winston';
 import { Environment } from './decorators/disallow-in-production.decorator';
 
 export const WinstonLoggerConfig = {
-    level: process.env.LOG_LEVEL || (process.env.ENV === Environment.Production ? 'warn' : 'debug'),
+    level: process.env.LOG_LEVEL || (process.env.ENV === Environment.Production ? 'info' : 'debug'),
     format: winston.format.combine(
         winston.format.timestamp(),
         winston.format.errors({ stack: true }),

package/tsconfig.json

@@ -12,6 +12,9 @@
     "outDir": "./dist",
     "rootDir": "./src",
     "baseUrl": "./",
+    "paths": {
+      "src/*": ["./src/*"]
+    },
     "incremental": false,
     "skipLibCheck": true,
     "strictNullChecks": false,

package/dev-grooming-docs/ozzy-prompts.txt

@@ -1,70 +0,0 @@
-Hi Ozzy, 
-Can you give me instructions to create a new model in the fees portal module, you can call it address-master. 
-This model needs to have the following fields. 
-1. address1 - shortText 
-2. address2 - shortText 
-3. addressType - selectionStatic with values - home, office & other. 
-4. city - many2one with the city model
-5. state - many2one with the state model
-6. pincode - many2one with the state model. 
-
-After I add this model I want to start storing student address. 
-
-To do this if you can also give me instructions on how to add a relation field to the student model, you can call this field studentAddress.
-
-
-
-
-
-
-Can you now create a new computed field provider. 
-- You can call this provider: StateTotalCitiesComputedFieldProvider
-- This will be a post computation provider and will depend on the city model being inserted, deleted, updated. 
-- The implementation simply needs to take a count of cities that belong to the same state as the city being mutated and update the state totalCities field.
-
-
-Can you now create a new computed field provider. 
-- You can call this provider: StateTotalPopulationComputedFieldProvider
-- This will be a post computation provider and will depend on the city model being inserted, deleted, updated. 
-- The implementation simply needs to take a sum of population of each city that belong to the same state as the city being mutated and update the state totalPopulation field.
-
-
-Can you now create a new computed field provider. 
-- You can call this provider: StateTotalGdpComputedFieldProvider
-- This will be a post computation provider and will depend on the city model being inserted, deleted, updated. 
-- The implementation simply needs to take a sum of gdp of each city that belong to the same state as the city being mutated and update the state totalGdp field.
-- I will add the totalGdp field to the state model after I have the computed provider TS code. 
-
-
-# Testing prompt sequence
-
-## Create Module 
-Can you create a new module called address-master. This will be used to store address master data. 
-
-## Add Model - Country 
-Can you add a new model to the address-master module called country. 
-This will have name, description (richText), countryCode. You can assume name & countryCode to be unique. But only name will be used as a userkey. 
-Also enable audit tracking on the model and all its fields.
-Make sure the table name is properly prefixed with the module name snake case. 
-
-## Add Model - Language
-Can you add a new model to the address-master module called language. 
-This will have language, languageIsoCode. You can assume language to be unique. 
-Also for the languageIsoCode, can you create a field with type staticSelection add a bunch (20 odd, include at-least 7-8 indian languages also) of commonly spoken languages with their respective language codes as values.
-Also enable audit tracking on the model and all its fields.
-Make sure the table name is properly prefixed with the module name snake case. 
-
-## Add Model - Country Language 
-
-Can you now add a new model called CountrySpokenLanguages, this model will have 2 many-to-one fields. 
-1. country - many-to-one with the country model. 
-2. spokenLanguage - many-to-one with the language model. 
-3. spokenBy - int field storing data representing how many people speak that language.
-Also enable audit tracking on the model and all its fields.
-Make sure the table name is properly prefixed with the module name snake case. 
-
-## Add Model - Country Population Trend 
-Can you add a model called CountryPopulationTrend, this model has the following fields. 
-1. country - many-to-one with the country model. 
-2. entryDate - date field. 
-3. populationAsOnDate - int field storing the population of that country as on that date. 

package/docs/grouping-enhancements.md

@@ -1,89 +0,0 @@
-# Grouping & Aggregation Enhancements (Code Review Summary)
-
-This document explains the recent changes to grouping/aggregation in the CRUD helper/service, why they were made, and how to use them (with examples on `PincodeMaster`).
-
-## What Changed and Why
-- **Dedicated grouping pipeline**: Grouping no longer reuses the record-level query (which had `SELECT entity.*`, pagination, and default order). A separate path builds clean group queries to avoid SQL errors and ensure correct counts.
-- **Multiple group-by fields**: The one-field limit was removed. You can now group on multiple fields (including relations) in the requested order.
-- **Relation-safe grouping**: Group-by fields can traverse many-to-one relations (e.g., `state.name`, `city.name`). The helper reuses existing joins (from filters) or adds the necessary joins and aliases.
-- **Date granularity**: Grouping supports `day`, `week`, `month`, `year` granularities in a DB-aware way (Postgres, MySQL/MariaDB, SQL Server).
-- **Aggregates**: Supports a core, DB-agnostic set: `count`, `count_distinct`, `sum`, `avg`, `min`, `max`. If `aggregates` is omitted, it defaults to `count(*)`.
-- **Group sorting/pagination**: Sorting and pagination are applied to group rows (not entity rows). Record pagination is kept separate for non-grouped queries.
-- **Ordered group names**: Group names follow the order of `groupBy` fields. Relation values and date/grouped values are included in sequence.
-- **Formatted date group labels**: You can add an optional format specifier to a date groupBy field: `field:granularity:format`. Supported formats: `MMM`, `MMMM`, `YYYY`, `YYYY-MM`, `YYYY-MM-DD` (defaults to the raw value if omitted).
-- **Count of groups**: Group counts are computed without pagination interference, so `meta.totalRecords` reflects total groups.
-- **DTO update**: `BasicFilterDto` now includes optional `aggregates?: string[]`.
-
-## Caveats
-- `populateGroup` is **not** supported when grouping on relation fields (e.g., `state.name`, `city.name`). Use it for scalar group-by fields only; otherwise fetch group metadata and then retrieve records in a separate call with the group key.
-- Sorting works for group keys without extra colons (e.g., `state.name`) and for aggregate aliases (e.g., `id_max`). For date bucket group keys with granularity/format (`createdAt:month:YYYY`), the sort parser treats the last segment as the order; results may vary by driver and may not sort as expected in all cases.
-
-## Usage Examples (PincodeMaster)
-Assume `PincodeMaster` has many-to-one `state` and `city` relations and a `createdAt` timestamp.
-
-### 1) Group by State and City
-```
-GET /api/pincode-master?offset=0&limit=200&groupBy[0]=state.name&groupBy[1]=city.name
-```
-Returns groups for every state/city combination with default `count(*)` aggregate.
-
-### 2) Group by Relation + Filter on Relation
-```
-GET /api/pincode-master?offset=0&limit=200&groupBy[0]=state.name&filters[state][name][$eq]=Maharashtra
-```
-Groups by state name but only for rows where state is Maharashtra.
-
-### 3) Multiple Group Fields (Relation + Scalar)
-```
-GET /api/pincode-master?offset=0&limit=200&groupBy[0]=state.name&groupBy[1]=city.name&groupBy[2]=pincode
-```
-Group names are ordered: state → city → pincode.
-
-### 4) Group by Date with Granularity (Month)
-```
-GET /api/pincode-master?offset=0&limit=200&groupBy[0]=createdAt:month
-```
-Groups by month (driver-aware), default group labels are raw date buckets.
-
-### 5) Date Granularity with Formatting
-```
-GET /api/pincode-master?offset=0&limit=200&groupBy[0]=createdAt:month:MMM
-```
-Group labels use short month names (Jan, Feb, …). For full names: `createdAt:month:MMMM`. Other formats: `YYYY`, `YYYY-MM`, `YYYY-MM-DD`.
-
-### 6) Aggregates (Count Distinct)
-```
-GET /api/pincode-master?offset=0&limit=200&groupBy[0]=state.name&aggregates[0]=pincode:count_distinct
-```
-Shows distinct pincodes per state.
-
-### 7) Aggregates (Multiple)
-```
-GET /api/pincode-master?offset=0&limit=200&groupBy[0]=state.name&groupBy[1]=city.name&aggregates[0]=id:count&aggregates[1]=id:count_distinct
-```
-Returns both total rows and distinct IDs per state/city group.
-
-### 8) Date Granularity + Relations + Aggregates
-```
-GET /api/pincode-master?offset=0&limit=200&groupBy[0]=createdAt:year&groupBy[1]=state.name&aggregates[0]=pincode:count_distinct
-```
-Distinct pincodes per state, per year.
-
-### 9) Filters with Grouping (Many-to-One)
-```
-GET /api/pincode-master?offset=0&limit=200&groupBy[0]=state.name&groupBy[1]=city.name&filters[state][name][$eq]=Nagaland
-```
-Groups only rows where state.name = Nagaland.
-
-### 10) Group Sorting and Pagination
-- Sorting applies to the group rows. Example:
-```
-GET /api/pincode-master?offset=0&limit=50&groupBy[0]=state.name&sort[0]=state.name:ASC
-```
-- Pagination (`offset/limit`) limits the number of groups returned; total group count remains in `meta.totalRecords`.
-
-## Notes and Behavior
-- If `aggregates` is omitted, `COUNT(*)` is added automatically.
-- Group names reflect `groupBy` order and apply formatting when specified.
-- Group queries reuse joins from filters when possible; otherwise, they create necessary joins for relation paths.
-- Non-grouped find behavior remains unchanged.

package/docs/seed-changes.md

@@ -1,65 +0,0 @@
-# Seeding Enhancements Summary
-
-## Overview
-This document summarizes the changes made to seeding behavior in `solid-core`:
-- Metadata pruning support across targets.
-- CLI flags for selective modules and pruning.
-
-## Pruning Support
-Pruning is now available for most metadata targets. When enabled, records present in the DB but missing from JSON are removed. This is done in two phases:
-1. Identify records in DB not present in JSON.
-2. Delete those records before normal upsert seeding.
-
-### Targets with Pruning
-- Module models + fields (with model-level pruning).
-- Views, actions, menus (with join cleanup).
-- Security rules, list of values, dashboards.
-- Scheduled jobs, saved filters, model sequences.
-- Permissions (also clears role-permission join table).
-
-### Targets WITHOUT Pruning (conservative)
-- Module metadata itself
-- Media storage providers
-- Roles
-- Users
-- Email templates
-- SMS templates
-- System fields (global)
-- Default settings (global)
-
-### Pruning Mode
-Pruning runs **only** when `--prune` is provided. If omitted, pruning is skipped.
-
-## CLI Changes
-### Modules to Seed
-`--conf` was removed. Use:
-```
---modules-to-seed venue,reports
-```
-This passes `modulesToSeed` to the seeder as an array.
-
-## Sample Commands
-### Default seeding
-```
-npx @solidxai/solidctl seed
-```
-
-### Select modules only
-```
-npx @solidxai/solidctl seed --modules-to-seed venue,reports
-```
-
-### Pruning enabled
-```
-npx @solidxai/solidctl seed --modules-to-seed venue --prune
-```
-
-### Pruning enabled (all modules)
-```
-npx @solidxai/solidctl seed --prune
-```
-
-## Files Touched (Key)
-- `src/seeders/module-metadata-seeder.service.ts`
-- `src/commands/seed.command.ts`
-- `src/repository/solid-base.repository.ts` (added `findOneByUserKey`)

package/docs/test-data-workflow.md

@@ -1,200 +0,0 @@
-# Test Data Workflow
-
-This document describes the end-to-end workflow for creating isolated test databases, seeding metadata, loading test data, and tearing everything down.
-
-## Overview
-The workflow is designed to:
-- Create one **test database per configured datasource** in the project.
-- Point the app to those new databases via `.env` updates.
-- Seed all metadata into the fresh databases.
-- Load model-specific `testData` entries from module metadata JSON files.
-- Cleanly reverse everything at the end.
-
-The commands below are the canonical flow.
-
----
-
-## Step 1: Create test datasources
-
-Command:
-```
-npx @solidxai/solidctl test data --setup
-```
-
-What this does:
-- Reads all configured datasources from the Solid registry (`SolidRegistry.getSolidDatabaseModules()`), and uses their `name()` values.
-- Generates a unique **run name** (two words, underscore-separated, e.g. `steady_wolf`).
-- Builds a **timestamped database name** per datasource:
-  - `<datasource>_<timestamp>_<runName>`
-- Backs up the current `.env` into `.env.backup.<runName>`.
-- Rewrites `.env` in-place with new `*_DATABASE_NAME` values.
-- Creates the databases/schemas using TypeORM and the configured connection info.
-- Writes a `.solidx-test-manifest` with the run name + database names so the teardown can reverse everything later.
-
-Example output:
-```
-▶ Running solid test data
-Creating test datasource environment file and manifest.
-Backed up .env to .env.backup.steady_wolf and applied new test datasource names to .env.
-Creating test database/schema "default_20260201234402_steady_wolf" on datasource "default"...
-
-============================================================
-  TEST DATASOURCE ENVIRONMENT CREATED
-------------------------------------------------------------
-  Run name : steady_wolf
-  Env backup : .env.backup.steady_wolf
-
-  Test databases/schemas created:
-- default: default_20260201234402_steady_wolf
-
-  Next steps:
-  1) Using updated .env with test datasource names
-  2) Run solid seed as usual
-  3) Proceed with loading the test data for each module
-  4) Run the test cases 
-  5) Tear down
-============================================================
-
-✔ solid test data completed
-```
-
-Rationale:
-- The `.env` rewrite guarantees the app connects to fresh databases without changing code.
-- The manifest records the run so deletion is safe and deterministic.
-
----
-
-## Step 2: Seed metadata into the new databases
-
-Command:
-```
-npx @solidxai/solidctl seed
-```
-
-What this does:
-- Seeds full module metadata into the **fresh test databases**.
-- Generates the `sa` user if needed and prints its password.
-- Ensures all models, fields, roles, permissions, views, actions, etc. exist before loading test data.
-
-Example output (truncated):
-```
-▶ Running solid seed
-▶ Pruning disabled: existing metadata will be kept.
-▶ No modulesToSeed provided. Seeding ALL modules.
-▶ Seeding Metadata for Module: solid-core
-✔ [solid-core] Module/Model/Fields seeded (upserted 376)
-...
-✔ Seeding completed.
-✔ solid seed completed
-```
-
-Rationale:
-- Test data relies on model metadata and relationships; this ensures the schema and reference data are ready.
-
----
-
-## Step 3: Load test data
-
-Command:
-```
-npx @solidxai/solidctl test data --load
-```
-
-What this does:
-- Reads all module metadata files (or a subset if `--modules-to-test` is provided).
-- Looks for `testData` arrays in each metadata file.
-- Resolves the correct repository for each model (repository name pattern: `<ModelName>Repository`).
-- Performs **upsert-style** inserts using the model’s `userKeyFieldUserKey`.
-- Resolves many-to-one relations using `${fieldName}UserKey`.
-
-Example output:
-```
-▶ Running solid test data
-Test data setup for all modules.
-Processing test data for module: solid-core
-✔ Test data setup complete for module: solid-core
-Processing test data for module: venue
-✔ Test data setup complete for module: venue
-✔ solid test data completed
-```
-
-Rationale:
-- This keeps test fixtures human-readable and tied to module metadata.
-
----
-
-
-## Step 4: Run Tests 
-```
-npx @solidxai/solidctl test run --module venue --api-base-url http://localhost:3000 --ui-base-url http://localhost:5173 --headless false
-```
-
-```
-npx @solidxai/solidctl test run --module venue --list-specs
-```
-
-What this does:
-- Loads `testing.scenarios` from the module metadata file.
-- Applies `--scenario-ids` or `--include-tags` filtering if provided.
-- Boots API and UI adapters with the supplied base URLs.
-- Registers any custom test specs listed in `testing.specs`.
-- Executes scenarios in order with fail‑fast behavior.
-
-Useful variants:
-```
-npx @solidxai/solidctl test run --module venue --scenario-ids api-authenticate-success,api-create-states
-```
-
-```
-npx @solidxai/solidctl test run --module venue --include-tags smoke
-```
-
-```
-npx @solidxai/solidctl test run --module venue --api-base-url http://localhost:3000 --headless true
-```
-
-```
-npx @solidxai/solidctl test run --module venue --headless false
-```
-
-Notes:
-- If your scenario depends on a previous scenario’s `saveAs` output (e.g., `loginSuccess`), ensure the auth scenario runs first.
-- For UI tests, `--ui-base-url` should point to a running frontend server.
-- `--list-specs` prints registered custom `test.spec` ids and exits.
-
-
-## Step 5: Tear everything down
-
-Command:
-```
-npx @solidxai/solidctl test data --teardown
-```
-
-What this does:
-- Restores `.env` from the latest `.env.backup.<runName>`.
-- Deletes all `.env.backup.<runName>` files created by the workflow.
-- Drops each test database/schema recorded in `.solidx-test-manifest`.
-- Deletes the manifest file.
-
-Example output:
-```
-▶ Running solid test data
-Deleting test datasource environment and databases.
-Dropping test database/schema "default_20260201234402_steady_wolf" on datasource "default"...
-✔ Test datasource env files and manifest deleted; test databases dropped.
-✔ solid test data completed
-```
-
-Rationale:
-- Keeps the local environment clean and restores the original `.env` safely.
-
----
-
-## Optional: Limit modules for test data load
-
-You can restrict test data loading to a subset of modules:
-```
-npx @solidxai/solidctl test data --load --modules-to-test venue,reports
-```
-
-Only the listed modules are processed.

package/docs/type-declaration-import-issue.md

@@ -1,24 +0,0 @@
-# Issue: Consumer sees `Property 'id' does not exist on type 'VenueUser'`
-
-## Summary
-The published declaration files in `dist/` import internal types using `src/...` module specifiers. In a consuming project, TypeScript resolves those imports against the consumer's `src` path (or fails), which can cause `User` to extend a different `CommonEntity` that does not define `id`. This leads to `Property 'id' does not exist on type 'VenueUser'` even though `CommonEntity` in the library defines it.
-
-## Evidence
-- `dist/entities/user.entity.d.ts` starts with:
-  - `import { CommonEntity } from "src/entities/common.entity";`
-- `dist/entities/common.entity.d.ts` correctly contains:
-  - `id: number;`
-
-Because the import is `src/...`, the consumer may resolve it to their own `src` tree instead of the library's `dist` types.
-
-## Root Cause
-Library declarations are not portable because internal imports are using absolute `src/...` aliases. These aliases are not part of Node module resolution, so consumers resolve them differently.
-
-## Fix Options
-1. **Preferred:** Replace internal imports in `src/` with relative paths so emitted `.d.ts` files are portable.
-2. **Alternative:** Keep `src/*` aliases but add a post-build step (e.g., `tsc-alias`) to rewrite `dist/**/*.d.ts` imports to relative paths.
-
-## Next Steps
-- Decide on option 1 or 2.
-- Rebuild and verify `dist/**/*.d.ts` no longer import from `src/...`.
-- Publish a new package version and ensure the consuming app resolves `User` and `CommonEntity` from the same package instance.