Permissions Dolibarr
Knot s’appuie sur les permissions natives Dolibarr. Un utilisateur ne peut pas contourner un refus ERP via un workflow, même si le graphe est bien conçu.
🔐 Rôles Knot
Dans Knot → Permissions (ou via les groupes Dolibarr selon ta version) :
| Permission typique | Effet |
|---|---|
| Lire les workflows | Voir les définitions |
| Créer / modifier | Éditer le canvas |
| Activer / désactiver | Passer en production |
| Lancer un run manuel | Bouton Run |
| Administrer credentials | Gestion des secrets chiffrés |
Attribue le minimum viable : un métier peut modifier un workflow sans toucher aux credentials.
🔐 Matrice rôles × actions Dolibarr
Chaque node Dolibarr vérifie les droits de l’utilisateur d’exécution :
| Action node | Droit Dolibarr équivalent |
|---|---|
| Get / List | Lecture objet |
| Create | Création |
| Update | Modification |
| Delete | Suppression |
Exemple : un compte « commercial » sans droit de suppression ne doit pas être utilisé sur un graphe avec Delete facture.
🔐 Multi-entité
- Les workflows et runs sont scopés à l’entité courante.
- Un admin multi-sociétés doit changer d’entité avant d’éditer ou de lancer.
- Les triggers object event héritent de l’entité de l’enregistrement déclencheur.
Voir aussi Connecteur Dolibarr.
🔐 Compte technique pour Cron
Pour un trigger Cron, définis quel utilisateur Dolibarr exécute le run (service account) :
- rôle dédié
[email protected]; - droits stricts (lecture facture OK, admin interdit) ;
- mot de passe rotatif et credential séparés des humains.
🔐 Audit
Les opérations sensibles (activation, export, accès credential) laissent une trace dans le journal d’audit Knot côté admin. Corrèle avec les logs runs pour une enquête incident.