Cum funcționează permisiunile

Roluri, grupuri de permisiuni, niveluri admin și user, wildcards ALL - cum se leagă totul.

Fiecare echipă are o structură diferită. Unii colegi trebuie să vadă totul, alții doar ce le privește. Sistemul de permisiuni din Proiect.ro controlează exact cine ce poate face - fără ca cineva să primească prea mult acces sau prea puțin.

Acest articol explică logica din spatele sistemului: cum sunt organizate permisiunile, de ce există roluri, cum funcționează grupurile de permisiuni și ce înseamnă cuvântul ALL când îl vezi în lista de permisiuni. La final vei înțelege cum se leagă toate aceste piese între ele, astfel încât să poți lua decizii informate când configurezi accesul echipei tale.

Ce este o permisiune

O permisiune este cel mai mic element de control al accesului. Ea spune exact ce poate face un utilizator: să vadă o pagină, să creeze un element, să editeze o înregistrare sau să șteargă ceva.

Fiecare permisiune are un nume descriptiv (de exemplu „View Team Members" sau „Create Proposal") și un tip de operațiune: Create, Read, Update sau Delete. Aceste patru tipuri formează modelul CRUD - o convenție standard în industria software, nu ceva specific Proiect.ro.

Permisiunile sunt predefinite de sistem. Nu poți crea permisiuni noi, dar poți alege care permisiuni intră în fiecare rol. Acest lucru asigură consistența: toți utilizatorii, din toate spațiile de lucru, au acces la același set de acțiuni disponibile.

Formatul unei permisiuni

Fiecare permisiune are un format structurat, compus din segmente separate prin două puncte. Vei vedea acest format când adaugi permisiuni la un rol. Iată ce înseamnă fiecare parte:

De exemplu, permisiunea org:rbac:admin:role:add se citește astfel: „în spațiul de lucru (org), în zona de securitate (rbac), la nivel de configurare (admin), pentru obiectul rol (role), permite acțiunea de creare (add)."

Un alt exemplu: org:proposals:user:view înseamnă „în spațiul de lucru, în zona de vânzări, la nivel operațional, permite vizualizarea ofertelor." Observă că aici nu apare un obiect separat - permisiunea vizează direct funcționalitatea la nivel general.

Niveluri de acces: admin și user

Distincția dintre admin și user în structura permisiunilor reflectă o separare fundamentală: cine construiește sistemul și cine lucrează în el.

Permisiunile de nivel admin controlează configurarea: crearea rolurilor, definirea pâlniilor de vânzări, stabilirea tipurilor de elemente de lucru, configurarea cozilor de suport. Sunt acțiuni care se fac o dată (sau rar) și care afectează modul în care platforma funcționează pentru toată echipa.

Permisiunile de nivel user controlează utilizarea zilnică: crearea unei oferte, înregistrarea orelor lucrate, adăugarea unui tichet de suport, vizualizarea unui proiect. Sunt acțiunile pe care membrii echipei le fac în fiecare zi.

Grupuri de permisiuni

Platforma are zeci de permisiuni individuale. Pentru a le face ușor de navigat, ele sunt organizate în grupuri logice. Fiecare grup corespunde unei zone funcționale a platformei.

Grupurile de nivel admin includ, de exemplu: Team (gestionarea membrilor), RBAC (roluri și permisiuni), Sales Admin (configurarea pâlniei de vânzări), WBS (structura de livrare a proiectelor), Support Admin (configurarea suportului).

Grupurile de nivel user includ: Sales (crearea și gestionarea ofertelor), Projects (lucrul pe proiecte), Support (gestionarea tichetelor), Organizations (gestionarea clienților).

Grupurile sunt create de sistem și nu pot fi modificate. Rolul lor este strict organizatoric: te ajută să găsești rapid permisiunea de care ai nevoie, fără să parcurgi o listă lungă nesortată. Când adaugi o permisiune la un rol, vei vedea grupul din care face parte, ceea ce face selecția mult mai intuitivă.

Ce este un rol și de ce există

Imaginează-ți că ai 15 colegi și fiecare trebuie să aibă acces la proiecte, ore lucrate și rapoarte. Fără roluri, ai configura 15 seturi individuale de permisiuni. Dacă mâine adaugi o funcționalitate nouă, ai actualiza câte 15 configurații. Rolurile rezolvă exact această problemă.

