From cf1e483c7fa4c3ea16d1981eb833e286f034806d Mon Sep 17 00:00:00 2001 From: Addison Beck Date: Thu, 20 Jan 2022 14:00:58 -0500 Subject: [PATCH] [bug] Account for entityId as a userId alternative during state migration (#622) Some clients, like Directory Connector, use different key for their user identifier: entityId We currently only check for userId in the migration service, but need to account for both. --- common/src/services/stateMigration.service.ts | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/common/src/services/stateMigration.service.ts b/common/src/services/stateMigration.service.ts index ab19af05c02..ddc191aeda3 100644 --- a/common/src/services/stateMigration.service.ts +++ b/common/src/services/stateMigration.service.ts @@ -193,7 +193,8 @@ export class StateMigrationService { alwaysShowDock: await this.get(v1Keys.alwaysShowDock), }; - const userId = await this.get(v1Keys.userId); + const userId = + (await this.get(v1Keys.userId)) ?? (await this.get(v1Keys.entityId)); // (userId == null) = no logged in user (so no known userId) and we need to temporarily store account specific settings in state to migrate on first auth // (userId != null) = we have a currently authed user (so known userId) with encrypted data and other key settings we can move, no need to temporarily store account settings