ofbiz-framework issueshttps://labs.nereide.fr/10031/apache/ofbiz-framework/-/issues2023-12-01T10:08:14Zhttps://labs.nereide.fr/10031/apache/ofbiz-framework/-/issues/23Récupération main menu avec id webapp (5)2023-12-01T10:08:14ZGil PortenseigneRécupération main menu avec id webapp (5)OFBIZ-10601OFBIZ-10601la repriseNicolas MalinNicolas Malinhttps://labs.nereide.fr/10031/apache/ofbiz-framework/-/issues/113Généraliser et remonter la gestion des flux2023-01-26T08:13:59ZGil PortenseigneGénéraliser et remonter la gestion des fluxL'outil de gestion des flux de Decathlon permet de visualiser et régénérer le traitement de commEvents pour l'envoi de données.
L'objectif est de faciliter la maintenance des échanges de données entre OFBiz et l'applicatif externe. Que ...L'outil de gestion des flux de Decathlon permet de visualiser et régénérer le traitement de commEvents pour l'envoi de données.
L'objectif est de faciliter la maintenance des échanges de données entre OFBiz et l'applicatif externe. Que ce soient les flux entrant ou sortant.
Deux possibilités :
* La gestion de envoi et réception de flux de manière asynchrone
* La reception d'un flux créé le commEvent avec le content associé, sans traitement ultérieur
* Le traitement d'un flux entrant se fait dans un second temps pour logger les erreurs et permettre l'analyse.
* La génération d'un flux sortant se fait classiquement
* L'envoi du flux sortant, peut etre précédé d'un service de contrôle validant la donnée envoyée.
* La gestion de flux synchrone :
* L'execution de l'envoi se fait de manière synchrone, un commEvent et content est créé pour logger l'envoi et permettre son réenvoi
* Le log de la reception se fait directement post traitement, à l'instar de l'envoi.
L'outil ne doit pas gérer l'ensemble des commEvent OFBiz. Il faut donc définir un discriminant pour les commEvent à suivre.
L'outil permet de gérer ce commEvent :
* Recherche un flux
* Replanification d'un flux sans modification
* Replanification avec modification (régénération de content)
Le flux généralisés, supportés sont :
- les mails à suivres avec PJ (génération de PJ sur un content)
- flux ftp
Avoir un service d'alimentation d'un mail à suivre/ftp à générer.
Avoir un job de traitement des commEvent simplifié. Pour planification de leur envoi (ou voir si les jobs standards font le taf)
**Tâches :**
- [x] Description globale de la tâche
- [ ] Definition des cas d'usages
- [ ] Définition de nouveaux types de commEvent
- [ ] Définition cas d'usage mail (idées de flux à suivre, autour d'une commande)
- [ ] Reprise des écrans
- [ ] Recherche de commEvent sous-type créés
- [ ] Liste des commEvent et content associés
- [ ] Services
- [ ] écriture de service de création de commEvent
- [ ] écriture de job de traitement de commEvent
- [ ] écriture de service de replanification de commEvent
Pad (brouillon collaboratif) du ticket:
https://pad.libre-entreprise.org/p/nereide_communautaire_113
**17 septembre 2019 : Le besoin exprimé par Pierre est plus simple que celui implémenté chez Decathlon :**
Logger les appels WS et leur retours de certains services dans des commEvents afin d'avoir des quantités chiffrés d'erreur, et de produire des analyses cas par cas.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
L'idée : de manière spécifique définir un service qui sera branché en écoute sur le serviceEngine (ou en seca sur les services à analyser) qui va :
* Vérifier (dans le cas `serviceEngine`) le fait que ce service est paramétré par `systemProperty` pour être loggé
* Créer un commEvent en enregistrant
* Dans un content les paramètres d'entrées de service sérialisés.
* Dans le status du commEvent : le code retour succès ou erreur
* Dans un autre content les données retournées préfixé du code retour exact, et éventuellement du header
* Dans le contactMechIdTo : une référence vers un contactMEch de type `webService` indiquant le endpoint contacté
* Dans le partyIdFrom l'acteur émetteur de l'appel
* Dans le partyIdTo l'acteur destinataire (identifié du header et du sens de l'appel in/OUT)
Cela fait on peut logger de manière paramétrable les services désirés.
Les données sauvegardées sur le commEvent permettent son rejeu, à coder de façon spécifique...
Reste a voir si c'est remontable/justifiable auprès de la communauté.la repriseGil PortenseigneGil Portenseignehttps://labs.nereide.fr/10031/apache/ofbiz-framework/-/issues/133Fix multi modal opening2020-05-25T16:09:11ZGil PortenseigneFix multi modal openingWhen opening a modal with a lookup, closing it and opening it again, this error happens :
To reproduce :
The issue is that when closing the modal the div inside html dom is not removed. Then opening a second time create another ident...When opening a modal with a lookup, closing it and opening it again, this error happens :
To reproduce :
The issue is that when closing the modal the div inside html dom is not removed. Then opening a second time create another identical div.
Since a lookup is based on an unique id, this id is no more unique...
Attached patch fix the issuela reprisehttps://labs.nereide.fr/10031/apache/ofbiz-framework/-/issues/136Eviter les erreurs dans les logs au premier chargement des web.xml2020-05-25T16:09:11ZPierre GaudinEviter les erreurs dans les logs au premier chargement des web.xmlla reprisePierre GaudinPierre Gaudinhttps://labs.nereide.fr/10031/apache/ofbiz-framework/-/issues/125Simplification du deploiement d'OFBiz2020-03-17T07:52:28ZMathieu LirzinSimplification du deploiement d'OFBiz## Problème
Actuellement le déploiement d'OFBiz doit se faire en livrant à la fois un Jar et un dossier contenant les sources XML/Groovy/Freemarker.
```mermaid
graph LR
A[ofbiz.jar] -->|classes| B(Production)
C[root directory] ...## Problème
Actuellement le déploiement d'OFBiz doit se faire en livrant à la fois un Jar et un dossier contenant les sources XML/Groovy/Freemarker.
```mermaid
graph LR
A[ofbiz.jar] -->|classes| B(Production)
C[root directory] -->|config/XML/FTL| B(Production)
```
Cette façon de procéder a 3 incovénients majeurs:
1. Ne s'intègre pas avec le mécanisme de gestion de dépendances de la plateforme Java basé sur la distribution de Jar.
2. Complexité de procédure de déploiement en production.
3. Charge mentale inutilement importante pour se représenter comment un fichier présent dans les sources est récupéré (système de fichier?, classpath?, un peu des deux?)
## Proposition
La solution envisagé consiste a donc distribuer l'ensemble des fichiers requis au lancement d'OFBiz dans `ofbiz.jar` et d'accéder aux fichiers en utiliser [le mécanisme de resource de l'API Java](https://docs.oracle.com/javase/8/docs/technotes/guides/lang/resources.html).
```mermaid
graph LR
A[ofbiz.jar] -->|classes/config/XML/FTL| B(Production)
```
## Tâches
Cette solution impose un travail important nécessitant de réaliser les étapes suivantes:
- [x] Rajouter dans le [build.gradle](build.gradle#L267) l'ensemble des fichiers
- [X] Schémas XML (`.xsd`)
- [x] Templates FreeMarker (`.ftl`)
- [x] Scripts Groovy (`.groovy`)
- [x] Scripts minilang (`.xml`)
- [x] fichiers de définition des composants/services/entités (`.xml`)
- [ ] Trouver une solution permettant de charger un composant OFBiz à partir d'un Jar
- [ ] Trouver une solution pour gérer les propriétés de configurations en permettant leur modification sans avoir à modifier les fichiers `.properties` du framework.
- [ ] Adapter la résolution de fichiers pour utiliser le classpath par défault
- [ ] Adapter la résolution des URL type `component://example/`
Il y a une issue ouverte sur Jira: [OFBIZ-11161](https://issues.apache.org/jira/browse/OFBIZ-11161)la repriseAntoine OuvrardAntoine Ouvrardhttps://labs.nereide.fr/10031/apache/ofbiz-framework/-/issues/3Les représentations JSON ne sont pas générés par le moteur d'affichage2020-03-17T00:53:13ZMathieu LirzinLes représentations JSON ne sont pas générés par le moteur d'affichagePour avoir une sortie de service en format JSON, OFBiz fournit un gestionnaire d'événements `jsonResponseFromRequestAttributes` associé à l'URI `json` permettant de rediriger le résultat du premier service vers ce gestionnaire.
Il parai...Pour avoir une sortie de service en format JSON, OFBiz fournit un gestionnaire d'événements `jsonResponseFromRequestAttributes` associé à l'URI `json` permettant de rediriger le résultat du premier service vers ce gestionnaire.
Il parait plus approprié d'avoir un type de gestionnaire de vues dédié au rendu en format JSONla reprisehttps://labs.nereide.fr/10031/apache/ofbiz-framework/-/issues/130Amélioration de createLogDirectoryIfMissing pour la création des journaux2020-03-17T00:40:15ZGhost UserAmélioration de createLogDirectoryIfMissing pour la création des journauxSi le dossier de journalisation n'existe pas ou qu'il ne possède pas les bons droit il faut passer en mode défault "runtime/logs"Si le dossier de journalisation n'existe pas ou qu'il ne possède pas les bons droit il faut passer en mode défault "runtime/logs"la reprisehttps://labs.nereide.fr/10031/apache/ofbiz-framework/-/issues/93Amélioration: Ajouter les communications de commandes2019-10-04T12:54:44ZNicolas MalinAmélioration: Ajouter les communications de commandesVoir sur le projet decath:
On ajoute une liste de communications liés a la commande sur la page de detail d'une commande (orderview) afin de suivre les demandes mails/telephone/etc liées a la commande
Le code se trouve sur PRO20200
htt...Voir sur le projet decath:
On ajoute une liste de communications liés a la commande sur la page de detail d'une commande (orderview) afin de suivre les demandes mails/telephone/etc liées a la commande
Le code se trouve sur PRO20200
https://labs.nereide.fr/10923/PRO20200
Add a discussion feature in order detail view for following communication about the order (mail, phone etc.)
![orderComm1](/uploads/532a36f5ecff4f162f1962bbc462b49a/orderComm1.png)
![orderComm2](/uploads/d279bdefbace9a9586804e1e5389f8fd/orderComm2.png)
![orderComm3](/uploads/0f5018133d083f3fd7eee167fa3f0cb7/orderComm3.png)la reprise