PBJ Vault — Changelog
Current release: 7.0.0 (September 2026)
7.0.0 — 4 September 2026
7.0.0 — THE SUITE MAJOR, requiring PBJ CRM 7.0.0. One equal version across the suite. No schema, crypto or vault change — DB stays 1.
Full release notes: PBJ CRM Suite 7.0.0.
1.18.0 — 29 August 2026
The settings screen is declared at a fixed level instead of one worked out at start-up. The old check ran before the site knew who was asking, so it always fell back to the WordPress-administrator level. A CRM owner now reaches the screen. Handing one person the Archive without making them an owner is unchanged, and nothing about who can read a vault entry changes.
1.17.0 — 28 August 2026
- Vault records are drawn with the suite’s shared cards, reading panes, record screens and file surfaces, so the Vault looks and behaves like the rest of the CRM.
- Every security boundary is unchanged, including the deliberate per-field reveal. The surfaces moved; the vault did not.
1.16.0 — 24 August 2026
- Unlocked and pinned Vault lists now use CRM-owned item cards, readers and saved workspaces without module-owned ordinary card geometry.
- Vault readers remain metadata-only; protected values, reveal, grants, unlock and record editing are unchanged.
- Legacy standalone rendering remains available when the CRM UI contract is not present.
1.15.0 — 24 August 2026
- Unlocked and pinned Vault lists now use CRM-owned cards and saved workspaces.
- Ordinary module-owned card and splitter styling has been removed.
- Locked lists, protected values, reveal, grants, unlock and record editing remain unchanged.
1.14.0
The Vault’s front end is sub-databases and records, and nothing else. That is what people use it for day to day, and that is now all it shows.
Per-record sharing grants have moved to the website admin, beside the other owner-only controls that already lived there. Nothing was taken away; it was moved to where the rest of its kind already was.
Nothing about the vault itself changes: no schema change, no change to your passphrase, your recovery code or anything stored.
1.13.0
Manage records can now show all records, pinned records or unpinned records. The filter works across the complete Vault record list, so unfiled records can be found without opening each sub-database by hand.
Pin management is assignment-first. Each record shows who it is pinned to, existing pins can be removed, and People, Businesses and Staff are found through search rather than an ID dropdown. Use “Add another” to pin the same record to multiple contacts in one save; protected Vault values are never loaded into the manager.
1.12.0
Choosing where to pin a Vault record is now a search instead of a long dropdown. Business, contact and staff results remain limited to records the viewer may use.
Modules → Vault → Manage records is now a real record manager. It searches, filters, sorts and pages across sub-databases, with deliberate row and selected-record deletion. Vault metadata can also appear in CRM Everything without reading or exposing protected values. No encryption, recovery, permission-schema or database change.
1.11.0
Vault records now appear on the correct CRM business, client-person and staff profiles. A business pin uses the business itself instead of a guessed contact-row number.
A person who is both a client and a member of staff can be filed under Client, Staff or Both. Records filed to both are shown once, and every pin is checked against both Vault access and CRM visibility.
Older business and staff pins remain untouched and continue to be read safely. Requires PBJ CRM 1.44.0. No encryption or table change.
1.10.0
The “Vault” heading no longer repeats the Vault tab above it, and the file viewer and its panels follow your theme’s colours.
1.9.0
A vault entry is now something you can attach things to — tasks, notes and files.
Nothing about the vault itself changes. Only the entry’s name is ever read for this. Every secret stays encrypted and still needs the vault unlocked, exactly as before.
1.8.0
An assistant can now see what sub-databases you have and what fields they hold — their names, the fields on them, how many records in each you are allowed to open, and what they can be pinned to. A field that is protected is named as protected and never read: the assistant is told the field exists and nothing more, and the value never leaves the vault. That was checked with the vault locked, and again with it unlocked, and nothing came out either way. It is reading only — there is no way for an assistant to create, change or delete a sub-database.
1.7.0
“What has changed since” now gives an honest total. Ask an assistant which vault records have changed since a date and the number it reports is the number that really did change, counted after the who-can-see-this rules have been applied, so sharing is untouched. It used to hand back the total for every record you can see, which meant the number and the records listed beside it disagreed. An assistant asking what has changed now gets the complete answer.
1.6.0
The Archive is now the Vault, everywhere you can see. A rename and only a rename: your data, the encryption, the lock, your license and every address are exactly as they were.
1.5.0
Record names, types and pins are available to the CRM’s new assistant connector — never a protected value, and never anything from a locked vault. Requires PBJ CRM 1.29.0 or newer.
1.4.0
The Vault home screen gains a search across every sub-database by name. Records stay out of the suite’s shared search on purpose — vault searching happens only inside the Vault. A locked vault still shows names and types only, never a protected value.
1.3.0
Housekeeping, with nothing touched in the vault. There is no change to encryption, to how the vault locks or unlocks, to who can see what, or to the database — and that is worth saying plainly, because it is the first question anyone asks of an Archive release.
The plugin now checks that PBJ CRM is not just installed but new enough, and says so with one notice instead of failing. It also asks for a slightly newer WordPress, because that is the version where WordPress began enforcing the CRM requirement at all. And if you remove the plugin while choosing to keep your data, its daily background job is now cleared out properly instead of being left pointing at something that is gone.
1.2.0
Internal only. PBJ Archive now declares its eight tables and two settings to PBJ CRM, so a future whole-suite backup includes them. The vault table is flagged as essential — without it, a restored backup’s encrypted values could never be read again — and the entry tables are flagged as needing their record numbers preserved, because those numbers are part of what the encryption checks. Nothing changes on screen, no data is touched, and there is no database change.
1.1.0
PBJ Archive now formally requires PBJ CRM, matching how it is sold: WordPress itself checks for the CRM, and if it is missing you get one plain message instead of a half-working plugin. Revealing a value now honours the “require an unlocked vault even to list records” setting. Signing out also clears your own vault session immediately rather than leaving it to time out. And filing a record from a business profile now offers the right sub-databases for a business.
1.0.0
First release. Sub-databases you design or build from a CSV (secret columns auto-detected); vault encryption (XChaCha20-Poly1305 / AES-256-GCM) under your passphrase with a one-time printed recovery code; reveal-on-click one field at a time with a full audit trail; per-type access levels plus per-record grants; records pinned to PBJ CRM companies, contacts and agents; a 31-point security self-test you can run yourself; plain-words fallback (and an upgrade path) for servers without the fast key-derivation extension.
Current release: 7.0.0 (September 2026)
7.0.0 — 4 September 2026
7.0.0 — THE SUITE MAJOR, requiring PBJ CRM 7.0.0. One equal version across the suite. No schema, crypto or vault change — DB stays 1.
Full release notes: PBJ CRM Suite 7.0.0.
1.18.0 — 29 August 2026
The settings screen is declared at a fixed level instead of one worked out at start-up. The old check ran before the site knew who was asking, so it always fell back to the WordPress-administrator level. A CRM owner now reaches the screen. Handing one person the Archive without making them an owner is unchanged, and nothing about who can read a vault entry changes.
1.17.0 — 28 August 2026
- Vault records are drawn with the suite’s shared cards, reading panes, record screens and file surfaces, so the Vault looks and behaves like the rest of the CRM.
- Every security boundary is unchanged, including the deliberate per-field reveal. The surfaces moved; the vault did not.
1.16.0 — 24 August 2026
- Unlocked and pinned Vault lists now use CRM-owned item cards, readers and saved workspaces without module-owned ordinary card geometry.
- Vault readers remain metadata-only; protected values, reveal, grants, unlock and record editing are unchanged.
- Legacy standalone rendering remains available when the CRM UI contract is not present.
1.15.0 — 24 August 2026
- Unlocked and pinned Vault lists now use CRM-owned cards and saved workspaces.
- Ordinary module-owned card and splitter styling has been removed.
- Locked lists, protected values, reveal, grants, unlock and record editing remain unchanged.
1.14.0
The Vault’s front end is sub-databases and records, and nothing else. That is what people use it for day to day, and that is now all it shows.
Per-record sharing grants have moved to the website admin, beside the other owner-only controls that already lived there. Nothing was taken away; it was moved to where the rest of its kind already was.
Nothing about the vault itself changes: no schema change, no change to your passphrase, your recovery code or anything stored.
1.13.0
Manage records can now show all records, pinned records or unpinned records. The filter works across the complete Vault record list, so unfiled records can be found without opening each sub-database by hand.
Pin management is assignment-first. Each record shows who it is pinned to, existing pins can be removed, and People, Businesses and Staff are found through search rather than an ID dropdown. Use “Add another” to pin the same record to multiple contacts in one save; protected Vault values are never loaded into the manager.
1.12.0
Choosing where to pin a Vault record is now a search instead of a long dropdown. Business, contact and staff results remain limited to records the viewer may use.
Modules → Vault → Manage records is now a real record manager. It searches, filters, sorts and pages across sub-databases, with deliberate row and selected-record deletion. Vault metadata can also appear in CRM Everything without reading or exposing protected values. No encryption, recovery, permission-schema or database change.
1.11.0
Vault records now appear on the correct CRM business, client-person and staff profiles. A business pin uses the business itself instead of a guessed contact-row number.
A person who is both a client and a member of staff can be filed under Client, Staff or Both. Records filed to both are shown once, and every pin is checked against both Vault access and CRM visibility.
Older business and staff pins remain untouched and continue to be read safely. Requires PBJ CRM 1.44.0. No encryption or table change.
1.10.0
The “Vault” heading no longer repeats the Vault tab above it, and the file viewer and its panels follow your theme’s colours.
1.9.0
A vault entry is now something you can attach things to — tasks, notes and files.
Nothing about the vault itself changes. Only the entry’s name is ever read for this. Every secret stays encrypted and still needs the vault unlocked, exactly as before.
1.8.0
An assistant can now see what sub-databases you have and what fields they hold — their names, the fields on them, how many records in each you are allowed to open, and what they can be pinned to. A field that is protected is named as protected and never read: the assistant is told the field exists and nothing more, and the value never leaves the vault. That was checked with the vault locked, and again with it unlocked, and nothing came out either way. It is reading only — there is no way for an assistant to create, change or delete a sub-database.
1.7.0
“What has changed since” now gives an honest total. Ask an assistant which vault records have changed since a date and the number it reports is the number that really did change, counted after the who-can-see-this rules have been applied, so sharing is untouched. It used to hand back the total for every record you can see, which meant the number and the records listed beside it disagreed. An assistant asking what has changed now gets the complete answer.
1.6.0
The Archive is now the Vault, everywhere you can see. A rename and only a rename: your data, the encryption, the lock, your license and every address are exactly as they were.
1.5.0
Record names, types and pins are available to the CRM’s new assistant connector — never a protected value, and never anything from a locked vault. Requires PBJ CRM 1.29.0 or newer.
1.4.0
The Vault home screen gains a search across every sub-database by name. Records stay out of the suite’s shared search on purpose — vault searching happens only inside the Vault. A locked vault still shows names and types only, never a protected value.
1.3.0
Housekeeping, with nothing touched in the vault. There is no change to encryption, to how the vault locks or unlocks, to who can see what, or to the database — and that is worth saying plainly, because it is the first question anyone asks of an Archive release.
The plugin now checks that PBJ CRM is not just installed but new enough, and says so with one notice instead of failing. It also asks for a slightly newer WordPress, because that is the version where WordPress began enforcing the CRM requirement at all. And if you remove the plugin while choosing to keep your data, its daily background job is now cleared out properly instead of being left pointing at something that is gone.
1.2.0
Internal only. PBJ Archive now declares its eight tables and two settings to PBJ CRM, so a future whole-suite backup includes them. The vault table is flagged as essential — without it, a restored backup’s encrypted values could never be read again — and the entry tables are flagged as needing their record numbers preserved, because those numbers are part of what the encryption checks. Nothing changes on screen, no data is touched, and there is no database change.
1.1.0
PBJ Archive now formally requires PBJ CRM, matching how it is sold: WordPress itself checks for the CRM, and if it is missing you get one plain message instead of a half-working plugin. Revealing a value now honours the “require an unlocked vault even to list records” setting. Signing out also clears your own vault session immediately rather than leaving it to time out. And filing a record from a business profile now offers the right sub-databases for a business.
1.0.0
First release. Sub-databases you design or build from a CSV (secret columns auto-detected); vault encryption (XChaCha20-Poly1305 / AES-256-GCM) under your passphrase with a one-time printed recovery code; reveal-on-click one field at a time with a full audit trail; per-type access levels plus per-record grants; records pinned to PBJ CRM companies, contacts and agents; a 31-point security self-test you can run yourself; plain-words fallback (and an upgrade path) for servers without the fast key-derivation extension.