[Epic] Refactor community and channel permissions data transformation

[alexjba]

In a nutshell

Provide data models as they are received from status-go and move the transformation to the QML layer. Add a new API to fetch permissions data for an arbitrary account selection, with the lifetime of this data controlled by QML and synced with backend events.

Description

Overview

The current permissions model was initially designed to support a specific UI component aimed at displaying permission holdings criteria and verifying if these criteria are met by user account holdings. However, the tokenised communities UI has grown more complex, and the existing model structure no longer fits our needs. This epic focuses on refactoring the permissions model to accommodate new use cases and improve data handling and presentation.

Current Issue

The existing model only supports a specific use-case: verifying if user account holdings meet the criteria set by admins, using two RPCs (checkAllChannelsPermissions and checkPermissionsToJoin) to get the satisfied flag. However, this structure drops valuable data at the nim layer, which must be re-assembled at the UI layer, leading to inefficiencies and limitations.

Objectives

The primary goals are to support new use cases efficiently, provide the UI with correctly structured data, synchronize data between the nim and UI layers, and improve the model’s maintainability and scalability.

New Use Cases (difficult to adapt to current model structure)

The existing RPCs already provide the necessary data structured precisely for each new use case, but the current model fails to utilize this structured data effectively:

Member Role Determination: The checkPermissionsToJoin RPC provides the overall satisfied status and the highest role directly. This information is crucial for the join community flows, but the current model does not leverage this structured data.

Channel Permissions: The checkAllChannelsPermissions RPC returns data grouped by channels, exactly as needed for determining channel permissions. This is essential for join community flows and other chat functionalities. However, the current model discards this structured data, requiring unnecessary reassembly in the UI layer.

Holdings Criteria Display: Both checkPermissionsToJoin and checkAllChannelsPermissions RPCs return data grouped by role, with the token requirements provided. This structure is ideal for displaying all holdings criteria per role/channel permission in the join community flows. Unfortunately, the current model does not retain this organization, necessitating additional processing in the UI.

Data Scenarios:

The main difference in the data scenarios is the account selection used to compute the models and the models lifetime. These are the two models we currently have.
Chat Section Model: Requires live data synced with holdings from shared addresses for determining channel permissions and initial join request permissions. This model lives as long as the chat section and it's correct. But the UI fails to maintain the synchronisation effectively for some of the new use cases described above.
Community Model: Needs data requested on demand in the UI with arbitrary wallet account selection. This can be generated by using a different account selection as the Chat Section Model. The current implementation in the communities module is inadequate, as it can be overridden by another community’s info and is wrongly synchronised with the chat section permissions model (with a different account selection).

Proposal

To address these needs, the proposal is to change the current architecture based on the agreements made at the offsite meeting (https://miro.com/app/board/uXjVKS3chcc=/). The steps are as follows:

• Nim API for on demand permission models: Create an API that provides permissions data for any account selection. This model’s lifetime needs to be bounded to the UI components that display its information and should be updated by external events. The current implementation in the communities module does not meet these requirements, as it can be overridden by another community’s info and is wrongly synchronized with the chat section permissions model. Implementing a UI data subscription mechanism could be an option.
  Regression risk: high

• Data Simplification: Provide simple, untransformed data to the UI from the nim layer. This applies to both the chat section model and the community model and should support the same APIs created in step 1. The data can be requested from the same API defined at step 1 for both Data Scenarios - for the shared accounts or for an arbitrary account selection.
  Regression risk: low (this model will work in parallel with the current one and won't be connected in the UI)

• UI Adapters: Develop UI adapters to handle all the identified UI use cases. These adapters will integrate the permissions data seamlessly into the UI components. The UI Adapters will consume the data provided by the Data Simplification step and will output the data in a format ready to be consumed by UI components.
  Regression risk: low (the adapters won't be hooked yet)

• UI Integration: Remove existing UI logic that manages permissions data and integrate the new UI adapters.
  Regression risk: high

• Nim Code Cleanup: Remove unnecessary transformations in the nim layer to optimize performance and maintainability.
  Regression risk: high

Tasks

• [Community permissions] Create a detailed model transformation design #14809

[alexjba]

cc @noeliaSD @jrainville