--- id: TST-PFM-MTD-095 title: portal page layouts table kind: integration product_area: platform module: metadata revision: 1 status: draft source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 repository: services-platform files: - modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js implements: [] environment: local implementation_state: implemented latest_result: not-run latest_run_at: null latest_run_ref: null conformance: not-verified estimated_minutes: 5 isolation: >- Prepared integration database and the suite fixture records; fixture teardown restores or removes its own rows. evidence: - 'services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js' - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#modules/layouts/db/portal-page-layouts.table.ts - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#accepts a well-formed row, so each refusal below is about the column it spoils - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#refuses a second definition with the same id in the tenant, by the primary key - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#accepts the same id in another tenant, because the tenant leads the key - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#refuses a purpose that is not an object id, by the purpose check - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#refuses a purpose with no application part, by the purpose check - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#refuses a blank name: the trigger nulls it and the column refuses the null - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#refuses a name longer than two hundred characters, by the name check - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#accepts a name of exactly two hundred characters, so the boundary is where it is stated - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#refuses a layout that is an array rather than an object, by the layout check - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#refuses a layout that is a scalar, by the layout check - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#refuses a layout that is JSON null, by the layout check - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#refuses a sys_locked value outside the two the standard defines, by the locked check - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#refuses a tenant that does not exist, by the tenant foreign key - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#refuses a row with no layout at all, which is a not-null refusal naming the column - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#refuses a row with no name at all, which is a not-null refusal naming the column - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#stamps version 1 and the system instants by default, so a direct write is a complete record - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#carries exactly one unique constraint, over the tenant, the purpose and the id - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#holds both tenants’ rows, read as the owner, so the confinement below is the policy’s doing - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#reads only the acting tenant’s definition - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#reads nothing at all with no tenant, so a statement outside a tenant fails closed - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#refuses a write for another tenant, by the policy rather than a predicate of ours - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#refuses moving one of its own definitions into another tenant - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#leaves the other tenant’s definition in place after both refusals - >- services-platform:modules/layouts/tests/integration/db/portal-page-layouts.table.integration.spec.js#stores a definition of each registered purpose side by side, so the purpose is data and not a partition fixture_imports: - drizzle-orm - ../../../db/portal-page-layouts.table - ../support - '@rhythmsoftware/macroservice-testing/refusals' - '@rhythmsoftware/macroservice-testing/stage' test_doubles: [] limitations: [] unmatched_specification: FND-PFM-MTD-083 binding_assertions: [] --- # Portal page layouts table ## Verification Boundary This integration suite checks reusable record presentations within the local test harness. The registered file and pinned revision define its boundary. ## What This Suite Proves The suite contains executable checks for this module, but no matching detailed scenario is established in this back-fill. The executable coverage finding records that mapping gap. Assertions are evidence of implemented checks; no execution result is claimed. ## What It Does Not Prove The register does not establish a current passing run or full specification conformance. Behavior outside the suite’s fixtures and assertions remains unverified. ## Real Dependencies and Test Doubles The fixture uses PostgreSQL and the imported persistence or API code. The fixture imports identify the setup seams; this register makes no broader claim that dependencies are undoubled. ## Must Not Be Doubled The operation under examination and its asserted stored outcomes must remain real within the declared harness. A fixture cannot replace the write, refusal or transactional effect that the bound scenario checks.