This page lists the changes in CYPEX v2.0.0 that alter the default behavior of the platform without breaking existing integrations. You should be aware of these changes, but they typically do not require action.

A new row is inserted into cypex.t_config with key password_policy and value:

An Organization sits at the centre of two independent mappings, not at the end of a chain. One mapping says which roles belong to the organization; the other says which schemas it may use. Both point at cypex.t_organization, and neither knows about the other:

pg_roles                          cypex.t_module
(login identity, grants)          (schema registry)
    │                                   │
    │  cypex.t_role_organization        │  cypex.t_module_organization
    │  (role_name ↔ organization)       │  (module_id ↔ organization)
    │                                   │
    └──────────►  cypex.t_organization  ◄──────────┘
                  (the tenant boundary)

A user sees a row only when both mappings agree: their role is mapped to the organization, and the schema holding the object is granted to that same organization. Satisfying one without the other produces an empty result, not a partial one.

In CYPEX, an Organization is the unit of multi-tenancy. Isolation is enforced in PostgreSQL by Row-Level Security policies that read the request JWT, not by filters in application code. Application traffic — the generated UI, PostgREST API clients, and the backend’s end-user request path — is subject to the same policies, so reaching the database through a different client does not widen what a user can see.

Organizations are not an authorization system on their own. They add a per-request data scope on top of the PostgreSQL role grants that decide what a user may do.

This page lists the purely additive changes in CYPEX v2.0.0. These do not modify the behavior of existing functionality — they add new tables, functions, indexes, and roles that integrate with the Organizations model.

The central tenant table. Created by the v2.0.0 upgrade with one row already inserted: the Default Organization (organization_domain = 'default').

After running the client-assignment migration, walk through the verification queries on this page. If verification fails, follow the rollback procedure.

For every migrated table:

Run through this checklist before applying the v2.0.0 migration scripts. Each item links to the page that explains why it matters.

• Full logical backup with pg_dump:

  ```bash
  pg_dump --no-owner --no-privileges -Fc -f cypex-pre-v2.dump cypex
  ```
  

• Filesystem snapshot of the PostgreSQL data directory, if your infrastructure supports it.

This page lists the upgrade scenarios that were exercised against the v2.0.0 migration scripts, the result of each, and the explicit answer to the most common question: does RLS change row visibility for existing single-tenant data?

Info

No. RLS does not change row visibility for existing single-tenant data. All existing rows remain visible to all existing users after the upgrade.

The mechanism is described in detail on RLS impact on existing data. The short version: the upgrade creates a Default Organization, maps every existing role to it, and the RLS policies explicitly allow organization_id IS NULL rows to be visible. Existing single-tenant data therefore continues to be readable.

This page answers the most common question about the v2.0.0 upgrade:

Info

Does enabling RLS change row visibility for existing single-tenant data?

No. Existing single-tenant data remains visible to all existing users after the upgrade. The migration is designed so that the transition from v1.x to v2.0.0 is transparent for end users at the row-visibility level.

This page describes the v2.0.0 role model and how roles, JWTs, and RLS policies work together to enforce multi-tenant isolation.

All three roles are created as NOLOGIN group roles. Humans (and the authenticator pool) log in as other roles that are granted membership in these groups — they never LOGIN as cypex_admin, cypex_user, or organization_admin themselves.

The v2.0.0 upgrade installs a default password policy by inserting a row into cypex.t_config with key password_policy. This page documents the policy, how to verify it on your instance, and how to override it.

The migration inserts:

1
2
3
4
5
6
7

{
  "minLength": 4,
  "minUppercase": 0,
  "minLowercase": 0,
  "minNumbers": 0,
  "minSpecial": 0
}

This is very permissive by design. The rationale is that shipping a working default is preferable to locking existing users out at upgrade time. Once the upgrade is complete, administrators should review the policy and tighten it to match their security requirements.