Odoo 20 supprime les règles d'enregistrement : auditez vos droits

Parmi les notes de version d'Odoo 20, publiées après l'Odoo Experience de fin septembre, une ligne passe presque inaperçue au milieu des agents IA et du nouveau plan comptable. Elle annonce que les droits d'accès « have been simplified by removing record rules »¹. Pour un utilisateur, c'est une ligne de plus. Pour une PME qui a fait cloisonner ses commerciaux, ses filiales ou ses sous-traitants, c'est la couche qui décide qui voit quoi dans la base, et elle change de forme.

Nous avons lu le code de la branche 20.0 plutôt que les résumés. Voici ce qu'il dit, et ce que nous recommandons de vérifier avant de migrer.

Deux tables fusionnent en une

Jusqu'à Odoo 19, la sécurité reposait sur deux objets. Les droits d'accès (ir.model.access) ouvraient un modèle entier à un groupe, opération par opération. Les règles d'enregistrement (ir.rule) filtraient ensuite les lignes visibles avec un domaine. Un commercial pouvait ainsi lire le modèle des devis, tout en ne voyant que les siens.

Dans la branche 20.0, le fichier ir_rule.py n'existe plus dans le module de base, et le dossier de sécurité de ce module contient un unique ir.access.csv². Le nouveau modèle ir.access porte dans une même ligne le modèle concerné, le groupe éventuel, les opérations et le domaine. L'en-tête du fichier CSV de base suffit à comprendre la logique : id,name,model_id,group_id/id,operation,domain. Les quatre colonnes booléennes de lecture, écriture, création et suppression disparaissent au profit d'un champ operation qui combine les lettres c, r, u et d³.

Le modèle calcule lui-même la nature de chaque ligne. Avec un groupe, elle devient une « permission ». Sans groupe, elle devient une « restriction » qui s'applique à tous les utilisateurs³.

Les règles de combinaison, lues dans le code

La documentation Odoo 19 posait trois principes. Les règles globales se cumulent, et chacune restreint davantage. Les règles de groupe s'additionnent, ce qui peut élargir l'accès sans dépasser les bornes fixées par les règles globales. Enfin, les deux ensembles s'intersectent⁴.

Le code d'Odoo 20 reprend cette mécanique dans ses commentaires. Les permissions sont « OR-ed together », tandis que les restrictions « are AND-ed and can each fail independently »³. Sur le papier, la continuité est donc forte, et les cas simples devraient migrer sans surprise.

Un point mérite pourtant un test sur vos données. En Odoo 19, un groupe qui possédait un droit d'accès sans règle d'enregistrement n'élargissait pas les règles d'un autre groupe : seules les règles des groupes de l'utilisateur entraient dans l'union. En Odoo 20, droit et domaine vivent sur la même ligne, et une permission sans domaine couvre logiquement tous les enregistrements. Si un utilisateur cumule un groupe large sans domaine et un groupe filtré, l'union des deux risque de lui ouvrir l'ensemble des lignes. C'est notre lecture du code, pas un comportement documenté par Odoo. Elle se vérifie en dix minutes sur une base de test, avec un compte qui cumule les deux profils.

Les intégrateurs qui ont publié des guides de migration convergent sur ce point. L'un d'eux décrit des sémantiques OR et AND « différentes d'avant » qui demandent de la prudence au moment de consolider les règles⁵.

Ce que cela casse dans un projet existant

Trois familles de personnalisations sont concernées.

La première regroupe les modules sur mesure. Chaque fichier ir.model.access.csv et chaque règle déclarée en XML doit être réécrit au format ir.access. Un module qui crée encore des enregistrements ir.rule vise un modèle absent de la branche 20.0². Le guide de migration d'Ecosire rappelle que, selon la documentation d'Odoo, une base qui embarque des modules personnalisés ne peut pas être migrée tant que ces modules n'ont pas de version pour la cible⁶.

