Production deploy failed at migrate with «must be owner of table
identity_organization»: the table (and others created/imported outside the
migration role) were not owned by custocrm_schema, which migration_user must
belong to to run AddField/AlterField. This is a pre-existing condition that
surfaced on the administration migration and recurred across pipelines
(#922, #937, #938) — not caused by the calls feature.
Fix makes deploy self-healing: before running migrate, reassign ownership of
all public-schema objects (tables, sequences, functions) to custocrm_schema
under the postgres superuser. Idempotent and safe on every deploy.
- deploy/postgres/reassign-schema-ownership.sql: reassign public-schema
ownership to custocrm_schema (verified against PG16)
- compose.yaml: mount the SQL into the postgres container
- deploy/cli/lib/deploy.sh: run the normalization step once postgres is
healthy, before the one-shot migrate
C04 RLS relies on the permissive custocrm_schema_access policy (USING/WITH
CHECK true, created by tenancy.0003 on every tenant table) to let login roles
perform cross-tenant writes such as a login-failed audit record with
organization_id IS NULL. That policy is attached to custocrm_schema, but
init-runtime-roles.sh never made custocrm_runtime_app / custocrm_runtime_platform
members of custocrm_schema, so the policy did not cover the login roles and the
write failed with 'violates row-level security policy' even under WITH CHECK
true. Reproduced on a clean DB; the missing membership was the sole cause.
Add the two GRANT statements. Document the bug and the post-cutover CSRF-cookie
fix (62bac47) in INVENTORY-0009 and RUNBOOK-0002.
Andrey