Endatix.Modules.Reporting 0.7.6

Endatix.Modules.Reporting

Reporting bounded context for BI-ready survey exports.

Installation:

dotnet add package Endatix.Modules.Reporting

Recommended Usage:

For running and hosting the Endatix Platform, Endatix.Api.Host is the recommended main package as it simplifies the installation and setup process.

dotnet add package Endatix.Api.Host

The module is registered automatically by EndatixBuilder.UseDefaults() — no host code change is needed to get it, and none is needed to keep it off. Availability is decided at runtime by the feature flag (see Registration), not by whether the package is present.

Module layout (Modulith)

Integration pipeline state lives on FlattenedSubmission in the reporting schema. A future reporting read API can expose SubmissionIntegrationSnapshotDto per submission without touching core Submission list endpoints.

Schema

Database schema: reporting

FormSchema compile modes

On every compile path (outbox form.definition.updated, manual POST .../reporting/compile-schema):

Test submissions alone do not force merge. This is a defensive bridge until Form Publish makes publish the controlled compile moment.

Registration

Registered via EndatixBuilder.UseDefaults() → UseModule(ReportingModule.Instance). The module class implements IEndatixModule plus the optional capabilities IHasFeatureFlag (runtime gating), IHasDbMigrations (migration contributor) and IHasFastEndpoints (endpoint discovery, plus serializers and OpenAPI tags — applied by the host only when the module actually registers). It is disabled by default until enabled in configuration:

"Endatix": {
  "FeatureFlags": {
    "ReportingModule": true
  }
}

Migrations

Run the commands from the oss folder.

Migrations live in provider-specific subfolders under Persistence/Migrations/:

• Persistence/Migrations/PostgreSql/ — available (InitialReporting, SeedDefaultExportFormats)

  Tenant export formats are rows, not code. Runtime catalog: DefaultExportFormats.All (SeedDefaultsAsync / tenant.created). Existing tenants: frozen SQL in SeedDefaultExportFormats — do not generate that migration from the catalog; a new default needs a new data migration. New tenants: outbox tenant.created → IDefaultExportFormatsSeeder.

• Persistence/Migrations/SqlServer/ — not yet available. SQL Server support is coming soon (endatix/endatix#813). Use PostgreSQL for Reporting until then.

SQL Server hosts: Do not enable ReportingModule with Endatix:Data:EnableAutoMigrations until SQL Server migrations land in #813. The module DbContext and migration contributor register on SQL Server, but startup auto-migration finds no migrations for the active provider and logs an error (the reporting schema is not created).

Startup also applies Reporting migrations when Customizations:Reporting:ApplyMigrationsAtStartup is true (default) and Endatix:Data:EnableAutoMigrations is enabled.

Add migration

PostgreSQL only (SQL Server: wait for #813).

dotnet ef migrations add <MigrationName> \
  --startup-project src/Endatix.WebHost \
  --project src/Endatix.Modules.Reporting \
  --context ReportingDbContext \
  --output-dir Persistence/Migrations/PostgreSql

Remove last migration

1. List migrations and check whether the last one is already applied locally:

dotnet ef migrations list \
  --startup-project src/Endatix.WebHost \
  --project src/Endatix.Modules.Reporting \
  --context ReportingDbContext

2. If it is applied, roll the database back to the previous migration:

dotnet ef database update <PreviousMigrationName> \
  --startup-project src/Endatix.WebHost \
  --project src/Endatix.Modules.Reporting \
  --context ReportingDbContext

3. Remove the last migration:

dotnet ef migrations remove \
  --startup-project src/Endatix.WebHost \
  --project src/Endatix.Modules.Reporting \
  --context ReportingDbContext

Apply migrations

dotnet ef database update \
  --startup-project src/Endatix.WebHost \
  --project src/Endatix.Modules.Reporting \
  --context ReportingDbContext