Les droits d'Odoo s'accordent par groupe, et un utilisateur en cumule facilement quinze. Personne ne sait plus ce qu'il peut faire : il faudrait lire quinze groupes, leurs héritages et leurs règles d'enregistrement. L'administrateur coche, et espère.
Dix-sept modules communautaires rendent les droits lisibles et gérables par rôles. Ils terminent le dépôt server-backend.
Résumé
Cinq modules traitent les rôles : des rôles utilisateur regroupant des groupes, leur déclinaison par société, un historique des changements, des profils utilisateur, et l'inspection des droits effectifs d'un utilisateur.
Cinq modules traitent les connexions externes : un cadre de sources de bases de données avec trois connecteurs — deux systèmes commerciaux et un format de fichier —, et un cadre de systèmes externes plus général.
Trois modules traitent l'import et le portail : l'évitement des doublons avant import avec son référentiel de correspondances, des types de portail distincts, et un groupe d'accès au back-office.
Quatre modules enfin traitent des mécanismes transverses : des remises globales, des adresses de calendrier en lecture seule pour les modèles de type agenda, et deux actions serveur génériques — navigation entre enregistrements et tri de lignes par critères.
L'essentiel
- Les droits effectifs d'un utilisateur inspectables.
- Des rôles utilisateur regroupant des groupes, déclinables par société.
- Un historique des changements de rôle.
- Des profils utilisateur.
- La connexion à des bases de données externes.
- L'évitement des doublons avant import, par correspondances.
- Des remises globales sur les documents.
- Des adresses de calendrier en lecture seule.
Ce que ces modules ajoutent à l'instance
| Famille | Modules | Nombre |
|---|---|---|
| Rôles et droits | base_user_role, base_user_role_company, base_user_role_history, base_user_role_profile, base_user_effective_permissions | 5 |
| Bases externes | base_external_dbsource, base_external_dbsource_mssql, base_external_dbsource_mysql, base_external_dbsource_sqlite, base_external_system | 5 |
| Import et portail | base_import_match, base_portal_type, base_group_backend | 3 |
| Transverses | base_global_discount, base_ical, server_action_navigate, server_action_sort | 4 |
Les menus : Paramètres ▸ Utilisateurs & Sociétés ▸ Rôles utilisateur et Profils utilisateur, Paramètres ▸ Technique ▸ Structure de la base de données ▸ Database Sources et Import Match, Paramètres ▸ Technique ▸ External Systems, iCalendars, et Paramètres ▸ Paramètres ▸ Remises globales.
Savoir ce qu'un utilisateur peut faire
La question « que peut faire cet utilisateur » n'a pas de réponse dans Odoo : les droits résultent du cumul de ses groupes, de leurs héritages, de leurs droits d'accès par modèle et de leurs règles d'enregistrement. Un administrateur qui coche un groupe de plus ne sait pas ce qu'il vient d'ouvrir.
base_user_effective_permissions permet d'inspecter les droits effectifs appliqués à un utilisateur — le résultat du cumul, et non la liste de ses groupes.
C'est le module à installer avant toute revue de droits : il transforme un audit d'une journée en une consultation d'écran.
Les groupes et les droits sont traités dans droits utilisateurs et sécurité d'accès.
Les rôles plutôt que les groupes
base_user_role (LGPL-3, version 18.0.1.2.0) introduit des rôles utilisateur : un rôle regroupe des groupes, et c'est le rôle qu'on attribue. Référentiel sous Paramètres ▸ Utilisateurs & Sociétés ▸ Rôles utilisateur.
La différence est organisationnelle : « comptable » est un rôle, et personne ne sait quels sept groupes il contient. Attribuer un rôle plutôt que sept groupes rend l'arrivée d'un salarié reproductible — et son départ vérifiable.
base_user_role_companydécline les rôles par société : le même utilisateur peut avoir un rôle différent selon la société active.base_user_role_historytrace les changements de rôle — qui a donné quoi à qui, et quand.base_user_role_profileajoute des profils utilisateur, sous son propre menu.
L'historique des rôles est l'information qu'un audit demande et qu'aucune instance ne possède : la liste des élévations de droits, avec leur date et leur auteur.
Trois de ces modules ont un README réduit à leur catégorie ; leurs menus en disent l'objet.
Se connecter à des bases externes
base_external_dbsource (LGPL-3) fournit un cadre de sources de bases de données externes, sous Paramètres ▸ Technique ▸ Structure de la base de données ▸ Database Sources. Trois connecteurs en dérivent : deux pour des systèmes de gestion de bases commerciaux, un pour un format de fichier embarqué.
base_external_system (LGPL-3) fournit un cadre plus général de systèmes externes, sous son propre menu.
La connexion à une base externe est le pont le plus direct vers un logiciel métier qu'on ne remplace pas : une application de production, un historique de paie, un système de caisse propriétaire. C'est aussi la brique dont dépendent les indicateurs calculés sur base externe.
Les indicateurs sur base externe sont traités dans exports SQL et indicateurs.
L'import, le portail et le reste
base_import_match évite les doublons avant un import : un référentiel de correspondances définit, par modèle, sur quels champs reconnaître un enregistrement existant. Menu sous Import Match.
C'est le module qui sauve une reprise de données : sans lui, réimporter un fichier corrigé crée une seconde fois tous ses enregistrements. Avec, l'import reconnaît l'existant sur les champs qu'on a désignés — numéro de TVA, référence interne, code client.
base_portal_typepermet de distinguer plusieurs types de portail — un portail client et un portail fournisseur n'ont pas les mêmes écrans.base_group_backend(LGPL-3) fournit un groupe d'accès au back-office. Son README est réduit à sa catégorie, et ses menus portent des noms de démonstration.base_global_discountajoute des remises globales, avec leur référentiel. README réduit à sa catégorie.base_icalfournit des adresses de calendrier en lecture seule pour les modèles de type agenda, sous Paramètres ▸ Technique ▸ iCalendars.server_action_navigatepermet de naviguer entre les enregistrements de n'importe quel modèle, etserver_action_sortde trier les lignes de n'importe quel modèle par critères.
Les adresses de calendrier répondent à un besoin simple : exposer un planning d'Odoo — interventions, congés, livraisons — dans l'agenda d'un collaborateur, sans développement.
Limites connues
- Six modules ont un README réduit à leur catégorie : les trois connecteurs de bases externes,
base_user_role,base_user_role_company,base_user_role_profile,base_group_backendetbase_global_discount. base_group_backendporte des menus de démonstration — nommés « Dummy » et « No Group » dans le relevé : à vérifier sur instance avant de l'installer en production.- Les rôles s'ajoutent aux groupes, ils ne les remplacent pas : un utilisateur peut avoir un rôle et des groupes directs, et le cumul s'applique.
- L'inspection des droits effectifs montre l'état, elle ne le corrige pas : la reprise est un travail d'administration.
- Une connexion à une base externe stocke des identifiants : les sortir de la base par un module d'environnement serveur.
base_import_matchreconnaît sur les champs désignés : une correspondance mal définie fusionne des enregistrements distincts, ce qui est pire qu'un doublon.base_icalexpose des données en lecture seule par une adresse : vérifier qui peut connaître cette adresse.- Les deux actions serveur génériques s'appliquent à n'importe quel modèle : à restreindre par les droits.
Identité technique
Les dix-sept modules viennent du dépôt OCA server-backend, branche 18.0 — dont tous les modules sont désormais documentés ici. Dix sont en AGPL-3, sept en LGPL-3. Les dépendances : base pour la plupart, base_user_role pour ses quatre extensions, base_import pour la correspondance d'import, portal pour les types de portail, base_automation pour la navigation, calendar, mail, web, web_editor et product selon le module.
Voir aussi droits utilisateurs et sécurité d'accès et exports SQL et indicateurs.
Questions fréquentes
Peut-on savoir exactement ce qu'un utilisateur Odoo peut faire ?
Pas avec un écran standard : les droits résultent du cumul de ses groupes, de leurs héritages, de leurs droits par modèle et de leurs règles d'enregistrement. base_user_effective_permissions permet d'inspecter les droits effectifs — le résultat, non la liste des groupes. C'est le module à installer avant toute revue de droits.
Quel intérêt des rôles par rapport aux groupes ?
Organisationnel : « comptable » est un rôle, et personne ne sait quels sept groupes il contient. Attribuer un rôle rend l'arrivée d'un salarié reproductible et son départ vérifiable. base_user_role les crée, avec une déclinaison par société, un historique des changements et des profils. Les rôles s'ajoutent aux groupes, ils ne les remplacent pas.
Comment éviter de créer des doublons en réimportant un fichier ?
base_import_match définit, par modèle, sur quels champs reconnaître un enregistrement existant — numéro de TVA, référence interne, code client. Sans lui, réimporter un fichier corrigé crée une seconde fois tous ses enregistrements. Attention : une correspondance mal définie fusionne des enregistrements distincts, ce qui est pire qu'un doublon.
Peut-on interroger une base de données externe depuis Odoo ?
Oui : base_external_dbsource fournit un cadre de sources de bases externes avec trois connecteurs, et base_external_system un cadre plus général. C'est le pont vers un logiciel métier qu'on ne remplace pas, et la brique dont dépendent les indicateurs calculés sur base externe. Sortez les identifiants de la base.
Peut-on exposer un planning Odoo dans l'agenda d'un collaborateur ?
Oui, avec base_ical, qui fournit des adresses de calendrier en lecture seule pour les modèles de type agenda — interventions, congés, livraisons. Vérifiez qui peut connaître cette adresse : elle expose des données sans authentification.
Se faire accompagner
La gestion des droits est le domaine où une instance se dégrade le plus silencieusement : chaque demande ponctuelle ajoute un groupe, personne ne retire jamais rien, et au bout de trois ans la moitié des utilisateurs peut tout faire. Deux modules suffisent à reprendre la main : l'inspection des droits effectifs et les rôles.
Nous commençons donc par un état des droits effectifs — qui révèle presque toujours des surprises — puis nous reconstruisons par rôles, avec leur historique. C'est aussi ce qu'un audit ou un assureur demande. Voir les prestations d'Atalios Consulting ou demander un rappel.
Pour aller plus loin
En résumé
Les droits d'Odoo s'accordent par groupe, et un utilisateur en cumule facilement quinze. Personne ne sait plus ce qu'il peut faire : l'administrateur coche et espère. Dix-sept modules rendent les droits lisibles et gérables par rôles. Parlons de vos droits d'accès.
