User access after you upgrade

What your users see

Your data is intact. What changed is who can read it.

Lists come back empty. Projects, connections, changelogs, and operations return nothing for someone with no grant, and the page renders its empty state rather than an error. Opening a link to a single project or connection returns a permission error instead.

That combination looks exactly like data loss, and it is the first thing an operator reports after upgrading. Nothing has been deleted. The upgrade assigns every existing project, connection, and changelog to the workspace’s Administrators group, so the records are waiting for the people you put in that group.

Who is affected

Everyone who used the deployment before the upgrade. Accounts carry over and people can still sign in, but an account that existed before the upgrade holds no permissions until an administrator places it in a group and grants that group a template.

Name an administrator before you upgrade

Set LIQUIBASE_PLATFORM_INITIAL_ADMIN_EMAIL in your .env to the address of an account that already exists, then upgrade. The server reads this setting every time it starts, so it promotes an account you already have rather than waiting for a new registration.

Two conditions decide whether the promotion happens.

• The address must be verified. Matching the setting proves someone typed the address, not that they own the mailbox. An unverified account stays without permissions until the person clicks the verification link, which promotes them straight away with no restart.

• The address must match exactly one account. If two accounts match, the server promotes neither and records the conflict in its log.

If you leave the setting empty, the next person to register becomes the workspace administrator and the door closes behind them. On a deployment that already has users, name the account instead of relying on that.

Grant your users their access back

Nothing carries a person’s previous visibility forward, so an administrator rebuilds it once. Group your users by the work they do, then grant each group a template that matches it.

• Manage groups creates the groups and adds people to them.

• Grant a group access with a template chooses a template and the projects or connections it applies to.

• Manage users and access describes what each template allows and how permissions resolve.

Work through your people in one pass after the upgrade rather than as the reports arrive. Someone who signs in before you reach them sees an empty application, which is correct and indistinguishable from a failure.