Ruoli e permessi

Pathrule nasce come strumento per una singola persona e cresce fino a diventare un prodotto per team. Quando inviti dei colleghi, la domanda diventa chi può vedere e modificare cosa. Questa pagina descrive i ruoli che assegni, come l'accesso si restringe dall'organizzazione al workspace e dove avviene davvero il controllo.

In breve: i ruoli si assegnano a livello di organizzazione, l'accesso può essere ristretto per singolo workspace e ogni lettura e scrittura su un workspace Pathrule Cloud viene verificata dal database rispetto all'utente con cui hai effettuato l'accesso. Lo stesso controllo vale sia che la richiesta arrivi dalla console web su app.pathrule.io, dalla Pathrule CLI, dall'estensione per VS Code o dal server MCP usato da un client IA.

Un workspace locale creato con --local non ha un account e risiede su una sola macchina, quindi i ruoli non si applicano finché non lo sposti nel cloud.

I quattro ruoli

I ruoli si assegnano a ogni persona a livello di organizzazione. Un owner o un admin invita un collega via email e sceglie il suo ruolo, Editor per impostazione predefinita; il collega accetta l'invito per unirsi. Puoi invitare da Members nella console web oppure dal terminale:

pathrule invite colleague@example.com --role viewer

Da qui derivano alcune tutele:

• Le modifiche alla proprietà richiedono l'autorità di un owner, e l'organizzazione deve sempre avere un owner.
• Le modifiche alla proprietà e ai membri vengono verificate sul server, compreso il requisito di mantenere un owner.

Le modifiche ai membri richiedono una sessione autorizzata valida. Le azioni più delicate di archiviazione ed eliminazione di un workspace richiedono in più un'autenticazione recente.

Postazioni e piani

Ogni persona nell'organizzazione occupa una postazione, qualunque sia il suo ruolo.

• Solo e Pro sono pensati per una sola persona. Non prevedono inviti; per lavorare con altri, passa a Team.
• Team è fatturato per postazione, con un minimo di due, owner incluso. Per invitare oltre le postazioni che paghi serve un'altra postazione; se le postazioni sono meno dei membri, tutti mantengono l'accesso e i nuovi inviti restano in attesa.
• Le postazioni Enterprise si concordano con il team vendite.

Postazioni e fatture si trovano in Billing nella console web; pathrule billing apre questa sezione dal terminale. Vedi Pathrule Web.

Accesso ai workspace: condiviso con l'organizzazione o privato

Il ruolo stabilisce cosa può fare una persona. La modalità di accesso di un workspace stabilisce chi può raggiungerlo. Ogni workspace si trova in una di due modalità.

• Condiviso con l'organizzazione. Ogni membro dell'organizzazione vi ha accesso, con il proprio ruolo nell'organizzazione.
• Privato. Vi ha accesso solo chi è stato aggiunto esplicitamente al workspace. Far parte dell'organizzazione non basta.

Owner e admin cambiano la modalità nelle impostazioni della console web, in Workspace, Access. Quando un workspace diventa privato, vi hanno accesso solo i membri aggiunti esplicitamente al workspace. Controlla e aggiungi le persone che ne hanno bisogno; l'appartenenza all'organizzazione da sola non concede più l'accesso. All'interno di un workspace privato, è il ruolo nel workspace a decidere cosa può fare una persona, quindi puoi dare a qualcuno un livello di accesso diverso da quello che ha altrove.

Perdere l'accesso non elimina nulla

Le modifiche ai permessi non distruggono mai il lavoro e solo di rado lo nascondono.

• Se perdi l'accesso in scrittura (per esempio, passi da Editor a Viewer) non scompare nulla. Puoi ancora leggere tutto quello che leggevi prima; le scritture fatte da te, o da un assistente che lavora per tuo conto, vengono rifiutate.
• Se perdi l'accesso a un workspace (vieni rimosso da un workspace privato o dall'organizzazione), solo allora i suoi contenuti spariscono dalla tua vista. I contenuti restano al team.

Lo stesso confine vale per l'assistente. Quando un client IA prova a scrivere dove un membro non può scrivere, la chiamata allo strumento MCP restituisce un chiaro esito di permesso negato, che l'assistente può riferirti in parole semplici, invece di fallire in silenzio o di sembrare riuscita. Il contesto che riceve un assistente, e i file di istruzioni che Pathrule scrive per lui, provengono sempre e solo dai workspace che quel membro può leggere.

Dove avviene il controllo

Niente di tutto questo viene imposto dall'applicazione che stai usando in quel momento. Ogni lettura e scrittura su un workspace Cloud passa da un controllo di accesso nel database, risolto in base all'utente con cui hai effettuato l'accesso, alla tua appartenenza all'organizzazione e alla modalità di accesso del workspace. I controlli di accesso fanno parte delle operazioni sul database eseguite dal server, non sono un pulsante nascosto nell'interfaccia.

• Un unico controllo per ogni superficie. La console web, la Pathrule CLI, l'estensione per VS Code, il server MCP locale e Remote MCP passano tutti dallo stesso controllo di accesso imposto dal database. Una modifica dal terminale e una scrittura da un client IA sono soggette alle stesse regole.
• Nessuna chiave di amministrazione condivisa. Ogni superficie usa un token per utente di breve durata, mai una chiave di servizio condivisa che potrebbe sbloccare i dati di un altro team. Un client compromesso può raggiungere solo ciò a cui quell'utente ha già accesso.
• Risoluzione lato server. I ruoli nell'organizzazione e nei workspace vengono risolti sul server, senza fidarsi di quanto dichiara il client, quindi una richiesta modificata non può concedersi un accesso che non le è stato dato.

Per il quadro completo di come viene protetto l'accesso al cloud, consulta la panoramica sulla sicurezza.

In modalità self-hosted

Enterprise self-hosted applica lo stesso modello di ruoli e permessi nel tuo account Cloudflare. I ruoli e le modalità di accesso ai workspace si comportano allo stesso modo; la differenza è che i dati e il database risiedono nel tuo account. Il single sign-on tramite il tuo identity provider viene configurato nell'ambito del contratto Enterprise e si collega agli stessi ruoli di organizzazione descritti qui. Vedi Enterprise self-hosted per capire come funziona quel tipo di deployment.