Panoramica della gestione del team
Scopri come funziona la gestione del team in CodeCourier, inclusi la gerarchia dei progetti, i ruoli dei membri, le funzionalità di collaborazione e il controllo degli accessi.
CodeCourier è costruito per la collaborazione di team. Ogni funzionalità della piattaforma - sandbox, workflow, personas, issue session e learning - è vincolata a un progetto, e i progetti supportano più membri con ruoli distinti. Questa sezione spiega come funziona il sistema di gestione del team e come usarlo in modo efficace.
Architettura incentrata sul progetto
L’unità organizzativa fondamentale in CodeCourier è il progetto. Un progetto rappresenta un codebase, un prodotto o un’iniziativa su cui il tuo team sta lavorando. Tutte le risorse - sandbox, run, workflow, personas, issue session, learning, issue e chiavi API - appartengono a un progetto.
Ogni progetto ha:
- Nome e slug - Un nome leggibile dall’uomo e un identificatore compatibile con gli URL
- Proprietario - L’utente che ha creato il progetto (ha il controllo completo)
- Membri - Altri utenti con accesso al progetto
- Impostazioni - Configurazione per prompt di sistema, chiavi API, variabili d’ambiente e altro
- Repository GitHub facoltativo - Un repository collegato per il deploy del codice e la gestione delle PR
- Logo facoltativo - Un logo di progetto personalizzato caricato nell’archivio
Gli utenti possono essere membri di più progetti contemporaneamente. La piattaforma traccia l’ultimo progetto attivo dell’utente e cambia contesto automaticamente quando naviga tra i progetti.
Modello utente e organizzazione
CodeCourier usa Clerk per l’autenticazione. Quando un utente si registra o accede, viene creato un record utente corrispondente nel database Convex con il suo ID Clerk, l’email, il nome e l’immagine del profilo. Il record utente è il punto di ancoraggio dell’identità per tutte le appartenenze ai progetti, le chiavi API e il tracciamento dell’attività.
Il modello del team è piatto per progettazione - non ci sono organizzazioni annidate né gerarchie di team. Ogni progetto ha un elenco diretto di membri, e ogni membro ha un ruolo che determina i suoi permessi. Questa semplicità mantiene il controllo degli accessi diretto e prevedibile.
Utenti multi-progetto
Ciclo di vita di un membro
Il ciclo di vita di un membro del progetto segue queste fasi:
- Invito - Un proprietario o un admin invita un utente tramite indirizzo email. L’appartenenza viene creata con stato « pending ».
- Accettazione - L’utente invitato vede l’invito in sospeso nella sua dashboard e lo accetta. Lo stato passa a « accepted » e ottiene l’accesso al progetto.
- Appartenenza attiva - Il membro può accedere a tutte le risorse del progetto in base al suo ruolo (owner, admin o member).
- Cambi di ruolo - I proprietari possono cambiare i ruoli dei membri. Gli admin possono essere promossi a proprietari o retrocessi a membri.
- Rimozione - Proprietari e admin possono rimuovere i membri. Il record di appartenenza viene eliminato definitivamente.
Gli utenti possono anche rifiutare un invito in sospeso, il che elimina il record di appartenenza senza che l’utente ottenga mai l’accesso al progetto.
Funzionalità di collaborazione
Quando più membri del team lavorano sullo stesso progetto, beneficiano di diverse funzionalità di collaborazione:
Risorse condivise
Tutte le risorse del progetto sono condivise tra i membri. Sandbox, run, workflow, personas e issue session creati da qualsiasi membro sono visibili a tutti i membri. Questa trasparenza garantisce che tutti possano vedere l’attività e lo stato del progetto.
Aggiornamenti in tempo reale
CodeCourier usa il modello di dati reattivo di Convex, il che significa che tutti i dati del progetto si aggiornano in tempo reale su tutti i client connessi. Quando un membro del team avvia un run di workflow, un altro membro vede il run comparire immediatamente senza aggiornare. Questo si estende a tutte le entità: sandbox, run, issue session e learning.
Sistema di notifiche
Il sistema di notifiche del progetto avvisa i membri del team sugli eventi importanti: completamenti dei run, fallimenti dei run, creazione di PR, merge di PR, ingressi di membri e completamenti di workflow. Le notifiche compaiono nella casella di posta e tracciano lo stato letto/non letto per utente.
Contatori di attività
Il progetto mantiene contatori denormalizzati che offrono una visibilità rapida sull’attività del progetto: numero totale di sandbox, sandbox attive, numero totale di run, run completati, run falliti, numero totale di workflow, numero totale di membri e inviti in sospeso. Questi contatori si aggiornano in tempo reale man mano che lo stato del progetto cambia.
Modello di controllo degli accessi
CodeCourier usa un modello di controllo degli accessi basato sui ruoli (RBAC) con tre ruoli: Owner, Admin e Member. Ogni endpoint API che accede ai dati di un progetto verifica prima che l’utente richiedente sia un membro attivo del progetto. Alcune operazioni richiedono inoltre privilegi di admin o proprietario.
Il controllo degli accessi viene applicato a livello di funzione Convex usando helper di autenticazione condivisi (getProjectForMember, requireProjectAdmin, requireProjectOwner). Queste funzioni controllano l’appartenenza e il ruolo dell’utente prima di consentire il proseguimento dell’operazione.
Membri in sospeso
isMemberOfProject rifiuta esplicitamente le appartenenze in sospeso. Un utente deve accettare l’invito prima di poter vedere o interagire con i dati del progetto.