Found while probing the insert path of the owner_name stamp for #67 (base c3c6526, memory
driver, demo seed complete). Out of that card's scope; filed.
What was measured
PlatformAdminSet declares ats_employer: { allowRead, allowCreate, allowEdit, allowDelete, viewAllRecords, modifyAllRecords } (src/security/permission-sets.ts). Signed in as
admin@platform.example, POST /api/v1/data/ats_employer:
| Caller |
Payload |
Result |
admin@platform.example |
no organization fields |
HTTP 500 ERR_SYSTEM_WRITE_ORGANIZATION_REQUIRED, body {"error":"Internal server error"} |
admin@platform.example |
organization and organization_id set to an existing org |
HTTP 500, same code |
admin@quillstone.example (employer admin) |
its own org |
HTTP 403 PERMISSION_DENIED — its RLS check refuses, which is the intended posture |
GET /api/v1/auth/organization/list as admin@platform.example returns []: the persona holds no
organization membership, and the write demands one no matter what the payload carries. So the
allowCreate: true the platform set grants on ats_employer cannot be exercised by any persona in
the app — every one of the 12 seeded rows exists because the seeder writes as the system.
Two separate problems in one response:
- The capability is declared and unusable. Either the platform persona needs whatever
organization context this write requires, or allowCreate on ats_employer is a false claim
about what the platform can do.
- The failure is a 500 with an internal code.
ERR_SYSTEM_WRITE_ORGANIZATION_REQUIRED is a
precondition on the caller, not a server fault; it reaches the client as
{"error":"Internal server error"} with no located, corrective message — the shape every gate in
this repo is written to avoid.
Same family as #45 (employer administrators cannot create ats_job, 403) and the tenancy seam in
#39 / #20. Not a duplicate of either: different object, different caller, different status code.
Reproduce:
OS_PLATFORM_OWNER_EMAIL=admin@objectos.ai npx objectstack dev --fresh --database-driver memory -p 4671 --log-level info
# after [Seeder] Seed loading complete, sign in as admin@platform.example / demo1234
# POST /api/v1/data/ats_employer {"name":"probe","verification_status":"draft","service_tier":"trial"}
Found while probing the insert path of the
owner_namestamp for #67 (basec3c6526, memorydriver, demo seed complete). Out of that card's scope; filed.
What was measured
PlatformAdminSetdeclaresats_employer: { allowRead, allowCreate, allowEdit, allowDelete, viewAllRecords, modifyAllRecords }(src/security/permission-sets.ts). Signed in asadmin@platform.example,POST /api/v1/data/ats_employer:admin@platform.exampleERR_SYSTEM_WRITE_ORGANIZATION_REQUIRED, body{"error":"Internal server error"}admin@platform.exampleorganizationandorganization_idset to an existing orgadmin@quillstone.example(employer admin)PERMISSION_DENIED— its RLScheckrefuses, which is the intended postureGET /api/v1/auth/organization/listasadmin@platform.examplereturns[]: the persona holds noorganization membership, and the write demands one no matter what the payload carries. So the
allowCreate: truethe platform set grants onats_employercannot be exercised by any persona inthe app — every one of the 12 seeded rows exists because the seeder writes as the system.
Two separate problems in one response:
organization context this write requires, or
allowCreateonats_employeris a false claimabout what the platform can do.
ERR_SYSTEM_WRITE_ORGANIZATION_REQUIREDis aprecondition on the caller, not a server fault; it reaches the client as
{"error":"Internal server error"}with no located, corrective message — the shape every gate inthis repo is written to avoid.
Same family as #45 (employer administrators cannot create
ats_job, 403) and the tenancy seam in#39 / #20. Not a duplicate of either: different object, different caller, different status code.
Reproduce: