--- id: TST-PFM-SEC-186 title: Approved workspace access database and service checks kind: integration product_area: platform module: security revision: 2 status: draft source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 repository: services-platform files: - >- modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js implements: - ATS-PFM-SEC-017-02 - ATS-PFM-SEC-017-04 - ATS-PFM-SEC-017-05 - ATS-PFM-SEC-017-06 - ATS-PFM-SEC-017-08 - ATS-PFM-SEC-017-11 environment: local implementation_state: implemented latest_result: not-run latest_run_at: null latest_run_ref: null conformance: not-verified estimated_minutes: 3 isolation: Use the prepared test database and suite-owned fixture rows; retain shared seed records. assertion_evidence: - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#staff access capability: approved access a tenant decides - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#asking a customer for access to one of its tenants - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#stores an approved grant in the requested state, with the window it asked for - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#materializes nothing, so asking grants no access at all - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#writes a security audit event that is not a widening, because nothing was granted - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#e-mails the tenant’s administrators, and nobody else - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#tells the administrators where to decide it, and names no token of any kind - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#refuses a second request for the same tenant, naming the one already open - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#lists the request as the caller’s own, with the names of what it would reach - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#approving a request - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#makes the grant active from now, for the time the approver chose - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#materializes a tenant-scoped assignment of the role, ending when the grant does - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#is the grant the shared read answers for that staff member and tenant - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#answers no grant once the window has closed - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#stores the ended grant as expired, settled by the read that saw it - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#writes a widening audit event naming the assignment and who decided - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#e-mails the staff member who asked, and nobody else - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#an approval may shorten the time asked for and never lengthen it - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#gives the two days that were asked for, not the thirty the approver named - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#refuses a duration outside the one-to-thirty-day range before it decides anything - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#declining and withdrawing - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#stores a declined request with the reason the administrator gave and no assignment - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#tells the staff member who asked - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#records a withdrawal as the requester’s own decision, so it is not read as the customer refusing - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#refuses a second withdrawal of the same request - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#revoking what is active, of every kind - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#revokes an approved grant with the reason given - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#revokes the assignment the grant materialized, so the access is gone at once - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#tells the staff member their access ended - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#revokes an emergency grant the customer never approved in the first place - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#revokes a standing grant, which a deploy would otherwise keep ensuring - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#leaves that standing grant revoked when standing access is ensured again - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#giving a member of Rhythm’s staff access directly - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#writes an approved grant that is active and decided at once, by the administrator who gave it - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#materializes the assignment that is the access - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#writes a widening audit event for it - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#e-mails the staff member it was given to and the tenant’s administrators - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#shows the grant in the tenant’s own list, with the role and the state - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#refuses an address that belongs to nobody at Rhythm, and writes nothing - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#the authorizer flush each of the tenant’s decisions submits after its commit - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#submits one flush when a request is approved, so the staff member is let in at once - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#submits one flush when access is given directly - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#submits one flush when an approved grant is revoked, once the revoke has committed - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#submits one flush when an emergency grant is revoked - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#submits one flush when a customer-level standing grant is revoked - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#submits no second flush when the revoke of an already revoked grant is refused - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#submits no flush when the revoke of a grant that was never active is refused - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#the monthly emergency report - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#reads the month in the execution’s own zone, half-open - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#reports the grant opened in the month, with every name behind it - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#leaves out the one opened in the next month, which that month’s report holds instead - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#refuses a month that is not YYYY-MM - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#a Rhythm Administrator’s customer-level standing access, seen from the tenant - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#is a customer-level standing grant of Acme, the premise of every case below - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#refuses a request into a tenant of that customer 409 staff_access_grant_active, naming the customer-level grant - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#is in the tenant’s own list, with no tenant of its own - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#refuses a revoke giving a reason the system reserves for its own revocations, leaving the grant active - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#is revoked by the tenant’s administrator, from any tenant of the customer, with its customer-scoped assignment - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#is left revoked by the deploy’s ensure and by the role hook, a person’s revoke - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#gains no new grant into the customer - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#a request from a staff member already holding a grant into the tenant - provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js#refuses it 409 staff_access_grant_active, naming the tenant-level grant dependency_evidence: >- The prepared PostgreSQL database supplies the persisted fixtures and constraints exercised here. The suite controls the clock at the declared seams; those collaborators remain outside its live proof. evidence: - >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js - >- Static review at the recorded source revision; executable results remain not-run and conformance remains not-verified. binding_note: >- Each binding names the scenario to which this file contributes assertions. A binding is not a recorded pass and does not extend the file’s dependency boundary. examiner: codex examined_at: '2026-10-23' final_text: OpenAI dependency_review: provenance: test source: >- services-platform:modules/security/tests/integration/services/staff-access/approved-tenant-access.integration.spec.js explicit_no_doubles: false identified_double_boundaries: - the clock --- # Approved workspace access database and service checks ## Verification Boundary The file exercises database or service behavior through the local integration harness. The assertion references identify the source checks for approved workspace access. ## What This Suite Proves The source assertions support the observations named in the bound scenarios. A scenario spanning multiple files must retain the other files’ contributions. ## What It Does Not Prove This examination does not run the suite. Passing behavior, deployed conformance and the behavior of substituted dependencies require separate execution evidence. ## Real Dependencies and Test Doubles The prepared PostgreSQL database supplies the persisted fixtures and constraints exercised here. The suite controls the clock at the declared seams; those collaborators remain outside its live proof. ## Must Not Be Doubled Keep the queried database, applicable constraints and transaction boundaries real. Provider substitutes cannot establish delivery, cloud execution or cross-service recovery.