Hozzáférési házirend

Az AI access policy dönti el, hogy a hozzáférési kapu a normál Odoo ACL-eken kívül mit tehet. Csak narrow jogosultságokkal rendelkezik: ha a felhasználó nem tud olvasni egy rekordot a Odoo-ben, akkor az AI sem – még akkor sem, ha a szabály engedélyezi.

Menük:

  • AI ‣ Konfiguráció ‣ Biztonság ‣ Hozzáférési csoportok

  • AI ‣ Konfiguráció ‣ Biztonság ‣ Hozzáférési szabályok

Fogalmak

AI hozzáférési csoport

A ai.access.group olyan személyek csoportja, akikre a szabályok vonatkoznak:

  • Tagok – explicit felhasználók (beleértve az ügynökfelhasználókat).

  • Mapped Odoo groups — ezekben a csoportokban mindenki tagja is.

  • Szabályok — az engedélyezési/megtagadási mátrix ehhez a csoporthoz.

Használjon olyan csoportokat, mint az AI – Értékesítési olvasók, AI – Support agent bot, AI – No HR.

AI hozzáférési szabály

Egy ai.access.rule cél:

  • opcionális Access group (üres = global szabály minden AI-felhasználó számára);

  • Modell (kötelező);

  • opcionális Mező (üres = modellszintű szabály);

  • perm_read / perm_write / perm_create / perm_delete mindegyik mint Öröklés, Allow vagy Deny.

A létrehozás és törlés csak modellszintű (a mezőszabályok figyelmen kívül hagyják). A Create mezőértékek beállításához továbbra is engedélyezni kell azokat a mezőket, ahol a házirend ellenőrzi őket.

Feloldási sorrend

Egy adott felhasználó, modell, művelet és opcionális mező esetében a ai_can nagyjából a következőképpen oldódik meg:

  1. Hard-deny padló — a technikai / önvédelmi modellek mindig tiltottak, beleértve minden ai.* platformmodellt és a nyers mail.message / discuss.channel modellt (lásd Biztonság).

  2. Bármely kifejezett Megtagadás, mező vagy modell szintű. A Megtagadás bármelyik szinten feltétlen: semmi, ami alatta következik, nem írja felül.

  3. Mező szintű Engedélyezés (csak olvasás/írás) — ez dönti el a mező szintjét, és az adott mezőre nézve felülírja a globális alapértelmezést. Erre a mechanizmusra épülnek a gyári szabályok és a modellek közötti íráshoz szükséges teljes, kifejezett engedélyezés: mivel az írás alapértelmezése Megtagadás, egy mezőre szabott Engedélyezés az, ami írhatóvá tesz egy mezőt. A modell szintet viszont nem váltja ki: egy modell közvetlen írásának továbbra is át kell mennie az adott modellre a 4. vagy a 6. lépésen. Csak a szülő one2many vagy many2many mezőbe beágyazott adatcsomag hagyja ki a gyermekmodell modell szintű ellenőrzését.

  4. Modellszintű Engedélyezés — a csoportok között a legspecifikusabb Engedélyezés győz.

  5. Csak kifejezett engedéllyel nyitható modellek — az ir.attachment és a mail.activity itt megáll. Ezek nincsenek a padlón, ezért szabállyal megnyithatók, de soha nem esnek át a globális alapértelmezésekre: illeszkedő Engedélyezés hiányában tiltottak.

  6. Global defaults a Beállítások menüből (alapértelmezett_olvasás / létrehozás / írás / törlés).

Ismeretlen modellek vagy műveletek sikertelen lezárása. Az eredmények a szabályok, csoportok vagy paraméterek változása esetén a gyorsítótárba kerülnek, és érvénytelenné válnak.

Univerzális szaniter sínek (házirend előtt/mellett)

