--- id: TST-PFM-MTD-116 title: describe object kind: integration product_area: platform module: metadata revision: 1 status: draft source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 repository: services-platform files: - modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js implements: - ATS-PFM-MTD-002-01 - ATS-PFM-MTD-002-02 - ATS-PFM-MTD-002-05 - ATS-PFM-MTD-005-07 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/metadata/tests/integration/services/describe/describe-object.integration.spec.js' - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#names the object by id, application and labels - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#lists exactly the owner's registered fields, in their declared order - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#marks every field standard, each showing the label the owner gave it - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#describes a list field by its data type, its displays, its label and its options - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#names a reference target by id and labels - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#describes a reference field whole: its definition, its displays and the target beside them - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#does not expand a reference target's own fields - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#carries the properties of a reference field in the one order every described field keeps, the target last - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#lets a form bind an editable field on a create and on an update - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#lets a form bind the record id only on a create - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#lets a form bind neither a server-owned value nor a system stamp - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#marks a computed name computed and unwritable, and says so of nothing else - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#marks the system columns system, the one a client writes among them - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#says of a standard field the owner requires nothing that it is required nowhere - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#lists the owner's collections in registered order - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#describes a collection whole: its labels, its description, its limit and where it may be written - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#names the registered object an element is, by id and labels, never its fields - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#carries no limit and no item object where the owner registered neither - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#answers an empty collection list for an object whose owner registered none - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#lists the custom fields after the standard fields, in creation order - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#describes a custom field by the same contract as a standard one, naming the field it came from - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#gives a custom field no original label, there being no owner label behind it - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#lists every standard field before every custom one, with nothing interleaved - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#described the field while it was live - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#leaves the archived field out of the description - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#shows the tenant's label, keeping the owner's beside it and the data type intact - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#shows the owner's label again once the override is removed - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#describes the overridden field whole: the tenant's label, the owner's as originalLabel, everything else untouched - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#carries the overridden field's properties in the one order every described field keeps, the owner's label before the description - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#describes the list whole: its single-selection displays, its options in order and the archived one flagged - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#carries a custom field's properties in the one order every described field keeps, with no original label between the label and the description - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#keeps a custom field's own required level, which the API enforces and the console enforces for itself - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#the first tenant sees its own custom field and its own label - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#shows the other tenant the registered fields alone - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#shows the other tenant the owner's label on the overridden field - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#shows the other tenant none of the first tenant's custom fields - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#describes the object with its custom fields and its override - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#answers the identical description every time - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#describes the field whole, the user reference beside the write classification - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#leaves the key off a field of the same object that holds no user - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#refuses an object that was never registered - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#refuses an execution with no tenant fixture_imports: - ../../../../services/describe/describe-object - ../../../../services/persistence/custom-fields - ../../../../services/registration/register-application - ../../../../services/persistence/standard-field-label-overrides - ../../support - '@rhythmsoftware/macroservice-testing/execution-context' - '@rhythmsoftware/macroservice-testing/refusals' - '@rhythmsoftware/macroservice-testing/stage' - '@rhythmsoftware/macroservice-errors/errors' test_doubles: [] limitations: [] unmatched_specification: null binding_assertions: - scenario: ATS-PFM-MTD-002-01 provenance: test source: - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#lists every standard field before every custom one, with nothing interleaved - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#shows the tenant's label, keeping the owner's beside it and the data type intact - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#lists the custom fields after the standard fields, in creation order note: >- These references identify the assertions this suite contributes; bindings to additional suites remain part of the scenario’s proof. - scenario: ATS-PFM-MTD-002-02 provenance: test source: - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#lets a form bind neither a server-owned value nor a system stamp - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#marks a computed name computed and unwritable, and says so of nothing else note: >- These references identify the assertions this suite contributes; bindings to additional suites remain part of the scenario’s proof. - scenario: ATS-PFM-MTD-002-05 provenance: test source: - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#shows the other tenant none of the first tenant's custom fields - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#answers the identical description every time note: >- These references identify the assertions this suite contributes; bindings to additional suites remain part of the scenario’s proof. - scenario: ATS-PFM-MTD-005-07 provenance: test source: - >- services-platform:modules/metadata/tests/integration/services/describe/describe-object.integration.spec.js#leaves the archived field out of the description note: >- These references identify the assertions this suite contributes; bindings to additional suites remain part of the scenario’s proof. --- # Describe object ## Verification Boundary This integration suite checks record descriptions and field configuration within the local test harness. The registered file and pinned revision define its boundary. ## What This Suite Proves The bindings identify the detailed or feature scenarios whose outcomes have assertions in this suite. Original case references remain attached to the detailed scenarios so a reviewer can inspect the exact assertion. 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.