Cédric Krier a écrit 118 commentaires

Dans les trucs "faciles" à faire, tu peux afficher/masquer le menu de gauche en cliquant sur le Nom d'entreprise ("Tryton" dans la démo) ou le masquer en partie à la façon de Wordpress.

Le menu se cache automatiquement si l'écran est trop petit (« responsive »).

C'est un pis-aller à mon sens — rien ne vaut la simplification.

Mais le menu est un point crucial de l'application sans ça on ne sait rien faire dans l'application. Si on le cache, je suis sûr qu'on va être assaillis de questions d'utilisateurs qui ne trouvent plus rien.

Par exemple, Gmail ou Dolphin (kde) sont des bons modèles d'interface simplifié car ce qui sert moins est retiré de la barre d'icône et regroupé dans des menus "plus".

C'est parce que tu a utilisé l'utilisateur de demo qui a accès quasiment à tout. Normalement, un employé est affecté qu'à certain groupe et donc ne voit que les entrées de menu correspondantes (3-4 généralement).

Et aussi les onglets pourraient être plus haut (dans la navbar en haut de l'écran), pour créer de l'espace avec les icônes de l'onglet.

C'est une idée à creuser. « Patch is welcomed » ;-)

La sobriété de l'interface est essentielle pour qu'ils soient capable de "découvrir" (sans chercher donc) les fonctions utiles.

J'y ai repensé et je pense que probablement un des problèmes serait que la « toolbar » soit trop présente avec tous ces libellés. J'ai donc proposé une amélioration qui réduit sa présence: https://bugs.tryton.org/issue6120 (inclus screenshots).

Des thèmes ont déjà été publié comme https://github.com/coopengo/sao/tree/master/theme/coog

Il y a quelques années, oui, pour voir. On a abandonné après quelques semaines.

En quelques années, le logiciel a fortement évolué. Je pense que le résultat de cette expérience ne peut plus être prise en compte.

Un second groupe a refusé de s'y engager, car ils percevait plus les contraintes que les bénéfices.

Toutes les structures ne sont pas nécessairement prête à passer à un outil de gestion ou bien la solution ne convient pas à leur métier (généralement on arrive à adapter Tryton).

Mais il y avait un fort sentiment de perdre du temps à s'y retrouver et de ne pas être capable de savoir ce que le logiciel pouvait faire.

C'est certainement par manque de formation et peut-être d'une mauvais configuration. Quand on met en place Tryton, on fait une petite formation d'½ journée et alors les utilisateurs sont opérationnels et efficaces sur tous le système car il y a une vrai cohérence d'ensemble.

C'est difficile de mieux expliquer ce qui n'est que ressenti.

Pour moi, j'entends que c'est une question de goût et de couleur (qui ne se discute pas). Par contre, un point que je n'ai pas signalé, c'est que délibérément la charte graphique du client web est réduit au minimum. On utilise le thème par défaut plus quelques règles CSS pour avoir un comportement correcte. L'objectif est que les intégrateurs ajoutent un thème bootstrap ou personnalise l’existant et ceci est d'autant plus facile que l'on part d'une base de départ la plus neutre et simple.

Du côté de Tryton, on tente de soit réutiliser des librairies existantes (ex: python-stdnum) soit d'en créer (comme par exemple: relatorio pour la génération de document).
Mais bon après la valeur ajoutée d'un module vient principalement de son design et de son intégration avec le reste du système, des points qui sont fortement différents chez chacun.

L'ergonomie je la base sur les réactions des utilisateurs

Donc je suppose que tu a mis des utilisateurs devant Tryton. Ce serait bien d'avoir un retour de cette expérience. De notre côté, quand on fait des formations utilisateurs, on explique une fois les quelques concepts utilisés dans Tryton et c'est parti. Car Tryton reprend toujours les mêmes concepts pour tous ces interfaces graphiques.

La sobriété de l'interface est essentielle pour qu'ils soient capable de "découvrir" (sans chercher donc) les fonctions utiles

C'est vraiment étrange car généralement, on reçoit des remarques sur notre interface trop sobre.

Quant à là communauté qui mène quelque part, ça n'empêche pas de préparer une vision des choses qui sorte de la technique. Debian, Gnome, KDE, etc. en ont une. C'est dommage de ne pas en avoir.

Ben en fait, on en a une, c'est sur la première page du site: modularity, scalability and security

Je doute fort qu'une convergence soit possible car la modélisation des objets métiers est fort différente. C'est d'ailleurs un des points historique de la divergence avec Odoo. Pour ERPNext, leur système de module est complètement différent car principalement basé sur des «hooks».

Si tu trouve l'interface web lente, le serveur doit être certainement surchargé pour l'instant (en plus ce n'est vraiment pas un machine puissante).
Pour l'ergonomie, je te conseil de regarder l'application bureau car elle est à des années lumières de l'ergonomie des deux précédents (tout peut être fait au clavier). Après il faut voir comment tu compare l'ergonomie car si tu le fait comme Odoo en comptant les clics, on ne sera pas sur la même longueur d'onde. Par contre, nous trouvons qu'avoir des onglets augmente grandement la productivité des utilisateurs.
A propos de l'encombrement, de base Tryton n'affiche que le strict minimum. Évidement si tu la compare à celle d'Odoo, au moins Tryton affiche les données importantes. Par exemple quand on encode une vente, on montre l'unité de mesure de la lignes au moins.

Finalement, Tryton est développé sur un modèle différent des deux exemples. Par exemple, la où les développements d'Odoo sont dirigés par la société Odoo, Tryton évolue au gré des contributions de la communauté et donc Tryton ira là où la communauté le mènera…

Un système de plugin pour le support des hébergements est en cours de préparation: https://github.com/drone/drone/issues/381

drone.io est un service commerciale autour de drone qui d’ailleurs n'utilise pas tout à fait la même version que celle publiée sur GitHub.

Bien sur, toute contribution à qui implémenterait ces contraintes est la bienvenue. Comme la solution est modulaire, ce ne serait que des modules à activer ou pas.

Pour la France, je n'en connais pas mais il faut dire que GNU Health est focalisé sur les pays en voie de développement. Les pays comme la France ont généralement beaucoup de contraintes à respecter.
Pour la taille, 1000 lits ça ne doit pas être un problème comme c'est basé sur Tryton qui tourne dans des environnements bien plus volumineux.

Oui, ceux que je connais (car j'y ai participé à un certain niveau) sont:

• Le ministère de la santé de la Jamaïque: http://blog.gnusolidario.org/2013/09/jamaican-ministry-of-health-adopts-gnu.html
• le centre médical de réhabilitation du Laos: http://blog.gnusolidario.org/2015/09/gnu-health-in-laos.html

Alors ça ne sert à rien d'utiliser un « blockchain » si c'est limité à toi et le tiers de confiance.

Ça ne pourrait pas être fait par un blockchain ?

Et donc partager ta comptabilité avec tous le monde ?

Je te propose dans parler sur http://groups-fr.tryton.org/. Personnellement, je ne suis pas Français et donc je n'ai pas vraiment de moyen d'agir.
Sinon Tryton possède des contraintes qui empêchent l'utilisateur de modifier par exemple un mouvement comptable posté. Je ne pense pas qu'il soit possible de faire plus sans l'intervention d'un tiers de confiance comme le dit @oumph.

C'est un peu dur. Il y a une gestion de production mais qui , il est vrai, est un assez légère. D'ailleurs un travail est en court pour implémenter les « routing » et les « work ».
Pour le BI, Tryton peut afficher des graphiques ainsi que les lier à une sélection (un exemple est visible sur la demo dans « Feuille de présence / Rapports / Heures par travail ». Par contre, les requêtes doivent être définies dans le code (peuvent être générique grâce à python-sql).

Ce serait mieux d'utiliser cette bannier au lieu de celle du siteweb.

Pas nécessairement, ça s'applique si le code fermé n'est pas un travail dérivé sinon ce n'est pas une réalisation combinée. Et c'est ce qu'explique l'article que la notion de travail dérivé n'est pas lié à la technique utilisée (pour les tribunaux) mais plus sur l'incorporation et la similitude.
Tous ce que je veux dire c'est qu'il n'y a pas de règle générale mais que chaque cas doit être évalué.

La LGPL n'est qu'une extension de la GPL (6 clauses) qui ajoutent quelques exceptions pour les réalisations combinées.
Donc la grande majorité des commentaires de l'article s'appliquent aussi à la LGPL. Tu peux aussi chercher GPL ou encore mieux lire l'article.

Cet article par exemple: http://www.law.washington.edu/lta/swp/Law/derivative.html

Comme d'habitude une justification technique de développeur alors que l’interprétation d'une licence est un problème juridique.

Je pense qu'une mauvaise interprétation est dommageable pour l'ensemble de la communauté.
Peu m'importe la licence qu'utilise Odoo tant qu'elle est correctement appliquée.

Le cas du « framework » ne tombe pas sous le coup d'un travail dérivé vu son but généraliste.

La définition de l'application (ici "module") de la LGPL est:
« An "Application" is any work that makes use of an interface provided by the Library, but which is not otherwise based on the Library. »
Ça ne parle pas d'empaquetage mais de comment l'application repose sur la librairie.

Un module qui dépend d'un autre module est fort probablement un travail dérivé. Donc si le module parent est sous licence LGPL, le module enfant doit l'être aussi. La « viralité » de la licence pour la LGPL n'est pas liée à la technique mais au fait d'être un travail dérivé.
Il est possible d'avoir un module propriétaire sous Odoo si celui-ci n'est un travail dérivé d'aucun module LGPL.
En fait, si Odoo ne voulait pas cette contrainte, ils auraient du choisir une licence de type BSD/MIT et non LGPL.
Après, la notion de travail dérivé est difficile à juger et doit être analyser au cas par cas.

Sauf qu'Odoo SA interprète la licence LGPL comme une BSD/MIT ce qui n'est pas correct à mon avis.
Un module ne peut pas être sous licence propriétaire s'il est un travail dérivé d'un module LGPL.

Pour les mises à jour, il faut soit se débrouiller tous seul (avec l'aide possible de OpenUpgrade) soit il faut acheter le service de migration à Odoo SA via la contrat Enterprise et uploader sa base de données sur upgrade.odoo.com