Az engedélyező szabályoktól függetlenül a kapu a következőket elutasítja vagy eltávolítja — egy kivétellel, amelyet a lista jelöl:

  • varázsmezők;

  • érzékeny kinézetű mezőnevek (jelszó, token, api_key, …);

  • mezők, amelyek egy másik modellbe írnak — ez az egyetlen védőkorlát, amelyet egy Engedélyezés szabály feloldhat, és csak mezőnként; lásd: Modellek közötti írás elleni védelem;

  • életciklus state írások;

  • nem írható / összetett típusok, amelyek nem lehetnek LLM-vezéreltek;

  • Megtagadási modellek relációs útvonalakban/tartományokban.

Modellek közötti írás elleni védelem

Egyes Odoo-mezők nem csupán egy értéket tárolnak: az írásuk egy másik modellbe is beír. A crm.lead.email_from például a kapcsolt partner e-mail címét frissíti. Védelem nélkül egy olyan asszisztens, amely „szerkesztheti a lead-eket”, a megnyitott modelleken kívüli kapcsolati adatokat is módosíthatna, az audit-napló pedig csak a lead-et nevezné meg.

Az Odoo-ban kétféle ilyen mező van, és csak az egyik nyitható meg.

A related mező definíció szerint átirányítja az írást a másik modellre. A kapu ezt eleve elutasítja, létrehozáskor és íráskor is, és semmilyen formájú hozzáférési szabály nem nyitja meg — engedélyezze inkább az asszisztensnek a célmodell írását.

Az inverse függvényt hordozó mező tetszőleges kódot futtat, amely bármit érinthet: a crm.lead.email_from compute+inverse mező, és az inverze a res.partner.email mezőbe ír. A kapu az ilyen mezőt elutasítja, hacsak egy mező szintű szabály kifejezetten nem engedélyezi pontosan annak a mezőnek az írását. A modellszintű Engedélyezés szándékosan nem elegendő: a crm.lead írásának megadása nem nyithatja meg csendben a res.partner modellt is.

A felület szélesebb, mint amilyennek látszik. Az alap Odoo mindennapi mezőkön is használ inverse-t — egy bejövő számla partnere, naplója, pénzneme és fizetési feltétele, egy számlasor terméke és főkönyvi számlája, egy lead e-mail címe —, ezért számoljon vele, hogy már az első valódi írás engedélyezésekor beleütközik ebbe a védőkorlátba.

Mindkét elutasítás konfigurációs határ, nem visszaélés: nem rögzít szabálysértést, és a felhasználónak nem jár figyelmeztetéssel.

Egy ilyen mező megnyitása

  1. Lépjen az AI ‣ Konfiguráció ‣ Biztonság ‣ Hozzáférési szabályok menüpontra.

  2. Hozzon létre egy szabályt, amelyben a Modell és a Mező is ki van töltve – a mező az, amitől érvényes lesz.

  3. Állítsa a perm_write értékét Engedélyezés-re.

Fontos

Az a szabály, amelyben a Mező üresen marad, modell szintű szabály, és nem oldja fel ezt a védőkorlátot, bármilyen engedékenynek is tűnik. A perm_write az a jogosultság, amely számít, és ez nyitja meg a mezőt egy létrehozási adatcsomagon belül is: a perm_create modell szintű, és a mezőszabályokon a rendszer figyelmen kívül hagyja.

A szabály az inverse-védőkorlátot oldja fel, semmi mást. Az adatbázisban nem tárolt mező — a product.template.standard_price inverse-szel számított, de nincs oszlopa — és a related mező is elutasított marad, bármilyen engedékeny is a szabály. Ha tehát az elutasítás egy helyes mező szintű szabály ellenére is megmarad, akkor a mező related vagy nem tárolt, nem pedig inverse-szel rendelkező mező.

Javaslat