Un rol este un pachet de permisiuni cu un nume descriptiv. Creezi rolul o singură dată, îi adaugi permisiunile necesare, apoi îl atribui oricui are nevoie de acel nivel de acces. Dacă mai târziu vrei să adaugi o permisiune nouă, o adaugi la rol - și toți membrii atribuiți o primesc automat.

Fiecare rol aparține spațiului tău de lucru. Poți crea oricâte roluri ai nevoie, le poți numi cum dorești și le poți activa sau dezactiva. Rolurile dezactivate păstrează configurația, dar nu mai acordă permisiuni membrilor asociați.

Cum se cumulează permisiunile

Un membru al echipei poate avea mai multe roluri în același timp. Permisiunile din toate rolurile se cumulează - nu se exclud reciproc.

Dacă Ana are rolul „Manager Vânzări" (care include permisiuni de vânzări) și rolul „Coordonator Suport" (care include permisiuni de suport), ea primește accesul combinat din ambele roluri. Nu trebuie să alegi între ele - se adaugă.

Același principiu funcționează și invers: dacă retragi un rol de la un membru, acesta pierde doar permisiunile din rolul respectiv. Permisiunile din celelalte roluri rămân neschimbate.

Rolul „Manager Vânzări"          Rolul „Coordonator Suport"
  - Creare oferte                  - Vizualizare tichete
  - Editare oferte                 - Creare tichete interne
  - Vizualizare clienți            - Atribuire tichete
  - Configurare pâlnii            - Transfer între cozi

           Ana primește TOATE cele 8 permisiuni

Acest model de cumulare înseamnă că nu există conflicte de permisiuni. Sistemul nu are permisiuni negative (interzicerea explicită a unei acțiuni). Dacă vrei ca cineva să nu aibă acces la o funcționalitate, pur și simplu nu incluzi acea permisiune în niciunul dintre rolurile atribuite.

Permisiuni de acces complet: ALL

Când un administrator are nevoie de acces complet la o zonă a platformei, adăugarea individuală a fiecărei permisiuni ar fi nepractică. Pentru această situație există permisiunile de tip ALL.

O permisiune care se termină cu ALL acordă automat acces la toate acțiunile din acel nivel. De exemplu:

• org:team:admin:ALL - acces complet la administrarea echipei (vizualizare, editare, invitare, excludere, plus toate sub-permisiunile)
• org:proposals:user:ALL - acces complet la utilizarea modulului de vânzări (vizualizare, creare, editare oferte, activități comerciale, etc.)
• org:support:admin:ALL - acces complet la configurarea suportului (tipuri, severități, statusuri, cozi)

ALL funcționează ierarhic. Dacă un membru are org:projects:user:ALL, aceasta acoperă automat permisiuni mai specifice precum org:projects:user:work:item:add sau org:projects:user:resource:usage:view. Sistemul verifică întreaga ierarhie de la permisiunea specifică în sus: dacă găsește un ALL la orice nivel superior, accesul este acordat.

org:ALL
  └── acoperă TOATE permisiunile din spațiul de lucru

org:projects:ALL
  └── acoperă org:projects:admin:... ȘI org:projects:user:...

org:projects:user:ALL
  └── acoperă org:projects:user:work:ALL
      └── acoperă org:projects:user:work:item:ALL
          └── acoperă org:projects:user:work:item:add
          └── acoperă org:projects:user:work:item:edit
          └── acoperă org:projects:user:work:item:delete

Cum decide sistemul ce ai voie să faci

De fiecare dată când accesezi o pagină sau execuți o acțiune, sistemul verifică automat dacă ai permisiunile necesare. Verificarea se face în fundal - nu trebuie să faci nimic manual.

Procesul de verificare funcționează în trei etape:

1. Colectarea permisiunilor - Sistemul preia toate rolurile atribuite ție în spațiul de lucru curent și adună toate permisiunile din acele roluri într-un set unic.
2. Verificarea cerinței - Fiecare pagină sau acțiune are definită o cerință de acces. Cerința poate fi o singură permisiune sau o combinație de permisiuni.
3. Decizia - Sistemul compară setul tău de permisiuni cu cerința paginii. Dacă cerința este îndeplinită, acțiunea este permisă. Dacă nu, primești un mesaj de acces interzis.

Verificarea cerințelor folosește două moduri:

