Politică de acces

Politica de acces AI decide ce poate face poarta de acces în plus față de ACL-urile Odoo obișnuite. Aceasta poate doar să restrângă drepturile: dacă utilizatorul nu poate citi o înregistrare în Odoo, nici AI nu poate — chiar dacă o regulă spune Permite.

Meniuri:

  • AI ‣ Configurare ‣ Securitate ‣ Grupuri de acces

  • AI ‣ Configurare ‣ Securitate ‣ Reguli de acces

Concepte

Grup de acces AI

Un ai.access.group este un set de persoane cărora li se aplică regulile:

  • Membri — utilizatori expliciți (inclusiv utilizatori agent).

  • Grupuri Odoo asociate — toți membrii acelor grupuri sunt, de asemenea, membri.

  • Reguli — matricea de permisiuni/refuzuri pentru acest grup.

Folosiți grupuri precum AI – Sales readers, AI – Support agent bot, AI – No HR.

Regulă de acces AI

Un ai.access.rule vizează:

  • Grup de acces opțional (gol = regulă globală pentru toți utilizatorii AI);

  • Model (obligatoriu);

  • Câmp opțional (gol = regulă la nivel de model);

  • perm_read / perm_write / perm_create / perm_delete, fiecare ca Inherit, Allow sau Deny.

Crearea și ștergerea se aplică doar la nivel de model (ignorate la regulile pe câmp). Setarea valorilor câmpurilor la creare necesită totuși permisiune de scriere pe acele câmpuri, acolo unde politica o verifică.

Ordinea de rezolvare

Pentru un anumit utilizator, model, operațiune și câmp opțional, ai_can se rezolvă aproximativ astfel:

  1. Pragul de refuz absolut — modelele tehnice / de autoprotecție sunt întotdeauna refuzate, inclusiv orice model de platformă ai.* și mail.message / discuss.channel brute (consultați Securitate).

  2. Orice Refuz explicit, la nivel de câmp sau de model. Un Refuz la oricare dintre niveluri este absolut și nimic de mai jos nu îl poate anula.

  3. Permisiune la nivel de câmp (doar citire/scriere) — decide nivelul câmpului și are prioritate față de valoarea implicită globală pentru acel câmp. Acesta este mecanismul pe care se bazează regulile livrate și întreaga activare între modele: cu scrierea refuzată implicit, o permisiune pe câmp este ceea ce face un câmp scriptibil. Nu înlocuiește totuși nivelul modelului: o scriere directă într-un model trebuie să treacă în continuare de pasul 4 sau 6 pentru acel model. Doar o încărcătură imbricată într-un câmp one2many sau many2many al părintelui omite verificarea modelului pentru modelul copil.

  4. Permisiune la nivel de model — cea mai specifică permisiune are prioritate între grupuri.

  5. Modele cu permisiune exclusiv explicită — ir.attachment și mail.activity se opresc aici. Nu fac parte din pragul absolut, deci o regulă le poate deschide, dar nu trec niciodată la valorile implicite globale: fără o permisiune corespunzătoare sunt refuzate.

  6. Valori implicite globale din Setări (default_read / create / write / delete).

Modelele sau operațiunile necunoscute se închid implicit (fail closed). Rezultatele sunt memorate în cache și invalidate când se schimbă regulile, grupurile sau parametrii.

Protecții universale de igienizare (înainte de/alături de politică)

Independent de regulile de permisiune, poarta refuză sau elimină următoarele — cu o excepție, menționată în listă:

  • câmpuri magice;

  • nume de câmpuri cu aspect sensibil (password, token, api_key, …);

  • câmpuri care scriu într-un alt model — singura protecție pe care o poate ridica o regulă de permisiune, și numai per câmp; consultați Protecția scrierii între modele;

  • scrieri ale state din ciclul de viață;

  • tipuri nescriptibile / complexe care nu trebuie să fie controlate de LLM;

  • modele cu refuz absolut în căi relaționale / domenii.

Protecția scrierii între modele

Unele câmpuri Odoo nu stochează doar o valoare: scrierea lor scrie și într-un model diferit. crm.lead.email_from, de exemplu, actualizează adresa de e-mail a partenerului asociat. Fără protecție, un asistent căruia i s-a permis să „editeze lead-uri” ar putea modifica datele de contact în afara modelelor pe care le-ați deschis, iar jurnalul de audit ar menționa doar lead-ul.

Odoo are două tipuri de astfel de câmpuri și doar unul dintre ele poate fi deschis.

Un câmp related redirecționează, prin definiție, scrierea către celălalt model. Poarta îl refuză categoric, la creare și la scriere, și nicio regulă de acces, indiferent de formă, nu îl deschide — permiteți în schimb asistentului să scrie în modelul țintă.