Amikor az elutasítás egy one2many vagy many2many adatcsomagon belül történik — például egy számlasor esetén a Számlasorok mezőben —, az asszisztens csak a szülő mezőt, az invoice_line_ids-t jelenti, mert azt próbálta írni. A valóban elutasított beágyazott modell és mező az Odoo kiszolgálónaplójába kerül, INFO szinten; keresse benne az AI x2many write refused szöveget. Az AI ‣ Monitoring ‣ Naplók alatt nem jelennek meg, és a hiányzó mezőengedély miatti elutasítás sem rögzít szabálysértést — ez konfigurációs határ, nem visszaélés.

Friss telepítés

  • Olvassa el: allow (mínusz a padló és a csíkok), így az asszisztens hasznos lehet kérdések és válaszok esetén.

  • Létrehozása / írása / törlése: deny, amíg meg nem nyit bizonyos modelleket.

  • Tíz mező szintű írási engedély érkezik bekapcsolva, hogy a bejövő számla és a számlasor folyamatai a fenti, modellek közötti védőkorlát alatt is működjenek: account.move (partner, napló, pénznem, fizetési feltétel, szállítási dátum, fizetési hivatkozás) és account.move.line (termék, főkönyvi számla, analitikus felosztás, partner). A crm.lead modellen semmi nincs megnyitva.

    Az account.move.line.analytic_distribution az, amit érdemes kétszer elolvasni. Ez JSON mező, ezért a rá vonatkozó szabály egyszerre két védőkorlátot old fel: a fenti, modellek közötti védőkorlátot és a JSON típusú értékek elutasítását, amelyet egyetlen más gyári szabály sem érint. Az inverze ráadásul kilép a dokumentumból — egy lekönyvelt soron törli a sor account.analytic.line rekordjait, majd újra létrehozza őket —, így egy analitikus írás olyan modellhez ér el, amelyet egyetlen szabály sem nevezett meg, és amelyet egyetlen naplóbejegyzés sem nevez meg.

    Ezeken a sorokon nincs hozzáférési csoport és nincs vállalat, tehát globális szabályok: minden AI-felhasználóra és minden ügynökre érvényesek, nem csak a számlázási folyamatra. Telepítéskor és az AI alkalmazás minden frissítésekor létrejönnek. Ha átír vagy kikapcsol egyet, a frissítés nem írja felül a módosítását; ha töröl egyet, az újra létrejön.

    Ezek csak ott léteznek, ahol a Könyvelés telepítve van, és az AI alkalmazás minden telepítése vagy frissítése csak az abban a pillanatban jelen lévő alkalmazásokhoz hoz létre sorokat. Ha a Könyvelést az AI alkalmazás után telepíti, a sorok csak az AI alkalmazás következő frissítésekor jelennek meg — addig a bejövő számla folyamat minden más tünet nélkül elutasítja a számlasorok írását, ezért a Könyvelés hozzáadása után frissítse az AI alkalmazást.

  • Két modell szintű engedély is bekapcsolva érkezik, az 5. lépés két, csak kifejezett engedéllyel nyitható modelljére: az ir.attachment olvasásra és írásra van megnyitva (PDF- és képtartalom a dokumentum- és a bejövőszámla-skillekhez, valamint fájl átcsatolása másik rekordra), a mail.activity pedig olvasásra, írásra és létrehozásra (az AI-felhasználó nevében készülő ellenőrző Teendők). A csatolmányok létrehozása és törlése, valamint a tevékenységek törlése zárva marad. A mezőszintű sorokhoz hasonlóan ezek is globálisak, telepítéskor és minden frissítéskor létrejönnek, és túlélik az Ön módosításait.

Figyelem

A beágyazott sorok útvonalán a négy account.move.line sor valódi írási jogosultság, nem csupán egy feloldott védőkorlát. A mező szintű Engedélyezés a modell szint és a globális alapértelmezés előtt dől el, ezért ha az account.move írása engedélyezett, az asszisztens a Számlasorok mezőn keresztül beállíthatja a számlasorok termékét, főkönyvi számláját, analitikus felosztását és partnerét, még akkor is, ha magának az account.move.line modellnek az írása soha nem volt engedélyezve — a létrehozás/írás alapértelmezett Megtagadása itt nem szab gátat. Az account.move.line közvetlen írása továbbra is elutasított; csak a szülő mezőbe beágyazott adatcsomag hagyja ki a modell szintű ellenőrzést.

