Cet espace est communautaire et est basé sur les contributions de chacun. N'hésitez pas a créer de nouveaux documents en suivant les bonnes pratiques.
Evolutions futures
Les évolutions de Neogia ne sont pas planifiées par un service Marketing central, mais par les différents partenaires intégrateurs de Neogia en fonction des contrats clients qui sont en cours de signature ou qui sont signés.
Aujourd'hui, tous ne pensent pas à indiquer le détail des réalisations à venir, mais cette page est là pour les y encourager.
Pour les partenaires Certifiés, publier les futures réalisations leur permet de gagner des points de contribution.
Contents
|
Les Reflexions
Ce chapitre correspond aux idées des uns ou des autres, pas forcément complétement abouties, mais cela permet de mettre en commun ces réflexions.
Au-delà de 3-4 lignes, il est recommandé de faire une page par fonction.
Evolutions futures des générateurs
-
le générateur des entity ofbiz doit générer juste les extend[kguerin] - disposer d'un getteur pour toutes les attribues y compris ceux permettant de faire le lien avec d'autre entity
-
revoir la génération du nom des attribues à partir du nom des primaryKey pour les associations[kguerin & bjansen] - gestion de l'héritage dans une même table
- dans les tests d'existance, juste avant un update, mettre dans le message l'élément n'existant pas. Par exemple partyRoleNoteExist doit avoir deux variables partyId et roleTypeId pour connaitre les données qui pose pb.
- supprimer toutes les warning des fichiers java générés
Gestion du Help
- edition d'élément de contenu associé à un écran ou une entité
- permettre la saisie de lien entre élément de contenu
- pouvoir faire une extraction des éléments de contenu de type help de manière à stocker les éléments saisies en fichier xml et pouvoir les intégrer dans un cvs et ainsi pouvoir faire des merges.
Screen paramétrable à partir du menu
- ajouter des balises dans la definition d'une option de menu permettant de positionner des variables lors de l'appel du screen associé
Ecran Générique paramétrable au niveau menu
- party, client, fournisseur, ...
- relation entre acteur
- paramétrage integration, association 1:1
- effacement du cache
- enumeration
- gestion des attribues complémentatire en fonction du type
- attribues complémentaires en fonction du type
- roletypeRollup
- content
- lookupParty avec parametre
- nouvelle écriture à partir d'une existante (dupliquer)
Surcharge des form ou des menu
- gestion de l'héritage entre fichier xml pour pouvoir surcharger ou remplacer
- pouvoir utiliser un élément de contenu en tant que qu'élément de fichier xml
- surcharge de form.xml en fonction d'un paramétrage utilisateur
- surcharge de menu.xml en fonction d'un paramétrage utilisateur
- WUP + codification d'une chaine de caractère en tant que chaine comprimé
Ré-organisation de l'ergonomie
- définition des types d'écran
- définition des fonctions dojo utilisable
- usage des menu
- performFind qui gére l'opérateur in avec des cases à cocher (pour les statuts, en autre)
- dans la définition de form (surtout pour le type list) il faut pouvoir définir un drop-down d'action (comme dans les listes neogia actuel, articles et commande)
- affiner l'attribue event et action de field dans les forms pour associé une action javascript
Commentaire sur les services
- ajout de balise pour ajouter de la doc et des mots clés
- affichage de la doc dans la page listant les services
- chargement en tant que description du service, la javadoc si c'est un java
Définition & Utilisation des view
- ajouter une balise contrainst dans les view, cela permettrais d'avoir un usage plus simple, par exemple sur les enumérations, ou pour des vues complexes
- ajouter une balise dynamic-entity-condition dans les screens, pour éviter de définir dans les fichiers view des vue utilisé une seule fois
- lors de l'affichage d'une view dans webtools, ne prendre que les champs avec groupBy="true" s'il y en a au moins 1
- ajouter dans webtools une recherche sur les view, pouvoir saisir n entity et à chaque saisie (de plus en plus restrictif) cela affiche uniquement les vues qui utilisent les entitées sélectionnées.
SQL processor
- Ajouter une gestion de requête enregistrés (via content) pour pouvoir enregistrer la requête courante ou rappeler une requête précédente.
Balise run-install-default
- équivalent au run-install-seed mais avec des données par defaut minimum pour être utilisable
Les évolutions de modèles
L'objectif est d'utiliser au mieux les entités OFBiz, et de clairement définir les plus apporté par Neogia
- au niveau des entités associées à Company remplacer les héritages de JuridicClassification, CommercialSign, CommercialNme, Nes vers Enumeration par un héritage vers PartyClassificationGroup
Généralité entre Modéle OFBiz et Neogia
- nom du package au plus haut niveau est ofbiz ou neogia selon la solution
Facility
Différence entre OFBiz et Neogia
- Le package Facility n'existe pas dans ofbiz c'est des sous composants de Product
- Le sous-composant (package) location de Neogia correspond à des parties des packages storage et inventory
Migration des entités Neogia vers le modéle OFBiz
- remettre les entités dans le sous-package de ofbiz
- Facility: location -> storage
- ..
- migrer NFacility vers Facility
Evolution d'ergonomie
Ecran types
Gestion des menus
Il faut avoir l'interface ofbiz standard et la nouvelle selon l'utilisateur.
Il faut pouvoir avoir des menus spécifiques pour un groupe d'utilisateur
Il faut un menu qui soit paramétrable par l'utilisateur
Ecran spécique Neogia
Gestion de commande Back-End
Il faut un enchaînement d'écran spécifique à Neogia (process B2B) et au besoin possibilité de choisir un type d'écran lors de la saisie (genre choix multiple avec valeur par défaut)
Gestion des receptions
Reprendre les écrans ofbiz comme base, en profiter pour vérifier s'il est toujours nécessaire de faire des copies de fichier shipment ofbiz vers Neogia
Les propositions
Ce chapitre correspond aux fonctions qui ont été en partie analysées, (au moins chiffrées) pour être insérées dans une proposition commerciale.
Pour certaines, la réponse du prospect est en attente, pour d'autres, la proposition commerciale n'a pas été acceptée mais si demain quelqu'un est interressé, le chiffrage est déjà disponible.
Dans le cadre d'un processus de formation, cela peut permettre de réaliser quelque chose qui a été demandé et donc qui sera sûrement utilisé ;-)
Extension du configurateur de produit
Configurateur d'offre
Extension de la gestion des devis
Les développements à venir
Ces fonctions font partie d'un plan projet client. Si vous souhaitez participer à ce développement (sur le plan financier) vous pouvez contacter le partenaire pour pouvoir inclure des spécifications complémentaires, mais avant cela, une évaluation financière de ce complément est faite.
Dans certains cas, certaines fonctions seront réalisées dans le cadre de Projet de fin d'études étudiant, donc avec un délai plus long et un résultat pas forcément garanti ;-) il n'y a pas de recettage client.
Intégration d'un outil OLAP (Mondrian + Jpivot)
Etat d'avancement: intégration compléte du moteur OLAP, avec une navigation dans un tableau croisé dynamique.
Travail A faire: intégration de la gestion des diagrammes