Un câmp cu inverse rulează cod arbitrar care poate afecta orice: crm.lead.email_from este compute-plus-inverse, iar inversul său scrie res.partner.email. Poarta refuză un astfel de câmp dacă nu există o regulă la nivel de câmp care permite explicit scrierea exact a acelui câmp. O permisiune la nivel de model nu este deliberat suficientă: acordarea scrierii pe crm.lead nu trebuie să deschidă tacit și res.partner.

Suprafața este mai largă decât pare. Odoo de bază are inversuri pe câmpuri obișnuite — partenerul, jurnalul, moneda și termenul de plată ale unei facturi furnizor, produsul și contul unei linii de factură, e-mailul unui lead — așa că vă puteți aștepta să întâlniți această protecție la prima scriere reală pe care o activați.

Oricare dintre refuzuri este o limită de configurare, nu abuz: nu înregistrează nicio încălcare și nu costă utilizatorul niciun avertisment.

Deschiderea unuia dintre aceste câmpuri

  1. Accesați AI ‣ Configurare ‣ Securitate ‣ Reguli de acces.

  2. Creați o regulă cu Model și Câmp setate — câmpul este cel care o face să conteze.

  3. Setați perm_write = Allow.

Important

O regulă cu Câmp lăsat gol este o regulă la nivel de model și nu va ridica această protecție, oricât de permisivă ar părea. perm_write este permisiunea care contează și este, de asemenea, cea care deschide câmpul într-o încărcătură de creare: perm_create este la nivel de model și este ignorată la regulile pe câmp.

Regula ridică doar protecția inversului și nimic altceva. Un câmp care nu este stocat în baza de date — product.template.standard_price este calculat cu un invers, dar nu are coloană — și un câmp related rămân ambele refuzate, oricât de permisivă ar fi regula. Prin urmare, dacă refuzul persistă după o regulă corectă la nivel de câmp, câmpul este related sau nestocat, nu un câmp cu invers.

Sfat

Când refuzul are loc în interiorul unei încărcături one2many sau many2many — de exemplu o linie de factură în Linii factură — asistentul raportează doar câmpul părinte, invoice_line_ids, deoarece acesta este câmpul pe care a încercat să îl scrie. Modelul și câmpul imbricate care au fost efectiv refuzate ajung în jurnalul serverului Odoo, la nivel INFO; căutați în el AI x2many write refused. Ele nu apar în AI ‣ Monitorizare ‣ Jurnale, iar un refuz pentru lipsa activării unui câmp nu înregistrează nici el o încălcare — este o limită de configurare, nu abuz.

Instalare nouă

  • Citire: permisă (cu excepția pragului și a elementelor eliminate), astfel încât asistentul să fie util pentru întrebări și răspunsuri.

  • Creare / scriere / ștergere: refuzate până când deschideți modele specifice.

  • Zece permisiuni de scriere la nivel de câmp sunt livrate activate, astfel încât fluxurile de facturi furnizor și de linii de factură să continue să funcționeze sub protecția între modele de mai sus: account.move (partener, jurnal, monedă, termen de plată, data livrării, referința plății) și account.move.line (produs, cont, distribuție analitică, partener). Nimic nu este deschis pe crm.lead.

    account.move.line.analytic_distribution este cel pe care merită să îl citiți de două ori. Este un câmp JSON, deci regula sa ridică două protecții deodată: protecția între modele de mai sus și refuzul valorilor de tip JSON, pe care nicio altă regulă livrată nu îl atinge. Inversul său părăsește, de asemenea, documentul — pe o linie postată șterge înregistrările account.analytic.line ale liniei și le recreează — astfel încât o scriere analitică ajunge la un model pe care nicio regulă nu l-a numit niciodată și pe care nicio intrare de audit nu îl numește nici ea.

    Aceste rânduri nu au grup de acces și nici companie, deci sunt reguli globale: se aplică fiecărui utilizator AI și fiecărui agent, nu doar fluxului de facturare. Sosesc la instalare și la fiecare actualizare a aplicației AI. Dacă editați sau dezactivați una, o actualizare nu vă va suprascrie modificarea; dacă ștergeți una, aceasta revine.

    Există doar acolo unde Contabilitate este instalată, iar fiecare instalare sau actualizare a aplicației AI populează doar aplicațiile prezente în acel moment. Dacă instalați Contabilitate după aplicația AI, rândurile apar abia la următoarea actualizare a aplicației AI — până atunci, fluxul facturilor furnizor refuză scrierile pe liniile de factură fără niciun alt simptom, așa că actualizați aplicația AI după adăugarea Contabilității.

  • Sunt livrate activate și două permisiuni la nivel de model, pe cele două modele cu permisiune exclusiv explicită de la pasul 5: ir.attachment este deschis pentru citire și scriere (conținut PDF și imagine pentru aptitudinile de documente și facturi furnizor, precum și reatașarea unui fișier la altă înregistrare), mail.activity pentru citire, scriere și creare (To-Do-uri de verificare create de utilizatorul AI). Crearea sau ștergerea unui atașament și ștergerea unei activități rămân închise. Ca și rândurile pe câmp, sunt globale, sosesc la instalare și la fiecare actualizare și supraviețuiesc modificărilor dumneavoastră.

