Feature: Implement Seamless Account Switching #111

New issue

Closed

opened 2025-10-13 20:18:56 +00:00 by rwachters · 0 comments

rwachters commented

2025-10-13 20:18:56 +00:00

(Migrated from github.com)

Feature: Implement Seamless Account Switching

Issue Type: Feature Request
Priority: High
Labels: feature, authentication, storage, ui/ux, refactoring

Executive Summary

This issue outlines the work required to implement seamless account switching functionality, allowing users to switch between multiple accounts without logging out. This feature necessitates significant architectural changes across the storage layer, authentication system, and UI components.

User Story Reference

NF.S20 - Switch Between User Accounts

Description: As a user, I want to be able to switch between my personal account and any other accounts I have access to (for instance, an admin account), without logging out, so I can easily switch between different personas or roles within the application.
Estimate: L (Large)

Acceptance Criteria

A "Switch Account" button or similar UI element is available.
Clicking the "Switch Account" button displays a list of available accounts.
Selecting an account does not log out the current user but simply switches the active account context.

Current Architecture Highlights

The current system is designed for a single active user session. This means:

Token Storage: Stores a single set of authentication data (dek.json, tokens.enc) without support for multiple concurrent user sessions.
Authentication Repository: Manages a single authentication state via StateFlow<AuthState>.
UI Layer: The UserMenu component only provides a "Logout" option.

Implementation Plan

The implementation will be broken down into the following phases:

Phase 1: Foundation (Storage Layer)

Priority: Critical
Files: app/src/commonMain/kotlin/eu/torvian/chatbot/app/service/auth/TokenStorage.kt, app/src/commonMain/kotlin/eu/torvian/chatbot/app/service/auth/FileSystemTokenStorage.kt
Description: Enhance the TokenStorage interface and refactor FileSystemTokenStorage to support multiple accounts, including a new directory structure ({baseUserDataStoragePath}/accounts/{userId}/), an account_index.json file, and migration logic for existing users.
Estimated Effort: 5-7 days

Phase 2: Repository Layer

Priority: Critical
Files: app/src/commonMain/kotlin/eu/torvian/chatbot/app/repository/AuthRepository.kt, app/src/commonMain/kotlin/eu/torvian/chatbot/app/repository/impl/DefaultAuthRepository.kt
Description: Add methods to AuthRepository for getting available accounts and switching between them. Update DefaultAuthRepository to implement this logic, including updating the _authState and modifying logout behavior.
Estimated Effort: 3-4 days

Phase 3: ViewModel Layer

Priority: High
Files: app/src/commonMain/kotlin/eu/torvian/chatbot/app/viewmodel/auth/AuthViewModel.kt
Description: Enhance AuthViewModel to manage and expose available accounts, and provide methods for switching and removing accounts. Load available accounts on initialization.
Estimated Effort: 2-3 days

Phase 4: UI Components

Priority: High
Files: app/src/commonMain/kotlin/eu/torvian/chatbot/app/compose/MainApplicationFlow.kt, new AccountSwitcherDialog.kt
Description: Update the UserMenu in MainApplicationFlow to include a "Switch Account" option. Create a new AccountSwitcherDialog component to display and manage available accounts. Integrate the dialog into the main application flow.
Estimated Effort: 2-3 days

Phase 5: Data Isolation

Priority: High
Files: Various ViewModels, EventBus
Description: Implement mechanisms to ensure proper data isolation between accounts. This includes adding an AccountSwitchedEvent to the EventBus and updating relevant ViewModels (e.g., SessionListViewModel, ChatViewModel) to clear cached data and reload information when an account switch occurs.
Estimated Effort: 2-3 days

Phase 6: Testing & Polish

Priority: Medium
Description: Comprehensive unit, integration, and UI testing for all new and modified components. This includes testing data migration, token management, data isolation, and UI interactions.
Estimated Effort: 4-5 days

Risks and Challenges

High Risk:
- Data Migration: Ensuring seamless migration of existing user data to the new storage format.
- Token Management: Correctly handling token expiration and refresh for inactive accounts.
- Data Isolation: Preventing any data leakage or cross-contamination between accounts.
- State Management: Managing complex state transitions during account switching.
Medium Risk:
- Performance: Potential impact of loading multiple account credentials.
- UI/UX: Clear indication of the active account and intuitive switching experience.
- Error Handling: Robust error handling for new failure modes.

Recommended Testing Strategy

Unit Tests: For FileSystemTokenStorage (multi-account storage, migration, index management) and DefaultAuthRepository (account management, switching, logout).
Integration Tests: Full authentication flow with multiple accounts, verifying data isolation after switching, and handling login/logout scenarios.
UI Tests: Account switcher dialog display, UI updates on account switch, adding/removing accounts.

Additional Recommendations

Consider implementing a maximum number of stored accounts.
Display "last used" timestamps in the account switcher.
Allow users to add custom labels/nicknames to accounts.
Add a visual indicator in the top bar showing the current active account.

Total Estimated Effort

17-24 days (3-4 weeks)