• Oricare din (any_of) - Este suficient să ai cel puțin una din permisiunile listate. Se folosește pentru pagini care pot fi accesate de mai multe roluri diferite.
• Toate (all_of) - Trebuie să ai fiecare permisiune din listă. Se folosește pentru acțiuni care necesită combinarea mai multor competențe.

În practică, aceste verificări sunt invizibile când totul este configurat corect. Elementele de interfață (butoane, meniuri, secțiuni) care necesită permisiuni pe care nu le ai sunt ascunse automat. Nu vei vedea un buton pe care nu ai dreptul să-l apeși.

Imaginea de ansamblu

Toate conceptele descrise mai sus se leagă într-o ierarhie simplă:

┌─────────────────┐
│  Membru echipă  │   Ana, Mihai, Elena...
└────────┬────────┘
         │ primește unul sau mai multe
         ▼
┌─────────────────┐
│      Roluri     │   Manager Vânzări, Coordonator Suport...
└────────┬────────┘
         │ conțin
         ▼
┌─────────────────┐
│   Permisiuni    │   Creare oferte, Vizualizare proiecte...
└────────┬────────┘
         │ sunt organizate în
         ▼
┌─────────────────┐
│     Grupuri     │   Sales, Projects, Support, Team...
└─────────────────┘

Grupurile organizează permisiunile. Permisiunile intră în roluri. Rolurile se atribuie membrilor. Membrii cumulează permisiunile din toate rolurile lor. La fiecare acțiune, sistemul verifică automat dacă permisiunile cumulate acoperă cerința acelei acțiuni.

Această structură îți oferă flexibilitate maximă cu efort minim de administrare. Definești roluri o singură dată, le atribui membrilor, iar de restul se ocupă platforma.

Exemple practice de configurare

Iată trei scenarii tipice și cum ar arăta configurarea permisiunilor pentru fiecare:

Manager de proiect

Trebuie să vadă proiectele, să gestioneze echipa de livrare, să înregistreze progresul și să vizualizeze rapoarte. Rolul său ar conține:

• Permisiuni admin pentru proiecte - configurarea structurii WBS, a tipurilor de elemente de lucru
• Permisiuni user pentru proiecte - lucrul efectiv pe proiecte, sarcini, ore, resurse
• Permisiuni user pentru rapoarte - vizualizarea analizelor de livrare și financiare

Consultant (contribuitor individual)

Trebuie să-și vadă sarcinile, să înregistreze ore și să folosească suportul intern. Nu are nevoie de acces la configurare. Rolul său ar conține:

• Permisiuni user pentru proiecte - vizualizare sarcini, înregistrare ore, utilizare resurse
• Permisiuni user pentru suport - creare tichete interne

Director sau fondator

Are nevoie de acces complet. În loc să adaugi zeci de permisiuni individuale, folosești permisiuni ALL la nivel de funcționalitate:

• org:settings:admin:ALL - configurare completă a spațiului de lucru
• org:team:admin:ALL - gestionarea completă a echipei
• org:rbac:admin:ALL - gestionarea rolurilor și permisiunilor
• org:proposals:user:ALL - acces complet la vânzări
• org:projects:user:ALL - acces complet la proiecte

Aceste cinci permisiuni ALL înlocuiesc câteva zeci de permisiuni individuale, păstrând același nivel de acces.

Principii de bună practică

Sistemul de permisiuni este flexibil, dar câteva principii te ajută să-l folosești eficient:

• Privilegiul minim - Acordă fiecărui membru doar permisiunile de care are nevoie efectiv. Este mai ușor să adaugi o permisiune mai târziu decât să descoperi că cineva a avut acces la ceva ce nu trebuia.
• Roluri pe funcții, nu pe persoane - Numește rolurile după funcția pe care o îndeplinesc („Manager Proiecte"), nu după persoana care le folosește („Rolul lui Andrei"). Când Andrei pleacă, rolul rămâne și poate fi atribuit succesorului său.
• Mai puține roluri, mai bine definite - Trei sau patru roluri bine gândite sunt mai ușor de administrat decât zece roluri cu suprapuneri. Folosește cumularea permisiunilor: dacă cineva are nevoie de acces la vânzări și proiecte, atribuie-i ambele roluri.
• Revizuire periodică - Pe măsură ce echipa crește sau se reorganizează, verifică dacă rolurile existente mai reflectă realitatea. Dezactivează rolurile care nu mai sunt necesare.