Az account.move fejlécmezőit ez nem érinti: a dokumentum írásához továbbra is az Ön saját modell szintű Engedélyezése kell. A négy sormező bezárásához adjon meg kifejezett Megtagadást — modell szinten az account.move.line modellre vagy magára a mezőre —, vagy kapcsolja ki a gyári szabályokat. A Megtagadás bármelyik szinten legyőzi az Engedélyezést, és mindkét szerkesztés túlél minden frissítést; egy gyári szabály törlése csak visszahozza azt.

Alapból tiltott olvasás (szigorúbb)

Állítsa az alapértelmezett olvasást Megtagadás értékre, majd adja hozzá az Engedélyezés szabályokat csak azokhoz a modellekhez, amelyeket az asszisztensnek látnia kell (pl. product.product, res.partner mezőmegtagadásokkal a belső megjegyzéseknél stb.). Biztonságosabb a szabályozott adatbázisokhoz; több beállítást igényel.

Példák

Minden AI olvasás tiltása az alkalmazottakon

  1. Globális szabály létrehozása a hr.employee modellre.

  2. Állítsa be a perm_read = Deny értéket (más engedélyek tetszés szerint öröklik/megtagadják).

Support ügynök csak helpdesk jegy létrehozására

  1. Hozzon létre mesterséges intelligencia hozzáférési csoportot Support bot, amelynek tagja az ügynök felhasználója.

  2. A globális alapértelmezések már tiltják a létrehozást.

  3. Szabály helpdesk.ticket (vagy project.task) erre a csoportra:

    • perm_create = Engedélyezés

    • perm_read = Megtagadás (vagy csak biztonságos mezők engedélyezése mezőszabályokon keresztül)

    • perm_write = Megtagadás

    • perm_delete = Megtagadás

  4. Mezőszint: engedélyezze az írást a létrehozáskor beállított néhány mezőbe (név, leírás, partner e-mail-cím, csapat), ha a szabályzat megköveteli az írási engedélyt az értékek beállításához a létrehozáskor.

  5. Győződjön meg arról, hogy a user ügynök rendelkezik egyező Odoo ACL-ekkel a jegyek létrehozásához – a házirend önmagában nem engedélyezheti a létrehozást, ha a felhasználói csoport nem tudja.

Naptár free/busy eseményrészletek nélkül

Cél: az ügynök létrehozhat egy értekezletet a szabad helyeken, de nem hagyhatja mások eseményeinek tárgyait és résztvevőit a LLM-ra.

  1. calendar.event modell:

    • perm_read = Megtagadás modell szinten a botcsoporthoz, or

    • perm_read = Engedélyezés az Deny mezőszinttel name, description, partner_ids, videocall_location és hasonlók esetén.

  2. Előnyben részesítse a dedikált szabad foglalt API/akciót, ha később hozzáad egyet; A nyers eseményolvasás gyakori túlzott megosztás.

  3. perm_create = Engedélyezés csak írási engedéllyel induláskor, leállításkor, név (általános), user_id.

Lásd a Ügynök-receptek-t a végpontok közötti ügynökreceptekért, amelyek egyesítik a szabályzatot, a képességeket és a csatornákat.

Kapcsolat az Odoo rekordszabályokkal

Az AI házirend not helyettesíti a rekordszabályokat. A többvállalati, csak követő dokumentumokat és a portál elkülönítését az Odoo továbbra is kényszeríti, amikor a kapu felhasználóként fut. A „létrehozni, de nem olvasni” tervezésekor ellenőrizze mindkét réteget: az olvasási pillanatképet visszaadó létrehozás továbbra is meghiúsulhat vagy megszakadhat, ha az olvasást megtagadják – az asszisztensnek az eszközhibákat mérvadóként kell kezelnie.