|
| From: | Pascal Aubry |
| Subject: | Re: [Dolibarr-foundation-board] Installation wizard |
| Date: | Wed, 17 Aug 2011 12:10:25 +0200 (CEST) |
| Nom | Statut | Description | Reversement | Commentaire |
| Module de notes de Frais | stable sur 3.0.0 | rattachant chaque dépense à un projet | possible mais c'est une modification du module de N2F communautaire | Auteur : address@hidden Portage en 3.0.0 : address@hidden |
| Module de gestion des temps consommés | stable sur 3.0.0 | - Ajoute un onglet "temps consommé"dans agenda Dolibarr - Ajoute un formulaire de saisie des temps (lié aux projets) - Temps pré-remplie suite à saisie graphique dans le calendrier - Exploite les temps consommé de Dolibarr (pas d'ajout de table) | http://lists.nongnu.org/archive/html/dolibarr-dev/2011-04/msg00014.html rep. Laurent pas intégré mais notion Onglet dans l'agenda natif Dolibarr intégré dans la 3.0.0 Attention notre version actuelle a beaucoup évolué depuis cette tentative de reversement en avril | Auteur :address@hidden |
| Module de demande de congé payé | stable sur 3.0.0 | avec validation ou rejet et comptage des jours disponibles ainsi que d'un délais de demande avant l’événement - Ajoute un onglet CP dans l'agenda Dolibarr | Reversable (c'est en module) à porter en 3.1.0 | Auteur : address@hidden |
| Module de gestion des références | stable sur 3.0.0 | 1 à n ratachées à un projet, avec description de chaque référence, image ou logo, export en csv et pdf | Reversable à rendre générique et clean code pour reversement à porter en 3.1.0 | Auteur : address@hidden Portage en 3.0.0 : address@hidden |
| Module RH | en développement (avancement 70%) | permettant notamment d'ajouter au prévisionnel de trésorerie les salaires et charges - Gestion des contrat de travail (CDI, CDD, Apprentissage) - Gestion des coefficients - Gestion des arrêts maladie - Protection des données par chiffrage SSL et passphrase | à voir après fin du développement Dolistore ? Class Commondbtm.class.php issue du projet GLPI (non usuel "Généric Object" développé par Walid Nouh | Auteur : address@hidden et address@hidden |
| Module indicateur | stable sur 3.0.0 | - tableaux reprenant à colonnes mobiles, triables (dev. en ExtJS) : - Action commerciales - Proposition commerciales - Bons de commandes - Factures triées par statuts - Notes de frais - Graphiques (dev. JQuery, highcharts js) - indicateur CA - indicateur % produits - indicateurs staffing (données issues de la gestion des temps) - trésorerie - commandé - facturé | à rendre générique c'est stable c'est en module | Auteurs : address@hidden et address@hidden dépendance module CP et module RH |
| Patch ajout logo pour les tiers | stable sur 3.1.0 | Permet de mettre un logo pour chaque tiers (client, fournisseur) | reversé le 27 avril 2011 http://lists.nongnu.org/archive/html/dolibarr-dev/2011-04/msg00034.html intégré dans la 3.1.0 par Laurent | Auteur : address@hidden |
| Patch ajout signature personnalisé | stable sur 3.1.0 | Permet de personnaliser sa signature de pied de mail issues de Dolibarr pour chaque utilisateur | reversé le 9 mai 2011 http://lists.nongnu.org/archive/html/dolibarr-dev/2011-05/msg00039.html intégré dans la 3.1.0 par Laurent | Auteur : address@hidden |
| Patch pour | stable sur 3.0.0 | un patch pour Dolibarr 3.0.0 stable qui ajoute la possibilité de choisir le nombre d'heure par jour. (Fichier /lib/date.lib.php) Il faut ajouter la variable de configuration HOURS_BY_DAY avec pour valeur le nombre d'heures de travail par jour. Si la variable n'existe pas on laisse à 24 heures par défaut. Dans la partie Temps consommés d'une tâche (fichier /projet/tasks/time.php), ce patch ajoute un récapitulatif des temps consommés pour chaque personne sur la tâche. | reversé le 15 avril http://lists.nongnu.org/archive/html/dolibarr-dev/2011-04/msg00010.html | Auteur : address@hidden Portage en 3.0.0 : address@hidden |
Bonjour à tous,
Oui je pense effectivement qu'une réunion serait la bienvenue.
J'imagine Maxime, que je dois prendre pour moi : "Certains ont alors dérivé avec "ergonomie"" :)
Chez TECLIB' nous avons réalisé plusieurs ajout d'interface type tableaux ou graphiques basés sur ExtJS et JQuery que nous avons présenté à Laurent lors de Solutions Linux, cf screenshots ci-dessous. Je ne dis pas que c'est la solution à l'avenir, c'était pour répondre rapidement à nos besoins internes.
Je rejoint Cyrille sur "Pour une application modulaire, une couche MVC digne de ce nom est
indispensable. Mettre en place un système MVC n'est pas une histoire du puriste "
Réduire la complexité (et le temps de débug et maintenance du code) par subdivision et sérialisation du code est nécessaire dans une application ayant atteint un développent significatif mais elle doit obligatoirement être accompagnée par la constitution d'une documentation solide permettant de s'y retrouver (à plusieurs !) dans tous ces nouveaux morceaux.
Mais je pense comme Laurent qu'il faut rester le plus simple possible et ne pas réaliser une usine à Gaz, des étapes intermédiaires ou une séparation partielle pourraient donc être la bonne solution (entre Full MVC, Templating ou simple séparation de l'affichage et le traitement des données il y a de la marge).
Quoi qu'il en soit, je pense indispensable de garder un seul projet pour préserver la notoriété et la crédibilité de la solution. Je suis persuadé que nous pouvons nous entendre malgré les petits pics que je perçois ça et là.
Un projet libre et une aventure collaborative !
Bonne journée
pascal
Bien cordialement,
Pascal Aubry
Directeur TECLIB'
tél. : 01 79 97 02 78 mob. : 06 37 87 92 30 fax : 01 72 70 31 18
teclib' technologies libres au service de l'entreprise
----- Mail Original -----
De: "Jean Heimburger" <address@hidden>
À: "Régis Houssin" <address@hidden>
Cc: "Maxime Longuet" <address@hidden>, address@hidden, "Pascal Aubry" <address@hidden>, "Hervé Prot" <address@hidden>
Envoyé: Mercredi 17 Août 2011 07:55:56
Objet: Re: [Dolibarr-foundation-board] Installation wizard
Salut à tous,
Oui il faut une réunion pour éclaircir et trouver ue synthèse.
Le mail accentue toujours les positions et peut paraître plus violent et
dur que la réalité qui est exprimée.
Dans ce débat, il y a pas mal d'éléments à reprendre. Pour arriver à les
transformer en une synthèse, à partir de laquelle on peut prendre des
décisions puis lancer des actions. Il ne fautpas que la réunion soit
juste une tribune où les diverses positions se retranchent.
Alors, pour préparer, on devrait bien relire les différents messages, ne
pas s'arrèter à ce qui nous a peut être un peu agacé ou agressé, pour
prendre les idées exposées et pour chercher ce qui nous paraît important
et utile pour le projet dolibarr, son présent et son futur.
@+
Jean
Régis Houssin a écrit :
> mon message a été coupé suite à une mise à jour d'un logiciel open
> source qui c'est mis à jour ! (ça c'est pour la petite histoire...)
>
> Respect Maxime !
>
> Il sera bon de se parler de vive voix début septembre pour dissiper les
> diverses incompréhensions d'un dialogue de sourd mailisé...
>
> http://rdv.dolibarr.fr/meeting/showua/h/66h7m
>
> nous ferons le point à ce moment là car beaucoup de choses sont a
> prendre et à laisser dans toutes les situations et tous les sens du
> termes...
>
> Je tenais à m'excuser d'avoir lancé une polémique sur le sujet, parfois
> je suis dépassé par l'ampleur du projet et par les demandes des clients,
> c'est très compliqué de mixer les deux...
>
> Malgré la lenteur de conversion du code, je reste persuadé qu'un fork
> nuirait considérablement, à moyen ou à court terme, à la réputation de
> l'application.
>
> Nous allons trouver un compromis... c'est notre force !!!
>
>
>
>
>
>
> Le 16/08/11 20:14, Maxime Longuet a écrit :
>
>> Bonsoir,
>>
>> Je vous livre mon petit avis sur la question. Cet avis repose sur l'expérience d'autres développements ; je ne connais pas assez bien le coeur de dolibarr pour donner un avis tranché. Et je pense également que ce genre de point ne peut-être débattu par simple échange de mail.
>>
>> Les premiers mail étaient sur la mise en place d'un système de template. Sur ce point là je rejoint Laurent sur la difficulté d'un "Vrai" système de template pour la maintenance, le debugage : direction usine à Gaz assuré. Ce n'est pas pour rien que de nombreux logiciels open source ne disposent pas de système de template pour la partie BackOffice.
>>
>> Après il faut savoir ce qu'on appelle mise en place de "système de template".
>> - Est-ce qu'on parle ici d'un vrai modèle MVC ? Et là au secours... Les puristes seront contents, mais accrochez-vous en dev, faudra du gros niveau pour avoir des contributeur (cf magento).
>> - Ou simplement un peu plus de séparation dans des fonctions d'affichage de page ? Et là il y a peut-être des choses à faire et à mettre en place niveau box, construction de liste, tableau....
>> - La page facture.php avec ces 3200 lignes est effectivement un peu lourde à lire. Mais c'est plus dans la rationalisation du code et sortir peut-être certains bout dans les classes qu'on gagnera en lisibilité plus que dans la mise en place d'un template.
>>
>> Si on parle niveau design pour la mise en place de plus de compatibilité css. Jean a raison, le développement de dolibarr aujourd'hui n'empêche absolument pas d'améliorer le code html produit et de disposer de plus de souplesse dans les CSS. C'est pas parce qu'on aura un système de template que d'un seul coup on va voir des nouveaux design super sexy arrivés.
>>
>> Un point été soulevé sur les interfaces mobiles. Là je pense clairement qu'utiliser des css ou des simples template web distinct pour un accès mobile c'est un peu passé de mode. Si vous voulez profiter pleinement de l'interface d'un android, d'un iphone ou d'un ipad il faut développer en direct avec les SDK. Par contre continuer le travail du module web service avec son API SOAP permet de dialoguer avec le moteur de dolibarr, là ça devient intéressant pour développer une interface mobile. Et dans ce cas là il n'y a pas trop de duplication de code.
>>
>> Certains ont alors dérivé avec "ergonomie". Effectivement pas mal de point d'ergonomie peuvent être réfléchis et travaillé mais sans forcement le développement d'un socle MVC. Par exemple les tableaux avec des colonnes paramétrable : des solutions existent. Je pense comme cela rapidement à une class de génération d'un grid qui permet d'avoir des colonnes paramétrables. Ou encore la génération d'un grid avec un affichage via Json par une bibliothèque JS type EXT permet aussi de faire de la préférence de colonne suivant les choix de l'utilisateur... Pour l'exemple d'une ligne tronquée dans les tableaux je ne pense pas qu'il serait résolu avec un système de template.
>>
>>
>> Donc Je pense que ceux qui veulent faire une séparation et une mise en place d'un système de template expliquent techniquement à quoi ils ont pensé (MVC, smarty pour des boxes, smarty sur toute les pages, système de template fais maison, de simple classe de génération de contenue.... ). Et à partir d'une proposition technique détaillé, on pourra débattre sur ce point précis, car à partir de simples généralités on se retrouve à dériver et débattre en dehors de la proposition initiale.
>>
>>
>>
>>
>
>
> Cordialement,
>
| [Prev in Thread] | Current Thread | [Next in Thread] |