In een sessie over Odoo-beveiliging op Odoo Experience 2026 vertelde een implementatiepartner wat hij bij klanten ziet. Iedereen zegt dat hij wil beperken wat AI in de database mag. Daarna krijgt de AI toch alle rechten, en de extra module die daar een slot op zet, gebruikt bijna niemand. In de openingskeynote ging het niet anders: de AI-assistent vroeg toestemming om een project aan te maken, omdat hij standaard geen records mocht bijwerken, en het antwoord vanaf het podium was dat hij alles mocht. Voor een demo is dat prima. In je eigen database begin je andersom.
Odoo 20 maakt toegangsrechten eenvoudiger en zet er nieuwe deuren bij, voor AI binnen Odoo en daarbuiten. Mijn vuistregel: geef een AI nooit meer rechten dan een nieuwe collega, en leg per rol vast wie wat mag.
Toegangsrechten zonder recordregels
Tot nu toe had je twee lagen: het toegangsrecht (mag deze groep lezen, schrijven, aanmaken, verwijderen) en de recordregel (op welke records). Volgens de release notes van Odoo 20 verdwijnt die tweede laag. Het domein, de filter die bepaalt op welke records een recht geldt, staat voortaan op het toegangsrecht zelf.
Minder lagen is makkelijker beheren. Heb je eigen rechten gebouwd, laat ze omzetten en test per rol op een testkopie. De gebruikersdocumentatie over toegangsrechten voor versie 20 beschrijft recordregels nu nog; de release notes zijn hier de nieuwste bron.
Begin bij de rol, niet bij de techniek
Wie doet wat, en wat hoort iemand juist niet te zien? Die vraag beantwoord je vóórdat je gebruikersrechten toekent. Odoo 20 geeft daarvoor fijnere stappen:
- Kassa: een nieuw, zeer beperkt toegangsniveau voor medewerkers.
- Verlof: een recht dat de app voor iemand helemaal afsluit.
- Aanwezigheden: wie er geen rechten op heeft, kan de app niet meer gebruiken.
- Documenten: gebruikersgroepen om rechten op bestanden en mappen in één keer te regelen.
Let bij Light Users op dat ene vinkje. Volgens dezelfde documentatie wordt een Light User automatisch een volledige gebruiker zodra hij een recht krijgt buiten zijn beperkte set. Eén vinkje te veel verandert dus ook het type licentie. Leg per rol vast welk type gebruiker erbij hoort en wie rechten mag aanzetten.
Een agent kan wat zijn vaardigheden toelaten
Een agent in Odoo werkt met vaardigheden: instructies plus tools. Volgens de documentatie over agents kan een agent zonder vaardigheden alleen informatie geven. Pas met vaardigheden maakt hij records aan of past hij ze aan. Welke vaardigheden een agent krijgt, is dus een rechtenvraag. In de demo's op de beurs werkte de AI binnen de rechten van de gebruiker die de vraag stelde, en vroeg hij bij elke schrijfactie om bevestiging. Toets dat in je eigen testdatabase voordat je erop bouwt.
Externe AI via MCP: de deur die je zelf openzet
Via MCP (Model Context Protocol), een open standaard, koppel je een externe AI-assistent aan je Odoo-database. De MCP-documentatie van Odoo is helder over de beginstand. Alleen leestools staan open; de rest blijft verborgen tot een beheerder een tool per stuk openzet. De assistent werkt met de rechten van de gekoppelde gebruiker, en elke verbinding staat als sleutel bij die gebruiker: verwijder je de sleutel, dan is de toegang ingetrokken. En alleen-lezen is een advies, geen slot. Een tool met dat vinkje mag de assistent zonder jouw goedkeuring aanroepen, dus zet het nooit op een tool die iets wijzigt.
Eén beperking staat er niet zo duidelijk bij. In de vragenronde van een technische sessie over MCP zei een ontwikkelaar van Odoo dat je een schrijftool nog niet per gebruiker kunt openzetten: sta je hem toe, dan geldt hij voor iedereen. Wat de assistent daarna echt kan, hangt af van de rechten van de gebruiker achter de koppeling. Des te meer reden voor een eigen gebruiker per koppeling, met de rechten van een nieuwe collega en een vervaldatum op de sleutel. Bij Newway hebben we het na de beurs in lagen gezet: via MCP stelt iedereen vragen met zijn eigen Odoo-rechten, en wie iets bouwt, doet dat op een aparte ontwikkelomgeving met review. Eén les uit dat overleg: afscherming die alleen in een weergave zit, houdt een assistent via MCP niet tegen. Wat iemand niet mag zien, scherm je af op het niveau van het veld.
Vastleggen en controleren
Odoo 20 helpt bij een audit. Wijzigingen in gebruikersgroepen staan in de chatter van de gebruiker, en uitgaande mail legt vast waar de inhoud vandaan komt. Plan een rechtencheck na elke upgrade, en daarna vast in je kwartaaloverleg.
Rechten volgen bij ons uit de analyse: wie doet wat in het proces. Elke wijziging gaat eerst door de testomgeving van onze OTAP-straat, en AI zetten we in met een mens die de uitkomst toetst. Zelf zijn we NEN 7510- en ISO 27001-gecertificeerd en controleren we onze autorisaties en toegangsrechten periodiek. Hoe je processen, eigenaren en normen vastlegt, lees je bij kwaliteitsmanagement. De rechtencheck na een upgrade hoort in het ritme van managed services.
Twee vragen vooraf
Wat gebeurt er met mijn recordregels bij de upgrade naar Odoo 20? Volgens de release notes verdwijnen ze als aparte laag: het domein komt op het toegangsrecht zelf te staan. Hoe jouw eigen regels erbij komen te staan, zie je op een testkopie. Zitten er recordregels in maatwerk, laat die dan vóór de upgrade nalopen.
Helpt Odoo 20 bij NEN 7510 of ISO 27001? Een systeem maakt je niet compliant. Odoo 20 helpt wel: rechtenwijzigingen worden gelogd en de toegangsniveaus zijn fijner. Compliance zit in de afspraken, de rolverdeling en de periodieke controle, en die leg je zelf vast. Geef elke rechtenwijziging daarom een eigenaar en een reden.
Wat Odoo 20 verder verandert, lees je in het overzicht van Odoo 20. Wil je weten of je rechten en AI-koppelingen klaar zijn voor Odoo 20? Plan een kennismaking
Luc Castermans was op Odoo Experience 2026 en schrijft in Hoe Odoo?! over Odoo inzetten zoals het bedoeld is.
