Vue d’ensemble de la gestion d’équipe
Comprenez comment fonctionne la gestion d’équipe dans CodeCourier, y compris la hiérarchie des projets, les rôles des membres, les fonctionnalités de collaboration et le contrôle d’accès.
CodeCourier est conçu pour la collaboration d’équipe. Chaque fonctionnalité de la plateforme - sandboxes, workflows, personas, issue sessions et learnings - est rattachée à un projet, et les projets prennent en charge plusieurs membres avec des rôles distincts. Cette section explique comment fonctionne le système de gestion d’équipe et comment l’utiliser efficacement.
Architecture centrée sur le projet
L’unité organisationnelle fondamentale dans CodeCourier est le projet. Un projet représente une base de code, un produit ou une initiative sur laquelle votre équipe travaille. Toutes les ressources - sandboxes, runs, workflows, personas, issue sessions, learnings, issues et clés API - appartiennent à un projet.
Chaque projet possède :
- Nom et slug - Un nom lisible par l’humain et un identifiant compatible avec les URL
- Propriétaire - L’utilisateur qui a créé le projet (a le contrôle total)
- Membres - Les autres utilisateurs ayant accès au projet
- Paramètres - Configuration des prompts système, des clés API, des variables d’environnement, et plus encore
- Dépôt GitHub facultatif - Un dépôt lié pour le déploiement de code et la gestion des PR
- Logo facultatif - Un logo de projet personnalisé téléversé vers le stockage
Les utilisateurs peuvent être membres de plusieurs projets simultanément. La plateforme suit le dernier projet actif de l’utilisateur et change de contexte automatiquement lorsqu’il navigue entre les projets.
Modèle utilisateur et organisation
CodeCourier utilise Clerk pour l’authentification. Lorsqu’un utilisateur s’inscrit ou se connecte, un enregistrement utilisateur correspondant est créé dans la base de données Convex avec son identifiant Clerk, son e-mail, son nom et son image de profil. L’enregistrement utilisateur est le point d’ancrage d’identité pour toutes les adhésions aux projets, les clés API et le suivi de l’activité.
Le modèle d’équipe est plat par conception - il n’y a pas d’organisations imbriquées ni de hiérarchies d’équipe. Chaque projet a une liste directe de membres, et chaque membre a un rôle qui détermine ses permissions. Cette simplicité garde le contrôle d’accès direct et prévisible.
Utilisateurs multi-projets
Cycle de vie d’un membre
Le cycle de vie d’un membre de projet suit ces étapes :
- Invitation - Un propriétaire ou un admin invite un utilisateur par adresse e-mail. L’adhésion est créée avec le statut « pending ».
- Acceptation - L’utilisateur invité voit l’invitation en attente dans son tableau de bord et l’accepte. Le statut passe à « accepted » et il obtient l’accès au projet.
- Adhésion active - Le membre peut accéder à toutes les ressources du projet selon son rôle (owner, admin ou member).
- Changements de rôle - Les propriétaires peuvent changer les rôles des membres. Les admins peuvent être promus propriétaires ou rétrogradés en membres.
- Suppression - Les propriétaires et les admins peuvent supprimer des membres. L’enregistrement d’adhésion est supprimé définitivement.
Les utilisateurs peuvent également refuser une invitation en attente, ce qui supprime l’enregistrement d’adhésion sans que l’utilisateur n’obtienne jamais l’accès au projet.
Fonctionnalités de collaboration
Lorsque plusieurs membres de l’équipe travaillent sur le même projet, ils bénéficient de plusieurs fonctionnalités de collaboration :
Ressources partagées
Toutes les ressources du projet sont partagées entre les membres. Les sandboxes, runs, workflows, personas et issue sessions créés par n’importe quel membre sont visibles par tous les membres. Cette transparence garantit que chacun peut voir l’activité et l’état du projet.
Mises à jour en temps réel
CodeCourier utilise le modèle de données réactif de Convex, ce qui signifie que toutes les données du projet se mettent à jour en temps réel sur tous les clients connectés. Lorsqu’un membre de l’équipe démarre un run de workflow, un autre membre voit le run apparaître immédiatement sans rafraîchir. Cela s’étend à toutes les entités : sandboxes, runs, issue sessions et learnings.
Système de notifications
Le système de notifications du projet alerte les membres de l’équipe sur les événements importants : achèvements de run, échecs de run, création de PR, fusions de PR, arrivées de membres et achèvements de workflow. Les notifications apparaissent dans la boîte de réception et suivent le statut lu/non lu par utilisateur.
Compteurs d’activité
Le projet maintient des compteurs dénormalisés qui offrent une visibilité rapide sur l’activité du projet : nombre total de sandboxes, sandboxes actives, nombre total de runs, runs terminés, runs échoués, nombre total de workflows, nombre total de membres et invitations en attente. Ces compteurs se mettent à jour en temps réel à mesure que l’état du projet change.
Modèle de contrôle d’accès
CodeCourier utilise un modèle de contrôle d’accès basé sur les rôles (RBAC) avec trois rôles : Owner, Admin et Member. Chaque point de terminaison d’API qui accède aux données d’un projet vérifie d’abord que l’utilisateur demandeur est un membre actif du projet. Certaines opérations nécessitent en plus des privilèges d’admin ou de propriétaire.
Le contrôle d’accès est appliqué au niveau des fonctions Convex à l’aide d’assistants d’authentification partagés (getProjectForMember, requireProjectAdmin, requireProjectOwner). Ces fonctions vérifient l’adhésion et le rôle de l’utilisateur avant d’autoriser l’opération à se poursuivre.
Membres en attente
isMemberOfProject rejette explicitement les adhésions en attente. Un utilisateur doit accepter l’invitation avant de pouvoir voir ou interagir avec les données du projet.