Issue #3594933: Redirect to the unlock form instead of white-screening a locked vault

Frank Mablyrequested to merge
issue/pdv-3594933:3594933-locked-vault-white-screens into 1.x

Fixes a white-screen (uncaught VaultLockedException) when an owner reaches a decrypt-on-build route on an idle-locked vault.

Problem

With a passphrase-protected vault that has idle-locked, a stale link (e.g. a file Edit left open before the unlock lapsed) or a direct URL reaches a route that decrypts on build (FileEditForm, RecordForm, the grant/trust item lists via VaultOptionsTrait, viewRecord) and throws an uncaught VaultLockedException. The overview hides those sections while locked, but these entry points do not.

Resolution

  • VaultLockedException carries the locked owner uid.
  • A new exception subscriber redirects the owner to their unlock form with a return_to back to the page, so they continue after unlocking. Scoped to the owner on an interactive HTML request; a consumer cross-site read or an API/JSON request is left for the normal handling.

Tests

VaultLockedRedirectTest: owner redirected to unlock (with return_to), non-owner not redirected, non-HTML request not redirected. phpcs + phpstan clean; passphrase/session suites still pass. Verified end-to-end: the locked Edit request returns 302 to the unlock form instead of a 500.

Merge request reports