Après six mois de développement, la version 4.0 de Tryton est sortie. Tryton est une plate-forme de développement d'application pour entreprise (progiciel de gestion intégré/PGI/ERP) sous licence GPL-3+. Grâce à son ensemble de modules qui grandit à chaque version, elle couvre de base bon nombre de besoins de l'entreprise. Et ceux qui seraient manquants peuvent être comblés grâce à son architecture modulaire.
C'est la première version compatible avec Python 3 pour la partie serveur. Cette version inclus également une réécriture de la pile réseaux en se basant sur Werkzeug comme bibliothèque WSGI ce qui permet d'utiliser l'ensemble des serveurs WSGI et ainsi d'utiliser d'autres designs que le processus multi-thread. Deux nouvelles langues font leur entrées: le lao et le chinois simplifié.
Comme d'habitude la migration depuis les versions précédentes est supportée de base.
Sommaire
Les clients
Pour rappel, Tryton possède 3 clients légers différents:
- Un client natif utilisant GTK+;
- Un client web basé sur jQuery et Bootstrap;
- Une bibliothèque Python.
Le client GTK+ écrit en Python n'est pas encore compatible Python 3, pour cela il faut attendre la migration à GTK+-3.
Les notes
Jusqu'à présent, des champs texte pour les commentaires étaient ajoutés sur les documents pour lesquels le besoin se faisait sentir. Mais ce n'était pas une solution efficace car s'il manquait sur un document, il fallait l'ajouter avec du code. Une solution générique a été développée en se basant sur le même principe que les attachements. Il est maintenant possible d'ajouter un commentaire sur n'importe quel enregistrement. De plus le système garde une trace par utilisateur des notes déjà lues et présente une notification quand une nouvelle note est disponible.
L'import/export CSV
L'import/export CSV a été retravaillé pour une meilleur expérience utilisateur. La fenêtre d'import permet maintenant d'ordonner les colonnes par Drag & Drop. Il est possible de choisir le codage parmi l'ensemble de ceux fournis par Python. La fenêtre d'export a maintenant les mêmes options CSV que celle de l'import.
À noter que cette fonctionnalité n'est pas encore présente sur le client web mais un étudiant a été sélectionné pour travailler dessus dans le cadre du Google Summer of Code.
Édition de contexte
Le contexte de lecture des enregistrements d'une vue peut à présent être modifié par l'utilisateur. Pour ce faire un formulaire est placé au dessus de la barre de recherche. Les valeurs de ce formulaire sont utilisées pour mettre à jour le contexte. Le formulaire est défini simplement par un ModelView, il hérite donc de toutes les fonctionnalités des formulaires de Tryton (évènements, contraintes, dynamisme, etc.).
Cette technique a été mise en pratique sur les rapports comptables comme le grand livre comptable. Cela a permis de supprimer le wizard d'ouverture et donc de rendre les rapports plus dynamiques. Dorénavant ces rapports étant basés sur les vues standards, l'utilisateur peut utiliser le moteur de recherche ; on évite aussi ainsi de les imprimer si on ne fait que les consulter.
Graphique
Les graphiques du client GTK+ ont été retravaillés afin d'être encore plus lisibles. Ils utilisent maintenant des couleurs plus claires, des lignes plus fines et des bords arrondi plus fins. En arrière plan, les axes sont représentés par des lignes pointillées. Et quand les lignes sont remplies, elles le sont avec une couleur suffisamment transparente pour voir les autres.
Le serveur
Le serveur est maintenant compatible Python 3 en plus de Python 2. Le plan est de fournir les deux versions de Python pendant une phase de transition (probablement jusqu'à la fin du support de Python 2 en 2020) grâce à l'outil 2to3. Pour garantir le bon fonctionnement sur toutes les versions de Python, les tests sont lancés systématiquement grâce à tox sur toutes les versions: 2.7, 3.3, 3.4 et 3.5.
Cependant quelques modules n'ont pas encore pu migrer à Python 3 à cause de dépendances non compatibles. C'est le cas des modules qui utilisent le protocole WebDAV et du module d'authentification par LDAP (ce sera corrigé pour la prochaine version).
Transactions
La gestion des transactions a été revue afin d'être plus proche de la PEP-0249. Elle permet d'avoir des transactions imbriquées ainsi que plusieurs curseurs sur la même transaction. Cette dernière possibilité réduit la consommation mémoire quand on itère sur une requête générant un très large résultat.
Le serveur reçoit le support du protocole two-phase commit qui permet de gérer les transactions distribuées. Le développement est basé sur l'API des data managers de Zope.
Ce protocole est important quand on veut communiquer avec un autre système de manière transactionnelle. Par exemple, un manager d’envoi de courriel transactionnel est maintenant inclus de base. Ce qui permet de garantir l'envoi de courriel uniquement si la transaction de la base de données est réussie.
Convention de nommage
Un convention de nommage pour les identifiants des documents a été adoptée. Le champ « code » est réservé pour les documents faisant partie du référentiel comme les tiers ou les produits. Le champ « numéro » est utilisé pour les documents de l’opérationnel comme les factures, les ventes ou les achats. Et enfin, le champ « référence » sert pour enregistrer des identifiants venant de système externe. Tous les modules ont été passés en revue afin d'assurer leurs cohérences.
Compatibilité
En plus de la refonte des rapports, une date est enregistrée sur les réconciliations. Par défaut, c'est la plus grande date des lignes réconciliées. Ceci permet entre autre de générer à posteriori le fichier FEC avec les bonnes informations sur les réconciliations, mais aussi de sortir la balance âgée pour une date dans le passé. La balance tiers a été incorporée dans la balance âgée puisqu'elle calculait le même montant quand on groupe les clients et les fournisseurs.
Référentiels
Il est maintenant possible d'enregistrer un tiers sans connaître son nom. C'est très utile pour enregistrer des opportunités au plus tôt.
Les vues des modèles et des variantes des produits ont maintenant quasiment le même design puisque l'une étend l'autre. Ceci a été possible grâce à un mécanisme qui crée automatiquement sur les variantes des champs fonctions pour ceux manquants par rapport aux modèles. Ceci enlève la confusion que certains utilisateurs avaient quand ils ouvraient le formulaire d'une variante qui était plutôt vide.
Les produits peuvent maintenant être placés dans plusieurs catégories. Une utilisation possible est par exemple la catégorisation multi-axes pour un site d'e-commerce. Ils peuvent aussi être classés dans les différents systèmes de classification. Tryton possède de base pour l'instant uniquement la classification taxonomique avec les taxons et les cultivar.
Production
Une partie du travail s'est aussi portée sur la production par l'ajout de deux nouveaux modules :
production_routing
Ce module ajoute la gestion des gammes, des étapes et des opérations de production. Il permet de décrire à l'utilisateur comme réaliser un ordre spécifique de production étape par étape.
production_work
Ce module ajoute la gestion des postes de charges. Il permet d'enregistrer par travail le nombre de cycles utilisés par production et ainsi calculer un coût de production basé soit sur le nombre de cycles, soit sur la durée. Les ordres de production sont répartis sur des lignes de productions qui sont représentées par une arborescence de postes de charges. Quant aux travaux, ils sont assignés aux postes de charges de cette ligne en fonction de la compatibilité entre l’opération et la catégorie du poste.
Aller plus loin
- Tryton (731 clics)
- Annonce (154 clics)
- Démo : login = demo_fr et mot de passe = demo (600 clics)
# Python 3
Posté par Victor STINNER (site web personnel) . Évalué à 6.
Ça fait plaisir de voir de grosses applications qui supportent Python 3. Bravo ! ;-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.