--- id: TST-PFM-DJE-116 title: Configuration data jobs kind: integration product_area: platform module: data-job-engine revision: 1 status: draft source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 macroservice-libraries: 54536a441935c6e09fdb7f96f0bec71c52ba4e03 services-crm: a8d1364f1dd44b723bb5f9acba12f983e9ec8d69 services-membership: 5994c270e8a37a30f848e99ba5b5ee6b87c08893 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f repository: services-crm files: - modules/data-jobs/tests/integration/services/jobs/configuration-data-jobs.integration.spec.js implements: - ATS-PFM-DJE-001-08 - ATS-PFM-DJE-002-02 - ATS-PFM-DJE-010-01 - ATS-PFM-DJE-010-03 environment: local implementation_state: implemented latest_result: not-run latest_run_at: null latest_run_ref: null conformance: not-verified estimated_minutes: 5 isolation: >- Suite-owned fixture records, job identifiers and workspace contexts; teardown removes the fixture data. evidence: - >- services-crm:modules/data-jobs/tests/integration/services/jobs/configuration-data-jobs.integration.spec.js assertion_inventory: - 'a configuration type’s data jobs: the ones of that type, and no other' - reading a job through its own object type’s routes - 'answers the job of this object type, naming the type it is of' - 'answers its one frozen item’s outcome and its empty rejection page, so a run can poll both' - >- answers the job of regions through the regions routes, which are the same handlers over another type - 'a job of another object type, named through these routes' - >- is read by the capability every object type shares, so what follows is scope and not a broken read (premise) - 'is not found by the status read, which says no more than that' - is not found by the results page - is not found by the rejections page - 'is not found by the apply, so a validated job of contacts cannot be started from here' - is not found by any of the four control actions - >- is left exactly as it was by all nine refusals, still validating and still waiting for its own routes - the list of one object type’s jobs - 'answers the jobs of this type, newest first, and no job of another type' - 'says of every row that it is of this object type, which is what the route promises' - 'answers the regions list the one job of regions, through the same capability and another scope' - honours the filters a caller sent beside the object type the route chose - >- answers a caller without this object’s bulk key only the jobs of this type they submitted themselves - applying and cancelling a job of this object type - answered an impact digest for the validated insert (premise) - refuses an apply of the validated insert that echoes no impact digest - refuses an apply of the validated insert whose digest is not the one the validation answered - 'leaves the job validated after both refusals, so the refused applies queued nothing' - 'queues the frozen items of its own validated job, which is what an apply does' - >- writes no contact type until a batch of the apply runs, so the apply queued work and performed none - 'cancels its own job, finishing it with nothing committed' - 'a bulk delete of contact types: twelve named, two of them in use' - 'answers the validation’s impact: ten it would delete and two it is blocked on' - says both are blocked because they are in use - 'counts what uses them per object type: the three contacts that hold the two types' - 'asks a person to type the number it would delete, not the number submitted' - 'refuses an apply with the wrong phrase, naming the confirmation' - refuses an apply with a digest that is not the validation’s - deletes nothing for either refused approval - deletes the ten types nothing uses and leaves the two that contacts hold - >- counts the ten it deleted on the job, and the two it refused again at the apply as conflicts, as a contact delete does - >- names, per type it left, the code in_use with no field and the counts in the message, never a record’s value - 'a bulk delete of contact types: one becomes used after the validation' - validated all three as deletable (premise) - deletes the two still unused and keeps the one a contact now holds - >- reports the one kept as a conflict with the code in_use, a concurrent change and not a failure of the job - 'a bulk delete: what a submitter must hold, and what a type may be' - 'refuses a submitter without the delete key, naming it' - 'refuses a submitter without the update key a status patch needs, naming it' - >- declares the bulk key and the delete key of every catalogue as what a delete needs, the keys its single DELETE route needs - 'rejects an id the tenant does not have as not_found, naming the field' - blocks a type locked against deletes as record_locked and deletes nothing - blocks a contact role that holds nothing but is a protected system record as record_protected - >- a bulk status change of contact types: twelve deactivated, activated again, one edited in between - validates the deactivation of all twelve as updates - 'deactivates all twelve, which is what Show Inactive then lists' - 'keeps the rest of each type as it was: name and description' - bumps each type’s version once - counts the twelve applied on the job - activates all twelve again - >- deactivates the two nobody edited and names the edited one as a version conflict, writing nothing over it - a bulk status change of the other catalogues that have a status - deactivates two contact roles and keeps their descriptions and their automatic assignment - deactivates two organization types and keeps their names - 'refuses a status patch of an address type, which has no status' registration_note: Registration describes existing source; the suite is not executed by this documentation job. --- # Configuration data jobs ## Verification Boundary The suite checks the production service or shared engine against its database fixture. The structured assertion inventory records the checks present at the pinned revision. ## What This Suite Proves The existing checks exercise configuration data jobs. The specification bindings identify the narrower outcomes supported by those assertions. ## What It Does Not Prove Local execution does not establish deployed queue, storage or service behavior. Independent test cases do not establish a complete cross-feature process. ## Real Dependencies and Test Doubles The owning service exercises production persistence and domain behavior against real Postgres. The fixture supplies caller contexts; queue delivery, storage and external calls are doubled where the file installs a test port. ## Must Not Be Doubled The database effects, security context and production operation under examination remain real. Their outcomes cannot be replaced with canned success responses.