Date personale
Ce date despre oameni ține platforma, cine le poate vedea, ce nu ajunge niciodată în jurnale și cum se scoate un om din evidențe.
Pe scurt
| Cine | Ce se ține | Cine vede |
|---|---|---|
| Conturile platformei | nume, email, ultima activitate, parola (doar ca hash) | membrii firmelor contului; hash-ul parolei nu îl citește nici aplicația |
| Angajații echipei | nume, specialitate, ora de venire, data angajării, tipul contractului, țara, anul nașterii, salariul net și brut, legături către contract și documente, poza | membrii firmei; salariile doar admin, patron, finante |
| Clienții de catering | numele, firma, telefonul, adresa de livrare; la abonați și valoarea lunară | doar admin |
| Clienții de fidelitate | numele, telefonul, data acordului și versiunea lui, acordul pentru oferte | dreptul fidelitate.citeste |
| Clienții firmei (B2B) | numele, CUI-ul, orașul | membrii firmei, după drepturi |
| Activitatea în platformă | ultima „bătaie” pe pagină, urmele de acțiuni ale contului | firma activă |
| Schimbările de parolă | contul, cine a schimbat, pe ce cale, când, IP-ul (fără hash) | nicio rută a API-ului nu le citește |
Cine vede ce
Izolarea pe firmă
Fiecare tabel cu firma_id are Row Level Security în mod FORCE: o interogare vede doar rândurile firmei active, indiferent ce cere. Asta se aplică angajaților, comenzilor de catering, clienților de fidelitate și clienților B2B (vezi Securitate).
Conturile nu aparțin unei singure firme: un cont se vede doar dacă are acces la firma activă, sau dacă e chiar contul tău.
Parola
Aplicația poate citi din tabelul conturilor doar id, nume, email, ultima_activitate și creat_la. Coloana cu hash-ul parolei nu îi este dată deloc.
Salariile
GET /v1/angajati întoarce lista oricărui membru al firmei, dar cheile salariuNet și salariuBrut apar doar pentru rolurile admin, patron și finante. Pentru restul, cheile lipsesc din răspuns (nu sunt goale, lipsesc). Cine încearcă să scrie un salariu fără acest drept primește 403 interzis_salarii.
Rolurile pe pagini
Restul se decide pe rol și pe drepturi (vezi Roluri și drepturi): comenzile de catering doar pentru admin, fidelitatea pe drepturile fidelitate.citeste și fidelitate.gestioneaza.
Ce nu ajunge în jurnale
Jurnalul serverului ascunde mereu, înlocuind cu [ascuns]:
| Ce | Unde |
|---|---|
câmpul secret | oriunde în obiectul scris, inclusiv în corpul cererii |
| cookie-ul | antetul Cookie |
| autorizarea | antetul Authorization |
Două căi poartă un cod secret chiar în adresă. În jurnal, codul e înlocuit cu [cod]:
/v1/invitatii/<cod>[/accepta] → /v1/invitatii/[cod]
/v1/fidelitate/card/<cod> → /v1/fidelitate/card/[cod]Pentru fiecare cerere, jurnalul scrie doar metoda, adresa (redactată), gazda și adresa IP. La o eroare neprevăzută scrie ruta (tiparul, fără valori), metoda, id-ul cererii și eroarea; niciodată corpul, cookie-ul, antetele sau query-ul.
Fără LOG=1, jurnalul scrie doar erorile; cererile obișnuite nu se scriu deloc. Redactarea se aplică oricum, oricare ar fi nivelul.
Scoaterea unui om
| Cine | Ce se poate face | Ce rămâne |
|---|---|---|
| Contul platformei | administratorul oprește accesul la firmă (PATCH /v1/acces/oameni/:id cu {"acces": false}) | contul; în API nu există o rută care șterge un cont |
| Poza de profil | omul o scoate (DELETE /v1/profil/poza) | fișierul se mută în arhivă, nu se șterge |
| Clientul de fidelitate | anonimizare: POST /v1/fidelitate/clienti/:id/sterge, cu dreptul fidelitate.gestioneaza | rândul rămâne cu numele Șters, telefonul gol, un cod de card nou și data ștergerii; punctele rămân ca registru |
| Comanda de catering | — | aplicația poate citi, adăuga și modifica, dar nu șterge |
POST /v1/fidelitate/clienti/7c1e.../sterge
→ 200 { "sters": true }A doua cerere pe același client întoarce 404: clientul e deja șters.
Acordul clientului de fidelitate
La înscriere, clientul bifează explicit acordul (acord: true, nimic altceva nu e acceptat). Acordul pentru mesaje cu oferte este o bifă separată și lipsa ei înseamnă „nu”. Se păstrează data acordului și versiunea textului acceptat. Cardul de fidelitate este un cod aleator, fără date personale în el.
Anonimizarea schimbă doar numele, telefonul și codul cardului. Date personale scrise în alte câmpuri (note, descrieri, etichete, în alte module) nu se șterg odată cu clientul.