### Feature: Implement Seamless Account Switching **Issue Type:** Feature Request **Priority:** High **Labels:** `feature`, `authentication`, `storage`, `ui/ux`, `refactoring` --- ### Executive Summary This issue outlines the work required to implement seamless account switching functionality, allowing users to switch between multiple accounts without logging out. This feature necessitates significant architectural changes across the storage layer, authentication system, and UI components. ### User Story Reference **NF.S20 - Switch Between User Accounts** - **Description:** As a user, I want to be able to switch between my personal account and any other accounts I have access to (for instance, an admin account), without logging out, so I can easily switch between different personas or roles within the application. - **Estimate:** L (Large) ### Acceptance Criteria * A "Switch Account" button or similar UI element is available. * Clicking the "Switch Account" button displays a list of available accounts. * Selecting an account does not log out the current user but simply switches the active account context. ### Current Architecture Highlights The current system is designed for a single active user session. This means: * **Token Storage:** Stores a single set of authentication data (`dek.json`, `tokens.enc`) without support for multiple concurrent user sessions. * **Authentication Repository:** Manages a single authentication state via `StateFlow<AuthState>`. * **UI Layer:** The [UserMenu](psi_element://eu.torvian.chatbot.app.compose.MainApplicationFlow#UserMenu) component only provides a "Logout" option. ### Implementation Plan The implementation will be broken down into the following phases: #### Phase 1: Foundation (Storage Layer) * **Priority:** Critical * **Files:** `app/src/commonMain/kotlin/eu/torvian/chatbot/app/service/auth/TokenStorage.kt`, `app/src/commonMain/kotlin/eu/torvian/chatbot/app/service/auth/FileSystemTokenStorage.kt` * **Description:** Enhance the `TokenStorage` interface and refactor `FileSystemTokenStorage` to support multiple accounts, including a new directory structure (`{baseUserDataStoragePath}/accounts/{userId}/`), an `account_index.json` file, and migration logic for existing users. * **Estimated Effort:** 5-7 days #### Phase 2: Repository Layer * **Priority:** Critical * **Files:** `app/src/commonMain/kotlin/eu/torvian/chatbot/app/repository/AuthRepository.kt`, `app/src/commonMain/kotlin/eu/torvian/chatbot/app/repository/impl/DefaultAuthRepository.kt` * **Description:** Add methods to `AuthRepository` for getting available accounts and switching between them. Update `DefaultAuthRepository` to implement this logic, including updating the `_authState` and modifying logout behavior. * **Estimated Effort:** 3-4 days #### Phase 3: ViewModel Layer * **Priority:** High * **Files:** `app/src/commonMain/kotlin/eu/torvian/chatbot/app/viewmodel/auth/AuthViewModel.kt` * **Description:** Enhance `AuthViewModel` to manage and expose available accounts, and provide methods for switching and removing accounts. Load available accounts on initialization. * **Estimated Effort:** 2-3 days #### Phase 4: UI Components * **Priority:** High * **Files:** `app/src/commonMain/kotlin/eu/torvian/chatbot/app/compose/MainApplicationFlow.kt`, new `AccountSwitcherDialog.kt` * **Description:** Update the `UserMenu` in `MainApplicationFlow` to include a "Switch Account" option. Create a new `AccountSwitcherDialog` component to display and manage available accounts. Integrate the dialog into the main application flow. * **Estimated Effort:** 2-3 days #### Phase 5: Data Isolation * **Priority:** High * **Files:** Various ViewModels, EventBus * **Description:** Implement mechanisms to ensure proper data isolation between accounts. This includes adding an `AccountSwitchedEvent` to the `EventBus` and updating relevant ViewModels (e.g., `SessionListViewModel`, `ChatViewModel`) to clear cached data and reload information when an account switch occurs. * **Estimated Effort:** 2-3 days #### Phase 6: Testing & Polish * **Priority:** Medium * **Description:** Comprehensive unit, integration, and UI testing for all new and modified components. This includes testing data migration, token management, data isolation, and UI interactions. * **Estimated Effort:** 4-5 days ### Risks and Challenges * **High Risk:** * **Data Migration:** Ensuring seamless migration of existing user data to the new storage format. * **Token Management:** Correctly handling token expiration and refresh for inactive accounts. * **Data Isolation:** Preventing any data leakage or cross-contamination between accounts. * **State Management:** Managing complex state transitions during account switching. * **Medium Risk:** * **Performance:** Potential impact of loading multiple account credentials. * **UI/UX:** Clear indication of the active account and intuitive switching experience. * **Error Handling:** Robust error handling for new failure modes. ### Recommended Testing Strategy * **Unit Tests:** For `FileSystemTokenStorage` (multi-account storage, migration, index management) and `DefaultAuthRepository` (account management, switching, logout). * **Integration Tests:** Full authentication flow with multiple accounts, verifying data isolation after switching, and handling login/logout scenarios. * **UI Tests:** Account switcher dialog display, UI updates on account switch, adding/removing accounts. ### Additional Recommendations * Consider implementing a maximum number of stored accounts. * Display "last used" timestamps in the account switcher. * Allow users to add custom labels/nicknames to accounts. * Add a visual indicator in the top bar showing the current active account. ### Total Estimated Effort **17-24 days (3-4 weeks)**