Bonjour tout le monde,
pour mes besoins perso j’ai commencé à me faire une commande « dolibarr » (sur le même principe que la commande occ chez nextcloud ou php artisan sur les projets laravel).
L’idée est de pouvoir rapidement en ligne de commande faire « des trucs » d’admin de dolibarr … par exemple pour remettre un mot de passe à un utilisateur
est-ce que c’est un besoin partagé, en ce cas on utilise un bout du wiki pour lister / documenter les besoins et ensuite on envoie une PR dans le coeur de dolibarr ou bien c’est un truc dont personne n’a besoin et ne perdons pas de temps avec ça ?
Une cli Dolibarr me paraît très pertinente, notamment pour des tâches d’administration récurrente sans se tordre les neurones avec l’API.
Je veux bien te suivre là-dessus.
Ok, alors avant d’aller polluer le wiki du projet je vous propose de faire la liste des courses ici (listez toutes les actions qui vous semblent utiles à implémenter)
De mon côté, j’utilise beaucoup tous les scripts d’installations, puis le script de @dev2a pour la désactivation/réactivation des modules actuellement.
Quelle grande idée. Cela m’intéresse de collaborer. Normalement, j’administre une vingtaine de Dolibarr sur mon propre serveur et depuis un moment, je ressens le besoin de quelque chose comme ce que tu décris.
Dans mon cas, ce qui m’intéresserait beaucoup, ce serait de pouvoir ACTIVER/DÉSACTIVER des modules depuis la console ! Parce que lorsque je dois mettre à jour un module sur toutes les instances, j’ai automatisé la copie des fichiers physiques (PHP) dans le répertoire « /custom », mais je dois me connecter à chaque instance (nom d’utilisateur + mot de passe + 2FA) en tant qu’administrateur pour désactiver le module et le réactiver !
Donc, je serais ravi de rejoindre le projet et de travailler sur l’activation/désactivation d’un module
Mais j’avoue que j’avais un peu la « flemme » de chercher comment faire la partie intégration avec Dolibarr depuis le terminal TOUT EN PRÉSERVANT LA SÉCURITÉ DU SYSTÈME. C’est-à-dire, je sais que Dolibarr a déjà son système d’APIs et que chaque utilisateur a même une clé API (que tu peux obtenir depuis ta fiche utilisateur). Mais pour être honnête, je n’ai pas eu le temps d’enquêter sur la façon dont cela pourrait être intégré dans une commande de type « occ »
Petite amélioration du jour, vous allez me dire qu’il y a peut-être une autre solution mais bon …
Voici un dolibarr qui change de comptable et le nouveau comptable demande à avoir une codification des codes comptables de tiers différente de celle qui était appliquée jusqu’alors.
Je n’ai pas trouvé comment réappliquer les codes aux clients existants lorsqu’on modifie le modèle de numérotation dans la configuration du module Tiers !
En bref lorsque je modifie Digitaria ça s’applique aux tiers créés après la modification mais pas aux anciens, ce qui est tout à fait justifiable mais dans notre cas particulier nous aimerions pouvoir le faire.
Et hop voici une bonne occasion de contribuer à dolibarr-cli … un exemple ci dessous du script lancé sur un dolibarr dont certains clients n’avaient pas de code comptables :
root@dolitests:~/dolicli# DOLPATH=/var/www/dolibarr-18/htdocs/ php8.2 ./dolibarr thirdparty accountingnumber
Update accounting number for all dolibarr thirdparties according with dolibarr setup rules
name code_compta_old code_compta_new
EricTest01 411ERICT
IFRTO 411IFRTO
LNST 411LNST
LGTOIP 411LGTOI
O'Plic ploc 411OPLIC
Asso. AbulEdu-FR 411ABEFR
.../...
on garde ou on jette (en bref je commit sur le dépôt cette contribution ou pas) ?
J’ai eu presque le même cas ! J’ai opté pour le mode démerde…
J’ai exporté tous les tiers, une formule de formatage dans Excel/Calc, ajout d’une colonne avec un calcul pour vérifier s’il y avait pas des doublons puis réimportation dans Dolibarr.
Ok, @bfaliere et autres contributeurs je me dis qu’il faut dès à présent choisir une sorte de hiérarchie / nomenclature des actions / opérations
→ comment faire ? une page wiki où on indique la hiérarchie des commandes ?
d’autre part je me dis qu’à la lumière de cet exemple on aura en fait parfois besoin de « bricoler le script avant de le lancer » c’est une grande force du logiciel libre et je vois de plus en plus dolibarr-cli sous deux aspects : un qui est « prêt à l’emploi » (par exemple pour changer le mot de passe d’un utilisateur, commande déjà implémentée) et d’autres qui seraient « des fonctions à adapter selon la situation particulière » comme ce bout de code qui ré-affecte les codes comptables car j’ai déjà rencontré deux situations : une qui était qu’il fallait mettre un code comptable à tous les clients et l’autre qui était « mettre un code comptable aux clients qui n’en ont pas déjà un » … de ce fait j’ai modifié le code et j’ai ajouté une conditions dans la requête SQL (ou un test en php du genre if !empty(code))
→ comment faire ? du code qui ne serait pas « actif » et dont le message serait par exemple « please update app/Command/Thirdparty/AccountingnumberController.php and then run the command again » ?
Totalement ok pour la nomenclature. Pourquoi pas directement dans le readme ou un fichier dédié aux règles de dev ? Et discutable en issue au besoin.
Pour la seconde partie, je me dis qu’effectivement, ça peut être intéressant de faire une vérif sur l’existance d’une ligne (mais pénible à faire pour chaque version, sauf si on a le temps). Est-ce qu’on pourrait pas mettre un avertissement, donner l’info de la modif à faire, et demander validation avant de lancer effectivement l’action ? C’est quelque chose qu’on pourrait imaginer aussi dans le readme.
