Merge tenant values with the deploy template catalog so every system
setting (e.g. all montzar_* can_edit=0 keys) appears like khaneghi
advanced settings, not only rows already stored for the tenant.
Co-authored-by: Cursor <cursoragent@cursor.com>
Extend template sync script to generate frontend allow/deny lists so
ProgramSettingsPage can hide can_edit=1 keys before API purge deploys.
Co-authored-by: Cursor <cursoragent@cursor.com>
Superadmin was seeding all deploy_settings_const INSERT keys including
can_edit=1 entries with wrong defaults (e.g. montzar_product_id=25).
Template/catalog now follow final can_edit=0 from SQL; editable keys are
purged from setting_templates and tenant settings on boot/seed.
Co-authored-by: Cursor <cursoragent@cursor.com>
Catalog keys from the SQL template write onto this tenant automatically; only extra keys need a per-key decision.
Co-authored-by: Cursor <cursoragent@cursor.com>
settings/setting_templates were created after replica setup, so the
subscription COPY user could not read them and tablesync looped.
Co-authored-by: Cursor <cursoragent@cursor.com>
A second logical copy unique-conflicts on existing PKs and leaves
tablesync workers stuck, so live UPDATEs never apply on slaves.
Co-authored-by: Cursor <cursoragent@cursor.com>
TCP 127.0.0.1:15432 is often closed; dump/count now fall back to the
cluster socket and runuser -u postgres, which already works on master.
Co-authored-by: Cursor <cursoragent@cursor.com>
TCP 127.0.0.1:15432 is often closed; the cluster listens on a unix
socket. Fall back to /var/run/postgresql then runuser -u postgres.
Co-authored-by: Cursor <cursoragent@cursor.com>
Passwords with @ broke libpq URIs; convert to keyword conninfo.
pg_dump -t public."table" produced empty dumps so replicas stayed at 0.
Co-authored-by: Cursor <cursoragent@cursor.com>
Operator --repair was blocked when pm2 watch owned /tmp lock file.
Only --repair-if-needed uses flock; lock path moved under deploy/.
Co-authored-by: Cursor <cursoragent@cursor.com>
Add sync-replica-data repair on deploy, a publisher-side replica watch
(60s + after tenant/settings writes), REFRESH PUBLICATION after migrate,
and Cache-Control no-store on program-settings and get_version.
Co-authored-by: Cursor <cursoragent@cursor.com>
Catalog keys are compiled into the API bundle so import no longer depends on an incomplete templates table or missing JSON on the server.
Co-authored-by: Cursor <cursoragent@cursor.com>
Import was posting to /admin/login without provider=user, so no token came back even with valid credentials.
Co-authored-by: Cursor <cursoragent@cursor.com>
Template defaults seed from deploy_settings_const; new tenants copy them, import decides per key, and /get_settings reads the per-tenant rows.
Co-authored-by: Cursor <cursoragent@cursor.com>
Sold apps can read settings from /get_settings; Super Admin saves only changed keys so huge runtime logs are not sent in the body.
Co-authored-by: Cursor <cursoragent@cursor.com>
Cast stored JSON through asSettingsArray so tsc accepts the snapshot payload, and strip Prisma ?schema= from DATABASE_URL before psql.
Co-authored-by: Cursor <cursoragent@cursor.com>
Import can_edit=0 settings via the sold version's admin login + get_settings, for Super Admin program-settings UI.
Co-authored-by: Cursor <cursoragent@cursor.com>
Logical replication carries rows but not DDL, so a migration that adds a
column stalls every subscriber with "missing replicated columns" until the
column exists there too. _prisma_migrations is replicated, so migrate deploy
on a subscriber reports nothing pending while its tables lag behind.
sync-replica-schema.sh applies pending migrations to each subscriber first,
tracking them locally in _replica_ddl_applied, then migrates the publisher.
--check reports subscription state and columns missing on any replica.
Co-authored-by: Cursor <cursoragent@cursor.com>
mohmdsdgandCursor