init

2026-07-11 03:11:41 +02:00
parent 3734977e6e
commit 75bc9d2440
1 changed files with 533 additions and 0 deletions
@@ -0,0 +1,533 @@
 Oui. Si tu gardes les bitflags, je simplifierais tes modèles autour de cette règle :
 > Les permissions appartiennent aux **groupes** ou sont accordées directement à un **membre**, et chaque attribution
 > possède un périmètre.
 Je ne mettrais plus les permissions par défaut directement sur `server` et `channel`.
 ## 1. `user`
 Je garderais quasiment ton modèle actuel :
 ```plain text
 user
 ----
 id
 username
 password
 pub_key
 created_at
 updated_at
 is_superuser
 ```
 `is_superuser` reste un bypass global, indépendant des permissions d’un serveur.
 Je ne mettrais pas de permissions directement dans `user`, car les permissions doivent être contextuelles à un serveur.
 ## 2. `server`
 Je supprimerais :
 ```plain text
 default_server_permissions
 default_channel_permissions
 default_voice_permissions
 ```
 Le serveur ne devrait pas porter directement les permissions. Il possède plutôt des groupes.
 ```plain text
 server
 ------
 id
 name
 password
 created_at
 updated_at
 is_default
 ```
 Les permissions par défaut seraient celles du groupe système `Everyone`.
 ## 3. `server_user`
 Je garderais cette table pour l’appartenance d’un utilisateur à un serveur, mais je supprimerais probablement :
 ```plain text
 is_admin
 is_owner
 server_permissions
 channel_permissions
 voice_permissions
 ```
 Je remplacerais les statuts par des groupes :
 ```plain text
 server_user
 -----------
 id
 server_id
 user_id
 username
 joined_at
 updated_at
 ```
 Puis :
 ```plain text
 group_member
 ------------
 group_id
 user_id
 ```
 Par exemple :
 ```plain text
 Everyone
 Membre
 Modérateur
 Administrateur
 ```
 L’utilisateur propriétaire pourrait rester une exception structurelle :
 ```plain text
 server.owner_id
 ```
 ou être représenté par un groupe système très privilégié. Personnellement, je conserverais `owner_id` pour éviter qu’un
 propriétaire perde accidentellement ses droits.
 ## 4. `group`
 Ta table actuelle est déjà proche de ce qu’il faut :
 ```plain text
 group
 -----
 id
 server_id
 name
 is_default
 created_at
 updated_at
 ```
 Je garderais les trois bitmasks :
 ```plain text
 server_permissions
 channel_permissions
 voice_permissions
 ```
 Donc :
 ```rust
 pub struct Model {
    pub id: Uuid,
    pub server_id: Uuid,
    pub name: String,
    pub is_default: bool,
    pub server_permissions: i64,
    pub channel_permissions: i64,
    pub voice_permissions: i64,
    pub created_at: DateTimeUtc,
 }
 ```
 Chaque groupe est alors un rôle contenant un ensemble de permissions.
 Exemples :
 ```plain text
 Everyone :
  READ_CHANNEL
  SEND_MESSAGE
  JOIN_CHANNEL
  SPEAK
 Modérateur :
  DELETE_OTHERS_MESSAGES
  MANAGE_MESSAGES
  MUTE_OTHERS
 ```
 ## 5. `group_member`
 C’est ici que j’ajouterais le périmètre.
 Actuellement, un groupe est uniquement attribué à un utilisateur de manière globale au serveur :
 ```plain text
 group_id
 user_id
 ```
 Pour permettre à un modérateur d’agir seulement dans une catégorie ou un canal, il faut ajouter un scope.
 ### Option que je recommande
 ```plain text
 group_member
 ------------
 group_id
 user_id
 scope_type
 scope_id
 ```
 Exemples :
 ```plain text
 Modérateur -> Alice -> server   -> serveur A
 Modérateur -> Bob   -> category -> catégorie Support
 Modérateur -> Claire -> channel  -> canal Général
 ```
 Avec un enum :
 ```rust
 pub enum PermissionScopeType {
    Server,
    Category,
    Channel,
 }
 ```
 Le problème est que `scope_id` peut pointer vers plusieurs tables. Il faudra donc valider la cohérence côté application,
 ou utiliser trois colonnes nullable.
 ### Variante plus propre SQL
 ```plain text
 group_member
 ------------
 group_id
 user_id
 server_id
 category_id
 channel_id
 ```
 Avec la règle :
 ```plain text
 exactement une portée est définie
 ```
 Mais cette variante est plus lourde à manipuler.
 Pour un projet avec SeaORM, je choisirais probablement `scope_type + scope_id`, avec validation dans le service de
 permissions.
 ## 6. Permissions individuelles
 Tu as deux possibilités.
 ### Option simple : les stocker dans `server_user`
 Pour une permission individuelle valable sur tout le serveur :
 ```plain text
 server_user
 -----------
 server_permissions
 channel_permissions
 voice_permissions
 ```
 Cela permet :
 ```plain text
 Alice possède individuellement SEND_MESSAGE sur le serveur
 ```
 Mais cette solution ne permet pas facilement une permission individuelle limitée à une catégorie ou un canal.
 ### Option plus flexible : créer `user_permission_scope`
 Je recommande cette table :
 ```plain text
 user_permission
 ---------------
 id
 user_id
 server_id
 category_id nullable
 channel_id nullable
 server_permissions
 channel_permissions
 voice_permissions
 created_at
 ```
 Exemples :
 ```plain text
 Alice -> SEND_MESSAGE -> serveur A
 Bob   -> DELETE_OTHERS_MESSAGES -> catégorie Support
 Claire -> SEND_MESSAGE -> canal Général
 ```
 La colonne `server_id` est utile pour garantir que toutes les ressources appartiennent au bon serveur.
 ## 7. Que faire de `channel_user` ?
 Ta table actuelle contient :
 ```plain text
 channel_user
 ------------
 channel_id
 user_id
 role
 permissions
 ```
 Je ne garderais pas `role` et `permissions` sous cette forme si tu as déjà `group` et `group_member`.
 Je l’utiliserais uniquement pour représenter une relation particulière au canal, par exemple :
 ```plain text
 channel_user
 ------------
 id
 channel_id
 user_id
 joined_at
 ```
 Ou je la supprimerais complètement si l’accès au canal est déduit des permissions et de l’appartenance au serveur.
 Pour les permissions, je préfère `user_permission`, qui couvre déjà :
 - serveur ;
 - catégorie ;
 - canal.
 Sinon tu risques d’avoir trois systèmes concurrents :
 ```plain text
 server_user.permissions
 channel_user.permissions
 group.permissions
 ```
 et le calcul deviendra difficile à maintenir.
 ## 8. Que faire des permissions de `channel` ?
 Je supprimerais :
 ```plain text
 default_channel_permissions
 default_voice_permissions
 ```
 Le rôle par défaut `Everyone` du serveur les remplace.
 Si tu veux qu’un canal accorde des permissions supplémentaires, tu peux utiliser une table dédiée :
 ```plain text
 channel_permission_grant
 ------------------------
 channel_id
 group_id nullable
 user_id nullable
 server_permissions
 channel_permissions
 voice_permissions
 ```
 Mais je ne l’ajouterais pas immédiatement. Commence avec :
 ```plain text
 permissions serveur
 permissions de groupe
 permissions individuelles
 ```
 Puis ajoute les overrides de canal uniquement si le besoin apparaît réellement.
 ## Structure que je choisirais maintenant
 ```plain text
 user
 server
 category
 channel
 server_user
 group
 group_member
 user_permission
 ```
 ### `server_user`
 Appartenance au serveur :
 ```plain text
 user_id
 server_id
 joined_at
 ```
 ### `group`
 Permissions d’un rôle :
 ```plain text
 id
 server_id
 name
 is_default
 server_permissions
 channel_permissions
 voice_permissions
 ```
 ### `group_member`
 Attribution d’un rôle avec périmètre :
 ```plain text
 group_id
 user_id
 scope_type
 scope_id
 ```
 ### `user_permission`
 Permission individuelle avec périmètre :
 ```plain text
 id
 user_id
 server_id
 scope_type
 scope_id
 server_permissions
 channel_permissions
 voice_permissions
 ```
 ## Calcul des permissions
 Pour un utilisateur et un canal donné :
 ```plain text
 permissions effectives =
    permissions des groupes applicables
    | permissions individuelles applicables
 ```
 Les groupes applicables sont ceux dont le scope est :
 ```plain text
 serveur parent
 catégorie parente
 canal courant
 ```
 Exemple :
 ```plain text
 Alice
  Everyone sur le serveur
  Modérateur sur la catégorie Support
  permission individuelle sur le canal Général
 ```
 Dans un canal de `Support`, elle reçoit :
 ```plain text
 permissions Everyone
 | permissions Modérateur
 | permissions individuelles du canal
 ```
 ## Problème important avec `is_admin`
 Je supprimerais `is_admin` de `server_user`.
 Un administrateur devient simplement un groupe :
 ```plain text
 Administrateur
 ```
 avec les permissions correspondantes.
 En revanche, je garderais probablement :
 ```plain text
 server.owner_id
 ```
 car le propriétaire est une relation métier particulière, pas seulement un ensemble de permissions.
 ## À propos de `i64`
 Puisque tu stockes des valeurs `u64` dans des colonnes `i64`, je ferais au minimum une abstraction claire côté Rust :
 ```rust
 fn permissions_from_db(value: i64) -> u64 {
    value as u64
 }
 ```
 Et j’éviterais de disperser les conversions dans les modèles.
 Si tu ne comptes pas utiliser le bit de poids fort, tu peux aussi décider officiellement que seuls les 63 premiers bits
 sont valides.
 ## Recommandation finale
 Je modifierais ton système comme ceci :
 ```plain text
 Supprimer :
  permissions de server
  permissions de channel
  is_admin de server_user
  permissions de channel_user
  role texte de channel_user
 Garder :
  is_superuser sur user
  owner_id sur server
  trois bitflags sur group
 Ajouter :
  scope aux attributions de groupes
  table user_permission pour les permissions individuelles
 ```
 Le modèle deviendrait :
 ```plain text
 User
  ├── appartient à des serveurs
  ├── reçoit des groupes
  └── peut recevoir des permissions individuelles
 Group
  └── possède trois bitflags
 GroupMember
  └── associe un groupe à un utilisateur dans un scope
 UserPermission
  └── associe directement des bitflags à un utilisateur dans un scope
 ```
 C’est le compromis que je choisirais : **bitflags conservés, groupes réutilisables, permissions individuelles possibles,
 et modération limitée par scope**.