Hi ABP team,
We're building a multi-tenant healthcare product (outpatient queue management) on ABP Commercial 10.6.0 / .NET 10, modern single-layer template with the React UI, using the Low-Code System module for tenant-configurable data capture (e.g. pre-appointment questionnaires). Our deployment is database-per-tenant with separated host/tenant schemas — each tenant has its own database built from its own migration set.
What we've observed with the Low-Code module in this topology:
The designer model is a single global document: LowCodeModels has no TenantId, and when a tenant admin edits the model in the Admin Console designer, the mutations are persisted to the host database's model document (verified via LowCodeModelMutationHistories). Entities created by a tenant admin therefore appear in every tenant's menu. However, the physical table for a tenant-created entity is created by IDynamicTableCreator under the current tenant's connection, i.e. only in the creating tenant's database. The result is an entity that is defined platform-wide but whose table exists in exactly one tenant database — other tenants (and the host) see the entity but cannot use it. The dynamic permission definitions (Dynamic__<Entity>__*) are persisted to the host-side dynamic permission store only, so tenant users receive 403s on dynamic pages in separate-database tenants. Deleting an entity in the designer removes it from the model document but leaves the physical table in place (we understand this is deliberate data protection — a supported cleanup path would still be welcome).
Our questions:
Is tenant-scoped modelling on the module's roadmap? Specifically the semantics we need: host-authored entities shared with all tenants; tenant-authored entities private to the authoring tenant. The layered model architecture (DynamicModelLayerBase, ModelJsonComposer, RuntimeJsonDynamicModelLayer, DynamicEntititesModelCacheKeyFactory) looks purpose-built for a tenant overlay layer, so we'd rather wait for an official implementation than build one. If it's planned, is there a rough timeline? If it's not planned: what is the supported extension path? Is implementing a custom DynamicModelLayerBase-derived tenant layer plus a replaced IDynamicTableCreator (fanning host-published tables out to tenant databases) the intended seam, or are there internal assumptions (designer app service, concurrency stamp, mutation history, save points, EF model cache) that make this unsupported today? In the meantime, is the observed behaviour in (1)+(2) — tenant-admin edits landing in the global model while the table lands tenant-side — intended, or should we log it as a defect? For now we're revoking AbpLowCodeDesigner.* from tenant roles as a safety measure. Is there a recommended way to scope visibility of host-authored entities per tenant (e.g. via the dynamic permissions or features) that you'd consider supported?
