Groupes techniques

group_scoped_permissions étend le catalogue effectif d'un groupe pour les ressources d'un bâtiment, sans mélanger permissions GROUP_* et ADMIN_*. Voir Architecture technique de l'immobilier.

GROUP_PERMISSIONS contient les trois droits véhicule. character_group_permissions reste le point de résolution ; les services véhicules vérifient ensuite séparément la clé physique. La suppression d’un groupe utilise une garde sur registered_vehicles.owner_group_id.

La migration 0023_character_groups crée groups, group_ranks, group_rank_permissions, group_members et group_invitations. Les appartenances référencent characters, jamais le compte global. Une clé composite empêche un doublon dans un même groupe sans limiter les appartenances à d'autres groupes.

api/app/services/groups.py est l'autorité des permissions. Les permissions effectives sont l'union des permissions directes des rangs de niveau inférieur ou égal ; le rang propriétaire 1_000_000 reçoit toujours GROUP_PERMISSIONS. Chaque mutation recharge le groupe, vérifie l'appartenance, la permission et la relation de rang avant d'écrire. Le transfert de propriété échange atomiquement le propriétaire vers le rang maximal et rétrograde l'ancien propriétaire au plus haut rang ordinaire.

Les routes /internal/v1/groups servent la ressource FiveM. medusa-groups remplace toujours le character_id reçu de la NUI par celui résolu via medusa-player-utils. Pour une invitation, le serveur compare les coordonnées des deux peds et transmet l'UUID du personnage cible seulement après validation. Les invitations expirent en base après 60 secondes et sont supprimées lors de la lecture ou de la réponse.

La NUI dédiée appartient exclusivement à medusa-groups, s'ouvre avec la commande groups liée à F3 et communique par callbacks NUI. Elle applique les règles AR/VR communes et utilise des dialogues internes, jamais alert, prompt ou confirm.

Son shell CSS reproduit la grille fonctionnelle de medusa-admin sans dépendance de styles entre ressources : dimensions maximales 1240 × 790 px, header de 82 px, rail de 220 px, sous-navigation de 56 px et workspace autonome. La liste dynamique des groupes vit dans le rail persistant tandis que les vues groupes/invitations occupent la même cellule de workspace. La classe active de la carte sélectionnée est recalculée à chaque rendu.

Les routes web /admin/groups utilisent OAuth, CSRF et les permissions admin. Les routes internes /internal/v1/group-admin recalculent ces mêmes permissions depuis les rôles Discord pour le panneau F10. Les actions web sont auditables par le middleware admin ; les actions F10 produisent des audits explicites via medusa-admin.