Atenționare

Pe calea liniilor imbricate, cele patru rânduri account.move.line reprezintă o permisiune reală de scriere, nu doar o protecție ridicată. O permisiune la nivel de câmp este rezolvată înainte de nivelul modelului și de valoarea implicită globală, deci, odată ce scrierea este permisă pe account.move, asistentul poate seta produsul, contul, distribuția analitică și partenerul pe liniile de factură prin Linii factură, chiar dacă scrierea pe account.move.line în sine nu a fost niciodată permisă — valoarea implicită Refuz pentru creare/scriere nu oprește această cale. O scriere directă pe account.move.line este în continuare refuzată; doar o încărcătură imbricată într-un câmp părinte omite verificarea la nivel de model.

Câmpurile de antet de pe account.move nu sunt afectate: scrierea documentului necesită în continuare propria dumneavoastră permisiune la nivel de model. Pentru a închide cele patru câmpuri de linie, adăugați un Refuz explicit — la nivel de model pe account.move.line sau pe câmp — sau dezactivați regulile livrate. Un Refuz la oricare dintre niveluri are prioritate față de Permisiune, iar oricare dintre modificări supraviețuiește fiecărei actualizări; ștergerea unei reguli livrate doar o face să revină.

Citire refuzată implicit (mai strict)

Setați citirea implicită la Refuz, apoi adăugați reguli de Permisiune doar pentru modelele pe care asistentul ar trebui să le vadă (de exemplu product.product, res.partner cu refuzuri pe câmp pentru notele interne etc.). Mai sigur pentru bazele de date reglementate; necesită mai multă configurare.

Exemple

Refuzarea oricărei citiri AI pentru angajați

  1. Creați o regulă globală pe modelul hr.employee.

  2. Setați perm_read = Deny (celelalte permisiuni moștenesc/refuză după preferință).

Permiterea agentului de suport să creeze doar tichete helpdesk

  1. Creați grupul de acces AI Support bot cu utilizatorul agent ca membru.

  2. Valorile implicite globale refuză deja crearea.

  3. Regulă pe helpdesk.ticket (sau project.task) pentru acel grup:

    • perm_create = Allow (permis)

    • perm_read = Deny (sau Allow doar pentru câmpurile sigure prin reguli pe câmp)

    • perm_write = Deny (refuzat)

    • perm_delete = Deny (refuzat)

  4. La nivel de câmp: permiteți scrierea pe puținele câmpuri setate la creare (nume, descriere, e-mailul partenerului, echipă), dacă politica dumneavoastră necesită permisiune de scriere pentru a seta valori la creare.

  5. Asigurați-vă că utilizatorul agent are ACL-uri Odoo corespunzătoare pentru a crea acele tichete — politica singură nu poate acorda crearea dacă grupul de utilizatori nu o poate face.

Calendar liber/ocupat fără detaliile evenimentelor

Obiectiv: agentul poate crea o întâlnire în intervale libere, dar nu trebuie să transmită către LLM subiectele și participanții evenimentelor altor persoane.

  1. Modelul calendar.event:

    • perm_read = Deny la nivel de model pentru grupul botului, sau

    • perm_read = Allow cu Deny la nivel de câmp pe name, description, partner_ids, videocall_location și altele similare.

  2. Preferați o API/acțiune dedicată pentru liber/ocupat, dacă adăugați una ulterior; citirea brută a evenimentelor este o sursă frecventă de divulgare excesivă.

  3. perm_create = Allow cu permisiune de scriere doar pe start, stop, name (generic), user_id.

Consultați Rețete pentru agenți pentru rețete complete pentru agenți, care combină politici, capabilități și canale.

Relația cu regulile de înregistrare Odoo

Politica AI nu înlocuiește regulile de înregistrare. Multicompania, documentele doar pentru urmăritori și izolarea portalului rămân impuse de Odoo atunci când poarta rulează ca utilizatorul. La proiectarea unui scenariu „creare, dar nu citire”, verificați ambele straturi: o creare care returnează un instantaneu de citire poate eșua sau elimina date dacă citirea este refuzată — asistentul trebuie să considere erorile instrumentelor drept definitive.