La deuxième concerne les réglages faits à la main par un administrateur, dans l'interface, sur des règles standard. Odoo 20 prévoit une méthode customize dont le commentaire est explicite : si l'accès provient d'un module, elle « deactivate it and edit a copy »³. Un champ calculé is_standard distingue les lignes livrées par un module de celles créées par export, par personnalisation ou par Studio. Pour l'audit, c'est une bonne nouvelle, car on sait enfin quelles lignes sortent du standard. Pour la maintenance, cela signifie qu'une règle standard personnalisée ne suivra plus les corrections de l'éditeur, puisque la copie active remplace l'original désactivé.

La troisième touche les applications qui ont reçu leurs propres réglages dans cette version. Les notes de version citent la possibilité de restreindre les utilisateurs « light » au seul module Code-barres, des groupes d'utilisateurs pour gérer les droits sur les fichiers et dossiers de Documents, et l'interdiction d'utiliser Présences sans droit dédié¹. Ce dernier point peut couper l'accès à des salariés qui pointaient jusque-là sans droit explicite.

Une trace des changements de groupes

Odoo 20 ajoute un élément utile pour la gouvernance. Les modifications de groupes d'un utilisateur sont désormais journalisées dans son fil de discussion et dans les journaux du serveur¹. Jusqu'ici, savoir qui avait donné les droits de gestionnaire comptable à un stagiaire demandait de fouiller les logs ou de faire confiance à la mémoire de l'administrateur. Cette trace ne remplace pas une revue périodique des habilitations, mais elle rend la revue vérifiable.

Une méthode d'audit en quatre temps

Nous conseillons de traiter ce chantier avant la migration technique, et non pendant.

1. Inventorier en Odoo 19. Exportez les droits d'accès et les règles d'enregistrement actifs, en séparant le standard de ce qui a été ajouté ou modifié. Les règles globales personnalisées méritent une attention particulière, car la documentation prévenait déjà que plusieurs règles globales peuvent, mal combinées, supprimer tout accès⁴.
2. Cartographier les profils réels. Listez les combinaisons de groupes que portent vraiment vos utilisateurs. C'est là que se cachent les cumuls à risque décrits plus haut.
3. Tester sur une base migrée. Odoo fournit une base de test migrée avant toute migration de production. Connectez-vous avec un compte de chaque profil et vérifiez ce qu'il voit sur les modèles sensibles : devis, factures, fiches salariés, contacts multi-sociétés.
4. Documenter les écarts. Le champ note du modèle ir.access accepte du texte libre³. Utilisez-le pour expliquer pourquoi une restriction existe. Le prochain intégrateur vous en remerciera.

Notre lecture

Fusionner droits et règles est une bonne décision. Dans une PME, l'administrateur Odoo n'est souvent pas un spécialiste, et deux couches qui interagissent entre elles laissent passer des erreurs : une règle oubliée, ou contredite par un groupe ajouté plus tard. Une seule table, avec une distinction claire entre permission et restriction, se lit plus facilement.

Le risque se situe dans la transition. Une migration réussie au sens technique, sans erreur au démarrage, peut très bien laisser un commercial voir le portefeuille de ses collègues. Personne ne le remarquera avant qu'un client le signale. Les nouveautés d'Odoo 20 qui attirent l'attention, comme les agents IA capables de créer et modifier des enregistrements, rendent ce point plus sensible encore, car un agent agit avec des droits qu'il faut avoir bornés correctement.

Notre recommandation est simple. Faites de la revue des habilitations un livrable à part entière de votre projet Odoo 20, avec un responsable métier qui valide les profils et non le seul développeur qui porte les modules.

Sources

• Odoo 20 Release Notes : https://www.odoo.com/odoo-20-release-notes
• Code source Odoo 20.0, ir_access.py : https://github.com/odoo/odoo/blob/20.0/odoo/addons/base/models/ir_access.py
• Code source Odoo 20.0, ir.access.csv du module base : https://github.com/odoo/odoo/blob/20.0/odoo/addons/base/security/ir.access.csv
• Documentation développeur Odoo 19.0, Security in Odoo : https://www.odoo.com/documentation/19.0/developer/reference/backend/security.html
• Ecosire, Odoo 19 to 20 upgrade guide : https://ecosire.com/fr/blog/odoo-19-to-20-upgrade-guide
• LinkedIn, publication sur la sécurité Odoo 20 : https://in.linkedin.com/in/mantu105