Consistent User Management UI Across Open Food Facts Tools

[teolemon]

Consistent User Management UI Across Open Food Facts Tools

Goal: provide a consistent user interface (UI) and user experience (UX) for getting a “Road to KeyCloak” and managing App-specific user settings across various Open Food Facts platforms (Website with Foundation, Flutter App, React Tools like Hunger Games, Open Prices, openfoodfacts-explorer), like favorite stores, currency, dev mode settings for off-explorer…

It should try to leverage our Web Component strategy and assumes Keycloak is the central Identity Provider.

Core Principles:

1. Centralized Identity & Core Data: Keycloak is the source of truth for authentication, authorization, and core identity attributes (email, password management, sessions).
2. Centralized Extended Profile & Settings API: A dedicated Open Food Facts backend API service manages user profile data beyond core identity (e.g., contribution stats, general preferences) and tool-specific settings (e.g., Open Prices currency, favorite stores). This API interacts with Keycloak and Specific tools or backends where necessary.
3. Web Component Library for Web UIs: A library of customizable Lit Web Components provides the standard UI elements for user management on all web platforms (eg Account switcher, access to the page or modal containing app specific settings).
4. Shared Design System: A well-defined design system dictates the visual appearance and interaction patterns, ensuring consistency even for native implementations (Flutter).
5. Consistent Customization: Tool-specific settings are managed by the tools themselves but integrated visually within the structure provided by the core components.

Implementation Details:

1. Backend User Profile API:
   • Responsibilities: CRUD operations for extended OFF profile data and tool-specific settings (stored appropriately, perhaps namespaced by tool). Potentially provides a endpoint for fetching combined user data (core from Keycloak + extended from the tool). Consistency across tools.
2. openfoodfacts-webcomponents (Lit Library):
   • Components: Create components like:
     • <off-profile-switcher>: Shows user icon/switcher/logout for navigation bar. Inputs: link to keycloak, link to local settings, user id (to get user photo and user name)
     • <off-settings-layout>: A container component providing consistent structure/navigation for settings pages.
     • (Other components ? Avoid stepping on KeyCloak)
   • Customization via Slots: The key to tool-specific settings.

     • Example: <off-settings-layout> could have a designated <slot name="tool-specific"></slot>.

     • Open Prices (whether built in React or using Lit itself) would then render its own settings component (e.g., <openprices-preferences>) inside that slot:
       <off-settings-layout>
       <off-profile-form slot="general"></off-profile-form>
       <off-account-security slot="security"></off-account-security>
       <openprices-preferences slot="tool-specific"></openprices-preferences>
       </off-settings-layout>

     • The openprices-preferences component is responsible for its own UI and for interacting with the Backend User Profile API to save its specific settings (currency, stores).

3. Platform Integration:
   • Web Tools: Web component
   • Flutter App:
     • Native Implementation: Build the non keycloak user management screens natively in Flutter. Crucially, this native UI must strictly adhere to the Shared Design System. It interacts directly with the Backend User Profile API. Tool-specific settings needed in the app are also built natively.
     • Question of the keycloak part, the webview solution is kind of disappointing
4. Shared Design System