[Dolibarr-dev] [BUG] création de DB MySQL - collate et charset
Bonjour, Je suis nouveau dans Dolibarr (pas en PHP) et en downloadant Dolibarr depuis CVS hier et en l'installant aujourd'hui, je remarque que la requête de création de table pour MySQL (mysql.lib.php, ligne 237) contient DEFAULT CHARSET et DEFAULT COLLATION, qui génèrent tous deux une erreur avec MySQL version 4.0.24 (default sur Debian Sarge on dirait). Pour finir l'install j'ai viré les deux et ça a très bien fonctionné mais j'ignore si ça va casser quelque chose plus loin, et de toutes façons ça ne devrait pas bloquer l'install, à moins que Dolibarr ne demande d'office MySQL 5 ou une version supérieure à 4.0.24 (?) Voilà, je ne sais pas comment vous résolvez les bugs généralement ni si vous avez un système de tracking et si vous l'utilisez, mais j'ai l'intention d'en signaler et d'en résoudre un paquet, alors je vous remercie de m'indiquer la meilleure procédure :-) Voilà, sinon bonjour à tous, il fait beau chez vous? (oui je sais, il fait presque noir...) Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Traductions?
Salut, Sur le wiki, il est noté qu'on peut envoyer les traductions sur CVS si on a un accès en écriture. Est-ce qu'il s'agit du même accès pour tout le monde (développeurs aussi)? Je ne pense pas que CVS permette une distinction de permissions du genre mais je ne suis pas très sûr. Dans la version CVS, il y a plein (beaucoup trop) de termes anglais-français mélangés. Je voudrais nettoyer ça au fur et à mesure de mes découvertes. Comme indiqué sur la page du wiki pour recevoir les accès CVS de développeur, je me suis inscrit sur Savannah, sur les listes dev, cvs et user et je commence à lire la doc de développement aujourd'hui. En attendant, j'imagine que soumettre tous les changements de fichiers de langue à la liste ne serait pas super bien perçu :-) Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] [BUG] création de DB MySQL - collate et charset
Le samedi 20 mai 2006 à 00:09 +0200, Laurent Destailleur (Eldy) a écrit : Yannick Warnier a écrit : Bonjour, Je suis nouveau dans Dolibarr (pas en PHP) et en downloadant Dolibarr depuis CVS hier et en l'installant aujourd'hui, je remarque que la requête de création de table pour MySQL (mysql.lib.php, ligne 237) contient DEFAULT CHARSET et DEFAULT COLLATION, qui génèrent tous deux une erreur avec MySQL version 4.0.24 (default sur Debian Sarge on dirait). Pour finir l'install j'ai viré les deux et ça a très bien fonctionné mais j'ignore si ça va casser quelque chose plus loin, et de toutes façons ça ne devrait pas bloquer l'install, à moins que Dolibarr ne demande d'office MySQL 5 ou une version supérieure à 4.0.24 (?) Non, l'objectif est que Dolibarr fonctionne sur des versions de Mysql 3.1 à aujourd'hui. La modif était nécessaire pour résoudre un problème sur Mysql 5 mais elle a crée une régression. Je viens de corriger cela. Peux-tu me dire si ca marche sur ton Mysql 4.0 (Je n'ai que des environnement en Mysql 4.1 ou 5.0). Testé à l'instant avec 4.0.24. Fonctionne nickel. Merci. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Traductions?
Le samedi 20 mai 2006 à 14:30 +0200, Laurent Destailleur (Eldy) a écrit : Yannick Warnier a écrit : Salut, Sur le wiki, il est noté qu'on peut envoyer les traductions sur CVS si on a un accès en écriture. Est-ce qu'il s'agit du même accès pour tout le monde (développeurs aussi)? Je ne pense pas que CVS permette une distinction de permissions du genre mais je ne suis pas très sûr. Dans la version CVS, il y a plein (beaucoup trop) de termes anglais-français mélangés. Je voudrais nettoyer ça au fur et à mesure de mes découvertes. Apparemment il s'agit surtout des fichiers de langue fr_BE. J'ai mis à jour la wiki pour répondre plus précisemment à ta question. Voici la procédure conseillé pour soumettre des traductions: Bon, je suis tombé sur un os (enfin moi je trouve que c'est un os). Est-ce que vous avez une langue maîtresse? Une langue à partir de laquelle toutes autres se traduisent? C'est fr_FR? Parce que le Wiki dit: Si un fichier n'a pas été traduit dans la nouvelle langue, Dolibarr utilisera l'Anglais. Or si c'est le français qui est le plus complet, ça me paraît... étrange d'utiliser l'anglais. Quoique finalement les noms des variables eux-mêmes sont en anglais... J'ai pas trop envie de comparer tous les fichiers ligne par ligne. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Wiki - demande de précisions
Salut,
Pour les demandes de précisions sur la doc du wiki (je peux changer le
wiki moi-même si quelqu'un me donne les précisions) je dois m'adresser
ici?
Dans la doc pour développeurs, Langages et normes, la section Syntaxe
SQL est trop brève. Elle ne donne aucun exemple. Dire Les SELECT *
sont interdits ne dit pas ce qui est permis. De même, quoter les
numériques ne précise rien sur la façon de faire. Un exemple pour
chasue serait parfait.
J'imagine que pas de SELECT * veut dire:
SELECT field_a, field_b, field_c FROM ...
et que quoter les numériques veut dire qu'on fait:
INSERT INTO table_1 (field_text, field_num) VALUES ('abcd','1234');
?
Merci,
Yannick
___
Dolibarr-dev mailing list
Dolibarr-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Wiki - demande de précisions
Le mercredi 24 mai 2006 à 21:17 +0200, Rodolphe Quiedeville a écrit :
Le 24.05.2006 16:59, Yannick Warnier a ecrit :
Salut,
Pour les demandes de précisions sur la doc du wiki (je peux changer le
wiki moi-même si quelqu'un me donne les précisions) je dois m'adresser
ici?
Dans la doc pour développeurs, Langages et normes, la section Syntaxe
SQL est trop brève. Elle ne donne aucun exemple. Dire Les SELECT *
sont interdits ne dit pas ce qui est permis. De même, quoter les
numériques ne précise rien sur la façon de faire. Un exemple pour
chasue serait parfait.
J'imagine que pas de SELECT * veut dire:
SELECT field_a, field_b, field_c FROM ...
et que quoter les numériques veut dire qu'on fait:
INSERT INTO table_1 (field_text, field_num) VALUES ('abcd','1234');
Tout a fait, tu peux préciser le wiki si tu veux, mais la compréhension
me semble un préréquis de base pour tout codeur non ?
Non, je ne pense pas de même. Une documentation bien faite permet au
logiciel d'aller beaucoup plus loin (PHP en est un bon exemple).
Beaucoup de petites erreurs (de développeurs) peuvent être évitées avec
une documentation précise, et la documentation par exemples est la
meilleure documentation qui soit.
Ici, en plus, il s'agit de lignes de conduite, donc plus c'est précis,
moins il y a de travail de correction.
Yannick
___
Dolibarr-dev mailing list
Dolibarr-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Wiki - demande de précisions
Le mercredi 24 mai 2006 à 23:08 +0200, Rodolphe Quiedeville a écrit :
Le 24.05.2006 21:52, Yannick Warnier a ecrit :
Le mercredi 24 mai 2006 à 21:17 +0200, Rodolphe Quiedeville a écrit :
Le 24.05.2006 16:59, Yannick Warnier a ecrit :
Salut,
Pour les demandes de précisions sur la doc du wiki (je peux changer le
wiki moi-même si quelqu'un me donne les précisions) je dois m'adresser
ici?
Dans la doc pour développeurs, Langages et normes, la section Syntaxe
SQL est trop brève. Elle ne donne aucun exemple. Dire Les SELECT *
sont interdits ne dit pas ce qui est permis. De même, quoter les
numériques ne précise rien sur la façon de faire. Un exemple pour
chasue serait parfait.
J'imagine que pas de SELECT * veut dire:
SELECT field_a, field_b, field_c FROM ...
et que quoter les numériques veut dire qu'on fait:
INSERT INTO table_1 (field_text, field_num) VALUES ('abcd','1234');
Tout a fait, tu peux préciser le wiki si tu veux, mais la compréhension
me semble un préréquis de base pour tout codeur non ?
Non, je ne pense pas de même. Une documentation bien faite permet au
logiciel d'aller beaucoup plus loin (PHP en est un bon exemple).
Beaucoup de petites erreurs (de développeurs) peuvent être évitées avec
une documentation précise, et la documentation par exemples est la
meilleure documentation qui soit.
Ici, en plus, il s'agit de lignes de conduite, donc plus c'est précis,
moins il y a de travail de correction.
Ok, je suis entièrement d'accord pour que tu mettes à jour le wiki,
j'expliquais juste le pourquoi de ce point précis.
Et j'expliquais juste pourquoi je n'étais pas d'accord :-)
Et puis j'ai oublié de dire merci pour ta confirmation d'ailleurs, donc
merci.
Voilà j'avais déjà mis à jour le wiki.
A+,
Yannick
___
Dolibarr-dev mailing list
Dolibarr-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Modèles de factures - pas dans le script d'update?
Salut, Toujours dans mes péripéties d'upgrade de 2.0alpha à 2.1alpha (CVS d'il y a une semaine), les différents modèles de factures ne s'affichent pas dans la drop-down model de htdocs/compta/facture.php J'ai un peu traqué le problème, qui m'a fait passer par htdocs/compta/facture.php (ligne 2030, appel à $html-show_documents()) puis par htdocs/html.form.class.php (ligne 2355, appel à ModelePDFFactures-liste_modeles()) puis par htdocs/includes/modules/facture/modules_facture.php (methode liste_modeles(), ligne 60) pour enfin trouver qu'il remplissait cette dropdown avec le contenu de la table llx_document_model de type invoice, or sur mon install d'upgrade de 2.0alpha à 2.1alpha il n'y a pas de modèle de type invoice. Voilà alors comme c'est un peu laborieux pour moi de réinstaller le truc à chaque fois, est-ce que le mainteneur du script d'upgrade pourrait vérifier que cette table est bien remplie comme il le faudrait? Merci, Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] gestion du stock si on n'utilise pas le module expédition
Le vendredi 02 juin 2006 à 17:03 +0200, Régis Houssin a écrit : Bonjour, Le stock n'est pas décompté si on n'utilise pas le module expédition. Est-ce que je rajoute une fonction qui permettrait de décompter le stock après la validation de la facture, seulement si le module expédition est inactif ? Qu'en pensez-vous ? Bonne idée. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Modèles de factures - pas dans le script d'update?
Le vendredi 02 juin 2006 à 10:44 +0200, nicolas gombert a écrit : Le jeudi 01 juin 2006 à 19:24 +0100, Yannick Warnier a écrit : Salut, Toujours dans mes péripéties d'upgrade de 2.0alpha à 2.1alpha (CVS d'il y a une semaine), les différents modèles de factures ne s'affichent pas dans la drop-down model de htdocs/compta/facture.php As-tu vérifié que les modèle etaient activé dans la configuration du module facture ? Non en effet ils n'étaient pas activés. Bien enregistré. Je le note sur le wiki dans la section factures. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
RE: [Dolibarr-dev] ajout gestion des particuliers
Le jeudi 08 juin 2006 à 17:55 +0200, Loic LE BLEIS a écrit :
Salut,
Le problème des classes multiples sur les éléments HTML (div, td, etc) c'est
que même si ça respect le W3C ça n'est (surprize!) pas interprété par notre
chere IE qui va prendre en compte la dernière des classes présente dans le
CSS.
Oui en fait c'est pour ça que je me disais que mon exemple n'était pas
bien fait. En fait si je reprends mon exemple:
td class=monstyle peutsecacher
et que j'inverse les classes:
td class=peutsecacher monstyle
Alors ça marche avec IE aussi puisque monstyle est le seul qu'on veut
vraiment interpréter et changer, l'autre pouvant être là simplement pour
indiquer que l'élément peut se cacher (comme son nom l'indique :-)).
Donc dans ce dernier exemple IE interprétera bien monstyle mais
renverra toujours l'élément quand on cherchera pour peutsecacher avec
getElementsByTagName('td').
Dans le JavaScript, on substituera la string monstyle par
monstylecaché et le tour est joué. L'autre classe reste là pour la
manipulation inverse où on veut remontrer les champs cachés.
Compris? J'ai pas vraiment vérifié mais je crois qu'Hervé a donné un
exemple avec le JS/non JS (je lui fais confiance pour cette fois ;-)).
Bon, en gros c'est un hack, il faut dire ce qui est, donc oui, la
solution la plus pure est d'utiliser un ID pour chaque élément, mais tu
peux faire une pseudo-catégorie en utilisant les classes et en restant
conforme à W3C. Tu as maintenant toute la palette de possibilités. Il te
reste à choisir (mais comme Loïc veut bien mettre les IDs pour toi, le
calcul n'est plus très compliqué).
Cela dit, c'est bien joli les IDs mais ça veut dire que chaque fois
qu'on veut rajouter un élément il faut modifier la page HTML et le
JavaScript (et si on oublie ça déconne). Bah... je suis incapable de
décider sur ce coup-là. Dur dur...
Yannick
___
Dolibarr-dev mailing list
Dolibarr-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Dolibarr Version 2.0.1 - Liste prospect - erreur de tri et problème page suivante
Le jeudi 08 juin 2006 à 20:03 +0200, Dolibarr a écrit : Hello, Nous sommes tombés sur deux problèmes à propos des listes prospect : * Si nous demandons la liste des prospect et qu'à la suite de l'affichage nous faisons page suite nous avons une erreur système parce que la variable stcomm n'est pas initialiser, l'instruction isset($_GET[stcomm]) ne détecte pas que la variable est vide (le Linux 2.6.11-6mdksmp #1 SMP Tue Mar 22 15:40:42 CET 2005 i686, Apache-AdvancedExtranetServer/2.0.53, PHP 4.3.10) ; pour palier le problème, j'ai complété l'instruction avec is_numeric($_GET[stcomm]) ; if(!empty($_GET['stcomm'])) est pas mal non plus pour les formulaires, bien que ça renvoie true pour une valeur = 0 ou 0. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Module facture - où est passée la constante FACTURE_RIB_NUMBER?
Salut, Dans les modèles de facture, jusqu'à tout récemment, on faisait usage de la constante FACTURE_RIB_NUMBER déclarée dans llx_const. Apparemment depuis peu la migration supprime cette constante (probablement en la remplaçant par une autre constante). Est-ce que quelqu'un pourrait me dire par quoi elle est remplacée? Étant donné que je ne sais pas ce que signifiait exactement FACTURE_RIB_NUMBER, c'est assez compliqué pour moi de trouver son remplaçant. Par contre manifestement beaucoup de modèles de facture en faisaient usage, donc je pense que c'est très important d'indiquer clairement quelque part (par exemple ici) ce qui a changé. C'est d'ailleurs toujours utilisé dans pdf_oursin... ligne 278 (et autres) Merci, Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] register_globals
Salut, Est-ce que Dolibarr fonctionne avec register_globals = off ? Merci, Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Procédure d'installation
Salut, Y a-t-il un moyen d'installer Dolibarr sans les scripts d'install? J'aimerais installer en considérant que l'utilisateur MySQL existe déjà et que la structure de répertoires (data) soit correcte, mais toujours en gardant la création de la DB. Bref, pour l'instant ça utilise etape1, etape2, etc dans install/, mais ce répertoire d'install est supposé dangereux (puisqu'il est conseillé de le retirer), ce qui m'empêche de faire une double install (utiliser le même répertoire htdocs/ mais pas le même /documents ni la même DB). Je travaille donc pour l'instant à une façon de contourner les scripts d'install, mais peut-être cela n'est-il pas nécessaire? Si je protège le script d'install avec un mot de passe, tout bêtement, ça devrait suffire, non? Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Dolibarr multi-host
Salut, Juste pour signaler que je viens de finir de faire fonctionner Dolibarr en multi-host, c'est-à-dire avec plusieurs installs utilisant le même code. J'ai par exemple marcel.gogo.com et julie.gogo.com, et tous deux sont des vhosts qui redirigent vers le même /var/www/dolibarr/htdocs. Le fichier conf.php utilise directement les variables définies par le serveur web au travers de la superglobale $_SERVER[] et la config est donc totalement dépendante du virtual host utilisé. Tout ça n'aurait pas été possible sans la structure super propre du code de Dolibarr. Félicitations. J'expliquerai un peu plus tard ici puis sur le wiki comment modifier les fichiers dans install/ pour pouvoir utiliser un fichier conf.php existant pour une nouvelle installation et sans écraser le fichier (qui prend sa config dans $_SERVER[] comme indiqué plus haut, donc qu'on ne veut pas écraser... jamais). Bonne nuit, Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Virgule ou point dans les factures
Le mardi 13 juin 2006 à 10:06 +0200, Jérôme Warnier a écrit : Salut, Notre nouveau modèle de facture fonctionne relativement bien (même s'il n'a pas encore toutes les fonctionnalités, comme les paiements déjà effectués), mais nous avons encore un petit problème: le séparateur décimal dans les PDF générés est un point, et non une virgule. Où peut-on arranger cela? number_format() devrait faire l'affaire mais il faudrait une fonction quelque part qui wrap number_format() en fonction de la langue de l'environnement (ou de la langue de la facture). Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
RE: [Dolibarr-dev] Virgule ou point dans les factures
Le mardi 13 juin 2006 à 11:57 +0200, Régis Houssin a écrit : Ce qui nous amène au problème de gestion linguistique des factures (en Belgique, nous avons trois langues nationales, en excluant l'anglais qui est fort utilisé mais pas national) où l'on voudrait pouvoir imprimer une facture avec les libellés en français, en néerlandais, en allemand ou en anglais selon le client. Est-ce que cela dérangerait quelqu'un si je rajoutais une drop-down langue à côté du modèle dans les factures, pour pouvoir choisir la langue à générer? Elle pourrait prendre par défaut la valeur de la langue du système (c'est dans cette langue que sont actuellement générées les factures PDF). Si je ne me trompe, on pourrait alors redéfinir, dans le modèle de facture, après chargement de pre.inc.php (qui charge main.inc.php et master.inc.php, c'est dans ce dernier que l'objet Translate est défini), l'objet Translate, qui définirait la langue de la facture. Ou plutôt on pourrait définir un autre objet Translate, pour être sûr de ne pas écraser l'objet Translate global. Ça plaît ça, comme idée, ou ça manque de quelque chose? Un tel choix de langue permettrait alors (dans le contexte actuel de langues ISO), un séparateur décimal pour chaque langue, de façon correcte. Par exemple, fr_BE serait une virgule, alors que en_US ou en_GB serait un point. Ce séparateur (et un séparateur de milliers) serait utilisé dans le modèle de facture (et pourquoi pas partout ailleurs) pour afficher les prix au travers de number_format(). Yannick Laurent a déjà inclus ceci dans la version cvs, par contre je crois que ca ne fonctionne pas encore, ou alors les modèles ne sont pas encore modifié pour. Régis Je ne vois aucune drop-down de langue dans la page de facture. Est-ce que Laurent pourrait m'en dire plus sur l'endroit où je dois trouver les modifs? Merci, Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Permissions de modif de ses infos utilisateur
Salut, À vérifier: Quand je n'ai pas la permission de modifier mes informations personnelles (ça s'appelle Create/Modify his own user information dans l'écran de config des permissions), je vois quand même un bouton Éditer sur ma page d'utilisateur, et je peux cliquer dessus et j'arrive sur le formulaire correspondant, mais quand je clique sur Enregistrer, il ne modifie rien, ne me donne aucun message d'erreur, et retourne tout naturellement sur la page d'affichage de mes infos (pas le formulaire). Serait-il possible de: - modifier user/fiche.php pour qu'il n'affiche pas le bouton Éditer dans le cas où je n'ai pas le droit de le faire - ajouter un check de permissions sur le formulaire d'édition de mes informations personnelles, qui me redirige sur la page d'affichage simple si je ne suis pas autorisé ? Si c'est nécessaire, je veux bien faire deux petits patches, mais là je n'ai pas encore regardé le code correspondant. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Permissions de modif de ses infos utilisateur
Le mardi 13 juin 2006 à 17:00 +0100, Yannick Warnier a écrit : Salut, À vérifier: Quand je n'ai pas la permission de modifier mes informations personnelles (ça s'appelle Create/Modify his own user information dans l'écran de config des permissions), je vois quand même un bouton Éditer sur ma page d'utilisateur, et je peux cliquer dessus et j'arrive sur le formulaire correspondant, mais quand je clique sur Enregistrer, il ne modifie rien, ne me donne aucun message d'erreur, et retourne tout naturellement sur la page d'affichage de mes infos (pas le formulaire). Serait-il possible de: - modifier user/fiche.php pour qu'il n'affiche pas le bouton Éditer dans le cas où je n'ai pas le droit de le faire - ajouter un check de permissions sur le formulaire d'édition de mes informations personnelles, qui me redirige sur la page d'affichage simple si je ne suis pas autorisé ? Si c'est nécessaire, je veux bien faire deux petits patches, mais là je n'ai pas encore regardé le code correspondant. Ceci dit même avec cette permission je n'ai toujours pas le droit de modifier quoi que ce soit, donc il y a un autre bug à trouver dans le coin. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Permissions de modif de ses infos utilisateur
Le mardi 13 juin 2006 à 17:39 +0100, Yannick Warnier a écrit : Le mardi 13 juin 2006 à 17:00 +0100, Yannick Warnier a écrit : Salut, À vérifier: Quand je n'ai pas la permission de modifier mes informations personnelles (ça s'appelle Create/Modify his own user information dans l'écran de config des permissions), je vois quand même un bouton Éditer sur ma page d'utilisateur, et je peux cliquer dessus et j'arrive sur le formulaire correspondant, mais quand je clique sur Enregistrer, il ne modifie rien, ne me donne aucun message d'erreur, et retourne tout naturellement sur la page d'affichage de mes infos (pas le formulaire). Serait-il possible de: - modifier user/fiche.php pour qu'il n'affiche pas le bouton Éditer dans le cas où je n'ai pas le droit de le faire - ajouter un check de permissions sur le formulaire d'édition de mes informations personnelles, qui me redirige sur la page d'affichage simple si je ne suis pas autorisé ? Si c'est nécessaire, je veux bien faire deux petits patches, mais là je n'ai pas encore regardé le code correspondant. Ceci dit même avec cette permission je n'ai toujours pas le droit de modifier quoi que ce soit, donc il y a un autre bug à trouver dans le coin. Voilà, on dirait qu'il faut la permission de modifier les détails d'autres utilisateurs pour pouvoir modifier les siens à soi. Ou alors il y a une autre interface pour modifier ses détails à soi que l'interface que l'on trouve via l'outil Utilisateurs et groupes en cliquant sur son nom...? Je ne sais pas mais c'est perturbant pour moi. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
RE: [Dolibarr-dev] Permissions de modif de ses infos utilisateur
Le mardi 13 juin 2006 à 20:25 +0200, Régis Houssin a écrit : j'ai modifié dans le cvs pour que le bouton Editer n'apparaisse plus. par contre je viens de tester avec un user n'ayant que le droit de modifier ses propres infos utilisateurs et je peux les modifier. est-ce que ca a résolu ton problème ? Tu vas me trouver lourd... :-D Ça marche nickel pour ce qui est mentionné plus haut, par contre, si j'ai juste(seulement) la permission de modifier mon mot de passe, je devrais pouvoir le faire et je ne vois pas vraiment comment faire ça sans restructurer un peu le formulaire d'édition d'utilisateur, parce que là si j'ai seulement cette permission-là il ne me laisse pas voir le bouton éditer. Enfin bon... tu vois, quoi. Enfin ça à la limite c'est moins grave mais c'est toujours un bug. Bref, je suis déjà content de pouvoir modifier mes détails quand j'y suis autorisé et de ne pas pouvoir quand je ne le suis pas. Un tout grand merci, donc. Yannick oui c'est vrai j'ai remarqué çà, mais en fait si tu as le droit de modifier ta fiche et pas le mot de passe, ce dernier ne peut être modifier si tu édite ta fiche. par contre si tu n'as que le droit de modifier ton mot de passe et bien effectivement tu ne peux pas le faire malgré tout. alors soit on désactive automatiquement le droit de modifier son mot de passe si on désactive le droit de modifier ses infos, soit on modifie le fonctionnement pour que seul le champs mot de passe soit modifiable ? Régis La solution facile étant évidemment de désactiver le mot de passe si on désactive les détails, mais je crois que c'est mieux de faire autrement. En fait ce serait beaucoup plus indiqué d'avoir une page séparée avec uniquement la modif du mot de passe. On pourrait mettre un lien sur la homepage Modifier son mot de passe, qui donnerait deux champs aussi (un pour confirmer, ça donne lieu à trop d'ennuis de support quand on ne demande pas de confirmer). Et un bouton à placer sur la page fiche.php pour modifier juste son mot de passe serait pas mal aussi. Par contre il ne sert à rien (je crois) d'afficher un champ mot de passe: dans la fiche, c'est pas vraiment utile (à confirmer). J'ai pas envie de le faire moi-même, mais si tu le fais pas directement j'aurai probablement un peu de temps la semaine prochaine pour le faire. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Factures - adresse banque
Bonjour, Certaines sociétés font figurer le nom et l'adresse de leur banque sur les factures. C'est mon cas (notamment). Vu la structure de la DB et le fait qu'il n'y ait (à ma connaissance) pas de table spécifique pour les banques (établissements), serait-il possible d'ajouter un champ libre bank_address dans llx_bank_account, puisque c'est à un compte bancaire qu'est généralement liée une facture? (autre sujet - peut-être à mettre dans un autre e-mail) Par ailleurs, serait-il envisageable de lier un contact à un compte en banque? Jérôme a l'air d'avoir une idée plus claire sur ce sujet, peut-être peut-il donner plus de détails? L'idée serait d'avoir, pour les gestionnaires de l'entreprise ou les comptables, un contact sous la main pour les problèmes bancaires éventuels nécessitant e-mail, coup de téléphone, fax ou que sais-je... Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Ajout d'un contact pour facturation
Le jeudi 15 juin 2006 à 15:26 +0200, Jérôme Warnier a écrit : Il semblerait qu'ajouter un contact comme contact facturation pour une société ne fonctionne plus. De même, je n'arrive pas à attribuer un contact sans société à une société. Et je me demandais si on pouvait attribuer un même contact à plusieurs sociétés. On dirait bien que la table llx_socpeople contient tous les types de contacts, avec un seul champ fk_soc, ce qui voudrait dire qu'un contact ne peut appartenir qu'à une société. Par contre il n'y a pas de raison de ne pas pouvoir le bouger d'une société à l'autre ou lui assigner une société quand il n'en a pas, mais apparemment il manque l'interface pour le faire. Voilà, il ne reste plus à quelqu'un qu'à confirmer. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Taux de TVA pour factures fournisseurs
Le jeudi 15 juin 2006 à 14:59 +0200, Jérôme Warnier a écrit :
C'est encore moi (Jérôme, non je n'ai pas changé...), resalut à tous,
Les taux de TVA sélectionables dans les factures fournisseurs sont
celles du pays dans lequel ma société se trouve. Or, je devrais pouvoir
choisir entre les taux de mon pays et ceux du pays du fournisseur, voire
même N/A pour les factures intracommunautaires entre assujettis.
Salut,
Voici un patch qui fixe deux grosses erreurs dans form.html.class.php.
La première (is_object($societe_vendeuse-pays_code)) renvoie toujours
faux (ce n'est pas un object).
La seconde, c'est qu'on utilise $societe_vendeuse-pays_code qui renvoie
un truc genre FR ou NL alors que le query qui suit ne réagit qu'à
l'id du pays (1 ou 17 dans ces cas-ci je crois).
Ce qui avait pour résultat de ne donner comme taux de TVA possible que
les taux de l'acheteur dans la dropdown TVA dans fourn/facture/fiche.php
(évidemment ça n'apparaît que quand on a un fournisseur à
l'étranger...).
Yannick
--- ../../dolibarr-cvs/htdocs/html.form.class.php 2006-06-15 16:01:26.0 +0100
+++ html.form.class.php 2006-06-15 15:57:10.0 +0100
@@ -1846,9 +1846,8 @@
function select_tva($name='tauxtva', $defaulttx='', $societe_vendeuse='', $societe_acheteuse='', $taux_produit='')
{
global $langs,$conf,$mysoc;
-
//print $societe_vendeuse.-.$societe_acheteuse;
-if (is_object($societe_vendeuse) ! $societe_vendeuse-pays_code)
+if (is_object($societe_vendeuse) ! $societe_vendeuse-pays_id)
{
if ($societe_vendeuse-id == $mysoc-id)
{
@@ -1861,14 +1860,7 @@
return;
}
- if (is_object($societe_vendeuse-pays_code))
- {
- $code_pays=$societe_vendeuse-pays_code;
- }
- else
- {
- $code_pays=$mysoc-pays_code;
- }
+ $code_pays=$societe_vendeuse-pays_id;
// Recherche liste des codes TVA du pays vendeur
$sql = SELECT t.taux,t.recuperableonly;
___
Dolibarr-dev mailing list
Dolibarr-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
RE: [Dolibarr-dev] Taux de TVA pour factures fournisseurs
Le jeudi 15 juin 2006 à 19:25 +0200, Régis Houssin a écrit : Le jeudi 15 juin 2006 à 14:59 +0200, Jérôme Warnier a écrit : C'est encore moi (Jérôme, non je n'ai pas changé...), resalut à tous, Les taux de TVA sélectionables dans les factures fournisseurs sont celles du pays dans lequel ma société se trouve. Or, je devrais pouvoir choisir entre les taux de mon pays et ceux du pays du fournisseur, voire même N/A pour les factures intracommunautaires entre assujettis. Salut, Voici un patch qui fixe deux grosses erreurs dans form.html.class.php. La première (is_object($societe_vendeuse-pays_code)) renvoie toujours faux (ce n'est pas un object). La seconde, c'est qu'on utilise $societe_vendeuse-pays_code qui renvoie un truc genre FR ou NL alors que le query qui suit ne réagit qu'à l'id du pays (1 ou 17 dans ces cas-ci je crois). Ce qui avait pour résultat de ne donner comme taux de TVA possible que les taux de l'acheteur dans la dropdown TVA dans fourn/facture/fiche.php (évidemment ça n'apparaît que quand on a un fournisseur à l'étranger...). j'ai testé ton patch, ca corrige bien le problème dans les factures fournisseurs mais pas dans les commandes fournisseurs. OK et deuxièmement ca crée des problèmes dans les commandes clients (je n'ai pas vérifier sur les propales et factures clients), il met un message à la place de la liste déroulante des taux de tva sur les lignes produits disant que le pays n'est pas défini. Le pays de ma société ou le pays du fournisseur? (le message d'erreur est différent normalement, selon les résultats d'une condition un peu bizarre juste avant). Je prépare un nouveau patch. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Re: Dolibarr- et OSC
Le jeudi 22 juin 2006 à 17:33 +, [EMAIL PROTECTED] a écrit : Today's Topics: 1. Re: Interface Dolibarr OSC (Yannick Warnier) Par pur intérêt, et sans trop y croire, sera-t-il possible d'attacher plusieurs boutiques OSCommerce à se société Dolibarr, ou est-ce que Dolibarr peut gérer d'une façon ou d'une autre une série de branches/succursales d'une même société? La question m'est aussi passée par la l'esprit. Même si ce n'est probablement pas la priorité. Dans mon idée, on a l'entreprise avec son stock (ou ses stocks en différents entrepôts). J'envisage de considérer un site web comme un entrepôt (ce qui permet de gérer la disponibilité et l'expédition des produits avec Dolibarr et éviter qu'une commande reçue via le web ne peut plus être honorée car on a vendu le produit en local). Si on creuse cette voie, on peut arriver à gèrer plusieurs boutiques OSC avec chacune son entrepôt en reliant les interfaces OSC non pas à l'entreprise, mais à un entrepôt. Mais, bon, on va déjà faire fonctionner avec une boutique OSC, et je ne connais pas encore assez bien Dolibarr pour avoir une idée de la faisabilité. Il ne faut pas abandonner l'idée. Je vais mettre un mot dans la page du wiki aussi pour garder une trace. Bien, gardons l'idée en réserve. Peut-être est-il également possible de gérer plusieurs entrepôts au niveau OSCommerce directement, mais il resterait quand même à faire le lien spécifique pour ce cas-là dans Dolibarr. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] suppression facture
Le jeudi 06 juillet 2006 à 00:19 +0200, Ozit a écrit : Bonsoir, Comme le disait Rodolphe, avec les vérifications OUI/NON à la validation d'une facture, cela devrait être suffisant pour ne pas faire de bêtises. En fait le problème c'est surtout quand on veut envoyer la facture au client puis que celui-ci fait remarquer qu'il y a une erreur (que ce soit sa faute ou la nôtre). Forcément, pour envoyer une facture au client il faut d'abord la valider. S'il y a une erreur du genre d'un mauvais taux de TVA pour l'un des composants, c'est con de devoir jeter la facture et tout refaire. Bref, ce sont des choses qui en théorie ne devraient pas arriver mais qui arrivent quand même, et c'est mal d'ignorer le problème. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Possibilité d'éditer et d'effacer une facture déjà validée
Le mardi 11 juillet 2006 à 08:46 +0200, Régis Houssin a écrit : J'ai ajouté la possibilité d'éditer une facture déjà validée. Cette fonction s'active dans la configuration du module facture, de plus il faut activer le droit modifier une facture dans l'onglet permission de l'utilisateur ou du groupe. Le bouton éditer n'apparait pas si la facture a déjà un paiement d'effectué ou si elle est classé payée. la facture garde son numéro d'origine après revalidation. Lorsqu'on édite une facture déjà validée on peut voir le bouton supprimer si et seulement si c'est la dernière facture, afin de les supprimer dans l'ordre inverse pour ne pas faire de trou dans la numérotation. Régis Hourr! :-) Merci (pas encore testé cela dit), Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Possibilité d'éditer et d'effacer une facture déjà validée
Le mercredi 12 juillet 2006 à 12:24 +0200, Rodolphe Quiedeville a écrit : Le 11.07.2006 15:24, Yannick Warnier a ecrit : Le mardi 11 juillet 2006 à 08:46 +0200, Régis Houssin a écrit : J'ai ajouté la possibilité d'éditer une facture déjà validée. Cette fonction s'active dans la configuration du module facture, de plus il faut activer le droit modifier une facture dans l'onglet permission de l'utilisateur ou du groupe. Le bouton éditer n'apparait pas si la facture a déjà un paiement d'effectué ou si elle est classé payée. la facture garde son numéro d'origine après revalidation. Lorsqu'on édite une facture déjà validée on peut voir le bouton supprimer si et seulement si c'est la dernière facture, afin de les supprimer dans l'ordre inverse pour ne pas faire de trou dans la numérotation. Régis Hourr! :-) Merci (pas encore testé cela dit), Bonjour, Je trouve cela un peu dangeureux tout de même les bonnes règles comptables veulent que si une facture est erronnée on l'annule avec un avoir et on en fait une nouvelle. Je sais que c'est plus pratique de modifier une facture existante, mais tout la solidité de Dolibarr venait de cette validation qui empêche tout modification ultérieure. Maintenant si de nombreux utilisateurs veulent cette fonctionnalité j'y consentirait mais sur le fond je reste opposer à cela. De plus pour les exports comptas c'est dangeureux, les exports (dans ma boite) se font tous les débuts de mois pour le mois précédents pour les calculs de TVA entre autres, les réglements pouvant intervenir le mois suivants, que se passe-t-il donc si une facture exportée en compta est modifiée ? Cela créé une incohérence, danger, danger Cordialement, L'option séparée pour cette permission-là me semble adéquate, elle devrait peut-être être mieux protégée (du genre pas incluse si on clique sur tout autoriser pour le groupe de permissions). Cela dit tant que tu peux faire une compta simplifiée, tu ne dois pas trop te soucier de l'annulation avec un avoir. Dans le fond, je suis d'accord avec toi, mais je trouve que l'option est bien pratique (puisque normalement je le faisais à la main donc que je ne respectais quand même pas les principes de compta). Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Erreur dans scripts/invoices/factures-impayees-commerciaux.php
Salut, Il y a une erreur dans le CVS dans le fichier nommé dans le titre. Je constate que ça a été modifié il y a deux semaines par eldy: http://cvs.savannah.gnu.org/viewcvs/dolibarr/scripts/invoices/factures-impayees-commerciaux.php?root=dolibarrr1=1.3r2=1.4 C'est une erreur de syntaxe PHP (manque une virgule). Eclipse la détecte sans même devoir ouvrir le fichier pour ça. Je suis un peu déçu qu'une faute de syntaxe se retrouve dans le CVS. Ce qui ne m'empêche pas de rester motivé et admiratif quand au travail fourni, mais quand même... Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Patch affichage prix
Salut,
Pour la conversion de l'affichage des prix dans les factures
(séparateurs . et , en fonction de la localisation), j'ai ajouté un
paramètre à la fonction price() dans htdocs/lib/functions.inc.php.
Ce n'est pas encore super comme méthode, notamment parce que ça ne
définit pour le moment que fr_FR, fr_BE, nl_BE et en_US (avec une valeur
par défaut quand même).
Le problème c'est que je ne peux pas me fier valablement aux variables
d'environnement (locales) pour faire la conversion, étant donné que cela
implique que les locales des différentes langues soient installées sur
la machine, ce qui n'est pas forcément le cas.
De plus, dans mon cas, j'utilise les différentes langues lors de
l'export de la facture en PDF, en prenant en considération la langue du
client (ce qui, je pense, n'est pas encore géré par Dolibarr).
Bref, j'attache un patch (en diff -r -u) de ma version modifiée de la
fonction price(). Je suis prêt à discuter d'une éventuelle meilleure
méthode. Le troisième paramètre de la fonction price() (ajouté dans la
modif) a une valeur par défaut, ce qui permet de continuer à l'utiliser
normalement partout ailleurs.
Yannick
--- dolibarr-cvs/htdocs/lib/functions.inc.php 2006-08-27 14:33:01.0
+0100
+++ dolibarr/htdocs/lib/functions.inc.php 2006-08-27 14:31:41.0
+0100
@@ -1712,18 +1712,31 @@
\param htmlFormatage html ou pas
(0 par defaut)
\seealsoprice2num Fonction inverse de
price
*/
-function price($amount, $html=0)
+function price($amount, $html=0, $l10n=null)
{
- if ($html)
- {
-
- $dec='.'; $thousand=' ';
- return ereg_replace(' ','nbsp;',number_format($amount, 2,
$dec, $thousand));
-
- }
- else
- {
- return number_format($amount, 2, '.', ' ');
+$dec='.'; $thousand=' ';
+ if(!empty($l10n)){
+ switch($l10n){
+ case 'fr_FR':
+ case 'fr_BE':
+ case 'nl_BE':
+ $dec = ',';
+ $thousand = ' ';
+ break;
+ case 'en_US':
+ $dec = '.';
+ $thousand = ',';
+ }
+ if ($html)
+ {
+ return ereg_replace(' ','nbsp;',number_format($amount,
2, $dec, $thousand));
+ }
+ else
+ {
+ return number_format($amount, 2, $dec, $thousand);
+ }
+ }else{
+ return number_format($amount, 2, '.', ' ');
}
}
___
Dolibarr-dev mailing list
Dolibarr-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] AJAX, scriptaculous et Dojo
Salut, Je vois que récemment le CVS a été bombardé de petits bouts de code pour ajouter un peu d'AJAX par-ci par-là. Je me sentirais coupable de ne pas relever le fait qu'il existe une librairie très sympa qui s'appelle XAJAX qui est en fait un outil d'aide aux développeurs PHP qui veulent ajouter de l'AJAX dans leurs applications web sans trop se frotter au JavaScript. Par ailleurs, étant donné la taille de Dolibarr (je m'étonnais encore aujourd'hui de le voir atteindre les 29 MB pour du code PHP en grande partie), il serait peut-être bon de jeter un oeil à Dojo (librairies JavaScript qui font un peu tout) avant de s'engager très loin sur la voie de Scriptaculous, qui après tout ne fait que rajouter de petits effets visuels (Dojo permet ça aussi mais beaucoup plus de choses en général). Voilà, j'ai libéré ma conscience. Sinon rien à dire, je n'ai pas eu de problème avec les petits morceaux d'AJAX et j'en suis bien content. Par contre là j'ai un petit problème par lequel Dolibarr m'a loggé en tant que user 0 et ne veut plus me délogger quand je clique sur logout. Je cherche et dès que je trouve un indice sensé je reviens poster un autre mail. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Problème de login
Salut, Lors d'une mise-à-jour d'une version de Dolibarr CVS de juin vers une version d'aujourd'hui, j'ai eu un problème de login. Lorsque je chargeais le répertoire racine de mon install, il me positionnait sur index.php (jusque-là rien d'étonnant) mais en passant au-dessus de la page de login (générée par la fonction dol_loginfunction() si j'ai bien compris) pour m'afficher une page de garde avec quelques menus en haut et à droite pour lesquels je me voyais refuser toute lecture (message d'avertissement m'indiquant que je n'avais pas accès). Après avoir bien fouillé et rien compris au $_SESSION['dol_user'], j'ai tenté de modifier la ligne 80 de htdocs/main.inc.php comme suit: if (! session_id() || ! isset($_SESSION[dol_user]) || ! isset($_SESSION[dol_token])) au lieu de if (! session_id() ! isset($_SESSION[dol_user]) ! isset($_SESSION[dol_token])) ( - ||) Apparemment (d'après mes tests d'insertion de balises de débug un peu partout) il semblerait que quoi que je fasse, j'avais toujours un des ces trois critères vrai, ce qui m'empêchait d'entrer dans la condition d'affichage de la boîte de login. Est-ce un cas isolé? Qu'est-ce que le $_SESSION['dol_token']? Est-ce que je ne devrais pas d'office me faire demander mon login si session_id() renvoie faux? Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Insertion de ligne de facture: $this-fk_product = null
Salut,
Avec une version CVS de mercredi ou jeudi passée, quand j'essaie
d'insérer une ligne de facture qui ne provient pas d'un produit dans un
brouillon de facture, l'opération ne fait tout simplement rien.
Après un peu de recherches, il apparaît que l'opération SQL d'insertion
de la ligne (facture.class.php, classe FactureLigne), lignes 2723-4:
if ($this-fk_product) { $sql.= '.$this-fk_product.',; }
else { $sql.='null,'; }
insère un fk_product null alors que ce n'est pas autorisé par la
structure de la table.
J'ai remplacé en local 'null' par '0' et ça passe, mais je me demande où
est le problème exactement, et si le fait de mettre le fk_product ) à
null ne va pas me causer des soucis par la suite.
Une idée?
Merci,
Yannick
___
Dolibarr-dev mailing list
Dolibarr-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] IBAN - plus qu'un préfixe
Salut, Je constate que la structure de la base de données limite l'IBAN (dans llx_bank_account) à un varchar(5). En fait, s'il ne s'agit peut-être que d'un préfixe pour les comptes belges et français, ce n'est pas forcément le cas pour les comptes espagnols et anglais. Ainsi par exemple, mon numéro de compte en banque en Angleterre se présente sous la forme d'une suite de 8 chiffres (12345678), plus un numéro d'agence (format 99-99-99). Mon numéro IBAN, lui, se présente sous la forme suivante: GB99 ABCD 77 J'ai mis des 7 et des 9 là où il peut y avoir n'importe quel chiffre. Pourrions-nous soit corriger ce champ de préfixe et lui attribuer une taille d'une trentaine de caractères (et le renommer en IBAN plutôt qu'IBAN_prefix) ou rajouter un champ full_IBAN qui reprendrait le code en entier (à mon avis le remplacement est la meilleure solution vu qu'un préfixe et un code complet qui coexistent ne peuvent mener qu'à des erreurs). Si la proposition fait l'unanimité, je veux bien fournir un patch au script d'upgrade. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Patch pour petit bug dans chiffre d'affaire transformé
Salut,
Voici un petit patch qui corrige (me semble-t-il) le bug qui affiche un
message d'erreur dans compta/stats/comp.php quand on veut afficher le
chiffre d'affaire transformé (colonne Delta [année]).
Le script s'applique à compta/stats/lib.inc.php où l'on utilisait
toujours $db-result() qui apparemment n'existe plus.
Yannick
--- dolibarrcvs/htdocs/compta/stats/lib.inc.php 2006-09-13 20:56:33.0 +0200
+++ dolibarr/htdocs/compta/stats/lib.inc.php 2006-10-07 23:45:59.185439715 +0200
@@ -34,7 +34,8 @@
if ($result)
{
- return $db-result (0, 0);
+ $res = $db-fetch_object($result);
+ return $res-sum;
}
else
{
@@ -61,7 +62,8 @@
if ($result)
{
- return $db-result ( 0, 0);
+ $res = $db-fetch_object($result);
+ return $res-sum;
}
else
{
___
Dolibarr-dev mailing list
Dolibarr-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Liste de factures - mois abrégé
Salut, J'ai un tout petit problème pour la liste de factures. Quand j'ai des factures de juin et de juillet de la même année (par exemple 1er juin, 4 juin, 7 juillet), la représentation sur trois lettres du mois est jui pour juin ET juillet. La seule solution que je vois c'est d'avoir des variables de langue pour le mois abrégé également, et de trafiquer un peu le mois de juillet pour afficher jul ou l'inverse (jun). Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
RE: [Dolibarr-dev] Patch pour petit bug dans chiffre d'affairetransformé
Les envois de Laurent sur le CVS ne sont pas mis en copie sur dolibarr-cvs@nongnu.org comme les tiens? Je pensais que c'était automatique et là je n'ai rien qui vienne de Laurent depuis ... euh... le 25 mai en fait. Yannick Le mardi 17 octobre 2006 à 13:48 +0200, Régis Houssin a écrit : Ton patch a déjà été appliqué par Laurent depuis samedi Régis -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Yannick Warnier Envoyé : mardi 17 octobre 2006 09:21 À : Discussions sur le developpement de Dolibarr Objet : Re: [Dolibarr-dev] Patch pour petit bug dans chiffre d'affairetransformé Régis, pourrais-tu appliquer mon patch (mail précédent dans ce thread) avant qu'il ne se perde? Merci. Yannick Le samedi 07 octobre 2006 à 22:53 +0100, Yannick Warnier a écrit : Salut, Voici un petit patch qui corrige (me semble-t-il) le bug qui affiche un message d'erreur dans compta/stats/comp.php quand on veut afficher le chiffre d'affaire transformé (colonne Delta [année]). Le script s'applique à compta/stats/lib.inc.php où l'on utilisait toujours $db-result() qui apparemment n'existe plus. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
RE: [Dolibarr-dev] Patch pour petit bug dans chiffred'affairetransformé
Le mardi 17 octobre 2006 à 14:51 +0200, Régis Houssin a écrit : oui je suppose qu'ils les a désactivé pour ne pas inonder la liste cvs. tu peux voir les dernières modifs ici : http://ns3744.ovh.net/~ldestail/dolibarr/cvschangelogbuilder_dolibarr.html C'est dommage, j'utilisais justement la liste dolibarr-cvs pour savoir ce qui changeait. L'interface que tu m'indique me semble moins pratique pour ça. Perso, je ne suis pas contre l'inondation de la liste cvs. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Dolibarr 2.1 beta? (était RE: [Dolibarr-dev] Patch pour petit bug dans chiffred'affairetransfor mé)
Le mardi 17 octobre 2006 à 14:51 +0200, Régis Houssin a écrit : oui je suppose qu'ils les a désactivé pour ne pas inonder la liste cvs. tu peux voir les dernières modifs ici : http://ns3744.ovh.net/~ldestail/dolibarr/cvschangelogbuilder_dolibarr.html Tiens, en regardant la page rapidement, je vois que le dernier tag en date dans CVS est un Dolibarr 2.1 Beta. Si c'est vraiment le cas, ne faudrait-il pas modifier la définition de DOL_VERSION dans htdocs/master.inc.php, ligne 35? Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] upgrade.php - pas de message si erreur avec select_db
Salut,
Dans upgrade.php, il n'y a pas de message d'erreur quand on parvient à
se connecter au serveur DB mais qu'on ne parvient *pas* à se connecter à
la base voulue ($db-select_db).
J'ai réalisé le petit patch ci-joint pour afficher un message que j'ai
corrigé dans le fichier de langues car le nom des variables dans le
fichier de langue en_US n'était pas bon (aussi dans le patch). Je l'ai
aussi corrigé dans le fichier de langue fr_FR/install.lang.
Merci de jeter un oeil et d'appliquer si ça convient. J'ai constaté au
passage qu'il y avait pas mal de warning (avec xdebug) par rapport à
$conf-syslog-enabled qui est utilisé alors que pas déclaré
(apparemment on n'utilise pas $conf-setValues($db) dans la procédure
d'install).
Yannick
diff -Naur dolibarrcvs/htdocs/install/upgrade.php dolididrik/htdocs/install/upgrade.php
--- dolibarrcvs/htdocs/install/upgrade.php 2006-08-15 18:33:56.0 +0100
+++ dolididrik/htdocs/install/upgrade.php 2006-10-19 22:06:42.0 +0100
@@ -94,10 +95,13 @@
{
if($db-database_selected == 1)
{
+ print trtd nowrap;
+ print $langs-trans(DatabaseConnection). : $dolibarr_main_db_host/tdtd align=\right\.$langs-trans(OK)./td/tr;
dolibarr_install_syslog(Database connection successfull : $dolibarr_main_db_name);
}
else
{
+ print trtd.$langs-trans(ErrorFailedToConnectToDatabase,$dolibarr_main_db_name)./tdtd align=\right\.$langs-trans(Error)./td/tr;
$ok = 0 ;
}
}
diff -Naur dolibarrcvs/htdocs/langs/en_US/install.lang dolididrik/htdocs/langs/en_US/install.lang
--- dolibarrcvs/htdocs/langs/en_US/install.lang 2006-09-09 01:55:07.0 +0100
+++ dolididrik/htdocs/langs/en_US/install.lang 2006-10-19 22:19:26.0 +0100
@@ -12,8 +12,8 @@
ErrorDirDoesNotExists=Directory %s does not exists.
ErrorGoBackAndCorrectParameters=Go backward and correct wrong parameters.
ErrorWrongValueForParameter=You may have typed a wrong value for parameter '%s'.
-ErrorFaileToCreateDatabase=Failed to create database '%'.
-ErrorFaileToConnectToDatabase=Failed to connect to database '%'.
+ErrorFailedToCreateDatabase=Failed to create database '%'.
+ErrorFailedToConnectToDatabase=Failed to connect to database '%'.
ErrorPHPVersionTooLow=PHP version too old. Version %s is required.
PHPVersion=PHP Version
YouCanContinue=You can continue...
diff -Naur dolibarrcvs/htdocs/langs/fr_FR/install.lang dolididrik/htdocs/langs/fr_FR/install.lang
--- dolibarrcvs/htdocs/langs/fr_FR/install.lang 2006-10-18 14:01:01.0 +0100
+++ dolididrik/htdocs/langs/fr_FR/install.lang 2006-10-19 22:21:36.0 +0100
@@ -12,8 +12,8 @@
ErrorDirDoesNotExists=Le répertoire b%s/b n'existe pas ou n'est pas accessible.
ErrorGoBackAndCorrectParameters=Revenez en arrière et corrigez les paramètres invalides.
ErrorWrongValueForParameter=Vous avez peut-être saisi une mauvaise valeur pour le paramètre '%s'.
-ErrorFaileToCreateDatabase=Echec de création de la base '%'.
-ErrorFaileToConnectToDatabase=Echec de connection à la base '%'.
+ErrorFailedToCreateDatabase=Echec de création de la base '%'.
+ErrorFailedToConnectToDatabase=Echec de connection à la base '%'.
ErrorPHPVersionTooLow=Version de PHP trop ancienne. La version %s est requise.
PHPVersion=Version PHP
YouCanContinue=Vous pouvez continuer...
___
Dolibarr-dev mailing list
Dolibarr-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Multi-monnaies
Salut à tous! Aujourd'hui, j'ai décidé d'encoder mon activité d'indépendant dans Dolibarr (j'ai fait la décision aujourd'hui, je ne vais pas le *faire* aujourd'hui). Seulement voilà, je suis dans un cas assez particulier (pas si particulier que ça). Je suis belge, mais je vis (et travaille) en Angleterre. Par ailleurs, j'ai la majorité de mes revenus en euros (un bon client belge). Malheureusement, ma compta officielle, je la fais en livres Sterling ou GBP (parce que je vis en Angleterre et que les impôts sont moins importants ici). Par ailleurs je pense au futur, et j'ai bien l'intention d'aller travailler dans d'autres pays (au programme: Pérou, Danemark et Nouvelle-Zélande). Je ne sais pas très bien comment ça va fonctionner au niveau de la taxation, mais il se pourrait fortement que je continue à être payé en euros, mais en devant remettre des déclarations d'impôts en Nuevo Sols (ou en dollars US), en DKK (couronnes danoises) et en dollars néo-zélandais, les uns après les autres. Forcément, rien n'est jamais simple, et pour un revenu gagné en euros, il y a un index mensuel officiel sur le site de l'administration des taxes anglaise qui me permet de calculer à combien ça équivaut en GBP. Autrement dit, si je voulais utiliser Dolibarr de façon optimale, il me faudrait un mécanisme qui permette d'avoir un montant dans sa devise originale, puis d'avoir d'avoir une vue dans la monnaie de mon choix des rapports annuels divers, mais aussi éventuellement des factures, etc. Jusqu'ici, je vois ça comme ceci: - une table llx_currency_exchange_rate (id, date, cur1, cur2, index1to2) où la date est la date de validité d'un taux jusqu'à la prochaine date avec un nouveau taux, cur1 est la devise de départ, cur2 la devise vers laquelle on convertit, et index1to2 est le multiplicateur. - dans chaque table avec un montant, avoir une indication de la devise dans laquelle ça se présente (et être certain d'avoir la date de validité de la somme) - au niveau utilisateur, donner une option d'affichage qui mette tous les montants dans une certaine devise (et chaque fois qu'on affiche un prix, on le convertit en fonction de la devise de base, de la monnaie d'arrivée et du taux connu pour la date de validité) - au niveau des factures (export PDF), il faudrait que je puisse choisir la devise d'export (puisque certaines de mes factures sont en GBP, d'autres en EUR) Par défaut, le système serait configuré en euros (partout), ce qui permettrait la compatibilité en arrière, mais on pourrait choisir de changer cette config. Par défaut aussi, le système proposerait un taux de conversion de base (configurable dans les paramètres système) qui serait utilisé si on n'a aucun taux de conversion pour la monnaie voulue à la date voulue. Les montants seraient alors affichés dans une autre couleur, définie dans les paramètres système également, pour signaler que la conversion est floue. Voilà, qu'est-ce que vous en pensez? Moi je crois que c'est de toute façon une nécessité à moyen terme (d'avoir une gestion multi-devise) et qu'il faudrait y penser sérieusement. Sur trois personnes à qui j'ai parlé de Dolibarr, deux m'ont posé la question de la gestion multi-devises sans que je les mette sur la voie. Cela dit mon public est assez international... Le plugin vers os-commerce me fait encore plus insister sur cette nécessité (quand on vend online, c'est intéressant de proposer de payer en plusieurs devises). Bien entendu, je suis prêt à l'implémenter. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] [Phoning] Erreur SQL sur llx_telephonie_societe_ligne
Le lundi 16 octobre 2006 à 16:24 +0100, Yannick Warnier a écrit : Salut, Depuis ma dernière mise-à-jour, j'ai une erreur SQL sur la page d'accueil de mon install Dolibarr: Request for last database access in error: SELECT count(rowid) as nb FROM llx_telephonie_societe_ligne WHERE fk_commercial_sign = 2 Return code for last database access: DB_ERROR_NOSUCHTABLE Information for last database access: Table 'dolibarr_demo.llx_telephonie_societe_ligne' doesn't exist Donc la table llx_telephonie_societe_ligne n'existerait plus, seulement avant de chercher, est-ce que quelqu'un peut me dire si cette dernière a subi des modifications lors des dernières mises-à-jour? Après vérification, l'erreur s'affiche uniquement lorsque le module Phoning est installé. Je n'ai pas de patch à apporter sur ce coup-ci, mais ça vaut le coup de le noter quelque part (que le module Phoning a un problème). ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Patch nombre de documents attachés à une facture
Salut,
Dans htdocs/compta/facture/document.php, le nombre de documents attachés
n'est pas correct lorsqu'il y a un fichier .meta dans le répertoire. En
fait il est correct mais comme on n'affiche pas les fichiers .meta, ça
ne sert à rien de les compter. Patch ci-joint.
Yannick
diff -Naur dolibarrcvs/htdocs/compta/facture/document.php dolididrik/htdocs/compta/facture/document.php
--- dolibarrcvs/htdocs/compta/facture/document.php 2006-09-13 19:56:32.0 +0100
+++ dolididrik/htdocs/compta/facture/document.php 2006-10-21 18:34:05.0 +0100
@@ -131,7 +131,8 @@
$i=0;
while (($file = readdir($handle))!==false)
{
-if (!is_dir($dir.$file) substr($file, 0, 1) '.' substr($file, 0, 3) 'CVS')
+ if (!is_dir($dir.$file) substr($file, 0, 1) '.' substr($file, 0, 3) 'CVS'
+ ! eregi('\.meta$',$file))
{
$filearray[$i]=$file;
$totalsize+=filesize($upload_dir./.$file);
___
Dolibarr-dev mailing list
Dolibarr-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Patch langue fr_BE
Salut, Merci d'appliquer le patch suivant qui traduit l'ensemble des fichiers de langue en_US en fr_BE. C'est une première version qui sera encore un peu améliorée, mais comme on est toujours en Beta et que c'est mieux qu'avant, ça ne pose pas de problème. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Nouveau développeur
Le vendredi 27 octobre 2006 à 10:04 +0200, Rodolphe Quiedeville a écrit : Salut, Yannick Warnier fait maintenant partie des développeurs officiels en ce qu'il a désormais accès au CVS sur Savannah. Bienvenue à toi Yannick Merci Rodolphe, C'est avec grand plaisir que j'accepte ce titre! Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Nouvel outil de traduction - extension Firefox
Le vendredi 27 octobre 2006 à 10:03 +0200, Rodolphe Quiedeville a écrit : Le 24.10.2006 00:43, Yannick Warnier a ecrit : Et encore une nouvelle version (cette fois c'est la dernière, promis) qui corrige le bug des espaces en trop. Salut Yannick, Au lieu de hacker le plugin de trad ne pourrions-nous pas plutôt modifier le format des fichiers .lang que nous utilisons, si tu me donnes la syntaxe native je veux bien me coller à cette tâche. Salut Rodolphe, Pour avoir utilisé les deux formats, je peux garantir à 100% que celui de Dolibarr est bien plus pratique. L'autre format est un format PHP simple: ?php $NomDeVariable = valeur; ? qui pose énormément de problèmes d'échappement (notamment) des guillemets et apostrophes. Je suis actuellement en discussion avec le développeur de l'extension Firefox phplangeditor, qui a d'ores et déjà accepté d'intégrer les modifications dans la prochaine version de l'extension. En fait, par pur hasard, c'est un gars avec qui je suis allé à l'école d'info, donc le courant passe bien. Je lui ai envoyé mon code, et une petite modification permettra de prendre un format ini ou php en lecture, selon l'extension du fichier au départ. Pas de souci donc, il faut juste un peu de patience pour que la nouvelle version de l'extension sorte (et puis qu'elle soit adaptée à Firefox 2.0 si nécessaire - elle fonctionne avec Firefox 1.5 pour le moment, je ne sais rien de la compatibilité avec les autres versions). Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Notes de frais
Salut, Dans notre administration journalière, nous trouvons le besoin quotidien d'encoder des notes de frais. Je vois une note de frais de la façon suivante: il s'agit d'une facture fournisseur, mais que l'un des employés (par ailleurs utilisateur de Dolibarr pour simplifier, mais ça pourrait s'élargir par la suite à des employés non-utilisateurs) a payé de sa poche, et donc qu'il faut lui rembourser. Est-ce qu'il y aurait déjà un système de ce genre en place? (avant de réinventer la roue) Ça pourrait faire l'objet d'un nouvel outil complet, mais je crois que c'est une bonne idée de garder cela dans la même table que les factures fournisseurs, parce qu'après tout ce sont des frais que l'on paie à un fournisseur. Le problème c'est que dans ce cas précis il n'y aurait pas toujours de fournisseur encodé (ou alors si?). Des avis? Des idées? Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Smarty
Le mercredi 29 novembre 2006 à 13:52 +0100, Rodolphe Quiedeville a écrit : Salut, Je vais intégrer smarty dans Dolibarr, j'en profite pour créer un répertoire external-libs au même niveau que htdocs et documents, en effet il me semble plus logique d'intégrer les libs externes à cet endroit plutôt que dans htdocs qui pour moi ne doit contenir que le code que nous écrivons. Salut, Pense, dans ton calcul, qu'il faudra une configuration spécifique dans ce cas pour inclure ce qui, souvent, se trouve en dehors du DocumentRoot du VirtualHost (et donc peut-être à mettre une config d'exemple sur le wiki...) Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Factures récurrentes
Salut, Quelqu'un pourrait-il m'expliquer en bref comment fonctionnent les factures récurrentes? Notamment si elles doivent être reprises dans les comptes de TVA ou si elles génèrent à chaque fois une nouvelle facture normale automatiquement... Parce que je vois que llx_facturedet_rec contient un lien vers llx_facture_rec, mais que llx_facture_rec ne contient pas de facid... (et je suis occupé à ajouter une vue TVA et je voudrais pauffiner avant de soumettre). Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] facturation par lot
Le mercredi 06 décembre 2006 à 07:55 -1000, Tahiti Rimai (Jean) a écrit : J'ai entamé le développement de la fonction facturation par lot. C'est-à-dire? Tu me rappelle ce que veut dire par lot dans ce contexte? Les fonctions seront ajoutées dans les modules contrat et compta. J'ai commencé aujourd'hui la page contrat/facturation.php, je l'enverrai sur le cvs ASAP. Je prévois ceci : une zone pour la saisie du mois à facturer (par défaut le mois courant) et un bouton pour lancer le calcul, un autre pour annuler un calcul précédent. Le calcul de quoi? une zone avec le résultat de l'opération : qc du style : contrat | client | n° facture provisoire | message ok ou message erreur On génère les factures brouillons, qu'il faut ensuite vérifier puis valider et imprimer une à une. Qu'en pensez-vous Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
RE: [Dolibarr-dev] IE 7 Dolibarr ...
Le lundi 11 décembre 2006 à 12:27 +0100, Vianney ASSOFI a écrit : Salut, Oui, mais demo / demo ne marche plus sur demo.dolibarr.com ;) V. C'est pour ça qu'il faut utiliser jean/jean ou francois/francois :-) Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] fr_BE - dépendance à fr_FR
Salut, Y aurait-il quelqu'un qui s'opposerait à un petit changement de code pour les fichiers de langue pour que fr_BE retombe sur fr_FR plutôt que sur en_US? C'est juste histoire d'économiser un paquet de copier-coller, mais on pourrait en faire une règle générale aussi avec un fr virtuel qui est fr_FR et qui permet à tous les fr_xx de retomber sur du français par défaut... Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: Dolibarr 2.1 beta? (était RE: [Dolibarr-dev] Patch pour petit bug dans chiffred'affairetransformé)
Le mardi 17 octobre 2006 à 17:16 +0100, Yannick Warnier a écrit : Le mardi 17 octobre 2006 à 14:51 +0200, Régis Houssin a écrit : oui je suppose qu'ils les a désactivé pour ne pas inonder la liste cvs. tu peux voir les dernières modifs ici : http://ns3744.ovh.net/~ldestail/dolibarr/cvschangelogbuilder_dolibarr.html Tiens, en regardant la page rapidement, je vois que le dernier tag en date dans CVS est un Dolibarr 2.1 Beta. Si c'est vraiment le cas, ne faudrait-il pas modifier la définition de DOL_VERSION dans htdocs/master.inc.php, ligne 35? Tiens, j'ai jamais eu de réponse et c'est toujours alpha qui se trouve dans master.inc.php. Des objections à ce que je modifie en beta et soumette? Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: Dolibarr 2.1 beta? (était RE: [Dolibarr-dev] Patch pour petit bug dans chiffred'affairetransformé)
Le lundi 11 décembre 2006 à 21:37 +0100, Rodolphe Quiedeville a écrit : Le 11.12.2006 21:05, Yannick Warnier a ecrit : Le mardi 17 octobre 2006 à 17:16 +0100, Yannick Warnier a écrit : Le mardi 17 octobre 2006 à 14:51 +0200, Régis Houssin a écrit : oui je suppose qu'ils les a désactivé pour ne pas inonder la liste cvs. tu peux voir les dernières modifs ici : http://ns3744.ovh.net/~ldestail/dolibarr/cvschangelogbuilder_dolibarr.html Tiens, en regardant la page rapidement, je vois que le dernier tag en date dans CVS est un Dolibarr 2.1 Beta. Si c'est vraiment le cas, ne faudrait-il pas modifier la définition de DOL_VERSION dans htdocs/master.inc.php, ligne 35? Tiens, j'ai jamais eu de réponse et c'est toujours alpha qui se trouve dans master.inc.php. Des objections à ce que je modifie en beta et soumette? Allez ok pour beta, mais alors il va falloir clore tous les bugs ouverts dans le bugtrack :-) Moi je dis ça simplement parce que eldy a mis un tag BETA dans le CVS le 24 octobre. Que ce soit alpha ou beta, ça m'est égal, mais j'aime bien la cohérence. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Bug $user-getrights('')
Salut,
Avec la dernière upgrade à partir du CVS, j'ai un bug qui m'empêche
d'aller plus loin que la page d'accueil de Dolibarr:
bFatal error/b: Unknown(): The script tried to execute a method or
access a property of an incomplete object. Please ensure that the class
definition user of the object you are trying to operate on was loaded
_before_ the session was started in
b/var/www/dolitest/htdocs/includes/menus/barre_top/eldy_backoffice.php/b on
line b72/bbr /
Je le poste ici parce que j'ai besoin d'un coup de main actif, pas juste
d'une résolution. J'aimerais bien le résoudre moi-même mais j'ai un
problème évident, c'est que je ne sais pas ce qui a changé dernièrement
dans les scripts en rapport avec la procédure de login.
Quoi qu'il en soit, la ligne 72 de eldy_backoffice.php contient
$user-getrights(''); qui semble avoir un problème de définition de la
variable $user.
Or si on reprend le processus dans l'ordre chronologique, index.php
charge pre.inc.php qui charge main.inc.php qui charge master.inc.php.
main.inc.php fait l'authentification, et utilise $user sans problème.
Ensuite, la contrôle est renvoyé à pre.inc.php qui, lui aussi, utilise
$user sans problème puis renvoie le contrôle à index.php.
index.php appelle llxHeader() (défini dans pre.inc.php) qui appelle
top_menu() (défini dans main.inc.php). C'est top_menu() qui appelle la
méthode showmenu() (ligne 486) définie dans eldy_backoffice.php et qui
casse tout parce que $user semble ne plus être défini.
Pourtant, à chaque niveau on appelle global $user;
C'est bien là mon problème. Si quelqu'un a un tuyau à me filer, je suis
toute ouïe.
Il s'agit donc d'une version de Dolibarr 2.1 post-beta mise-à-jour avec
une version CVS d'aujourd'hui, sans rien d'exceptionnel.
Yannick
___
Dolibarr-dev mailing list
Dolibarr-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Table subproduct dans scripts migration
Salut, Je crois qu'il manque la table llx_subproduct dans les scripts de migration, ce qui cause une erreur dans product/index.php qui, pour une raison que j'ignore parce que je ne suis pas encore bien habitué à dolibarr_print_error(), n'affiche pas la requête SQL. Donc en gros: - il manque llx_product_subproduct dans dolibarr/mysql/migration/2.0.0-2.1.0.sql - il manque un paramètre, sans doute, ligne 170 de htdocs/product/index.php qui permette de voir la requête qui foire ainsi que la raison de l'erreur renvoyée par le DBMS - ça veut dire quoi llx_? Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Re: Table subproduct dans scripts migration
Le vendredi 15 décembre 2006 à 00:11 +, Yannick Warnier a écrit : Salut, Je crois qu'il manque la table llx_subproduct dans les scripts de migration, ce qui cause une erreur dans product/index.php qui, pour une raison que j'ignore parce que je ne suis pas encore bien habitué à dolibarr_print_error(), n'affiche pas la requête SQL. Donc en gros: - il manque llx_product_subproduct dans dolibarr/mysql/migration/2.0.0-2.1.0.sql - il manque un paramètre, sans doute, ligne 170 de htdocs/product/index.php qui permette de voir la requête qui foire ainsi que la raison de l'erreur renvoyée par le DBMS - ça veut dire quoi llx_? Même problème, semble-t-il, avec llx_user_entrepot. Ça affiche plein d'erreurs pas belles partout (commande/fiche.php?id=1 ici) , ce serait pas mal de penser à faire la modif rapidement ;-) Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Re: Table subproduct dans scripts migration
Le vendredi 15 décembre 2006 à 00:15 +, Yannick Warnier a écrit : Le vendredi 15 décembre 2006 à 00:11 +, Yannick Warnier a écrit : Salut, Je crois qu'il manque la table llx_subproduct dans les scripts de migration, ce qui cause une erreur dans product/index.php qui, pour une raison que j'ignore parce que je ne suis pas encore bien habitué à dolibarr_print_error(), n'affiche pas la requête SQL. Donc en gros: - il manque llx_product_subproduct dans dolibarr/mysql/migration/2.0.0-2.1.0.sql - il manque un paramètre, sans doute, ligne 170 de htdocs/product/index.php qui permette de voir la requête qui foire ainsi que la raison de l'erreur renvoyée par le DBMS - ça veut dire quoi llx_? Même problème, semble-t-il, avec llx_user_entrepot. Ça affiche plein d'erreurs pas belles partout (commande/fiche.php?id=1 ici) , ce serait pas mal de penser à faire la modif rapidement ;-) Houla, j'avais pas capté que c'était si simple que ça. J'ai simplement copié le code SQL des tables correspondantes de mysql/tables dans mysql/migration/2.0.0-2.1.0.sql et l'affaire est dans le sac. J'ai envoyé sur le CVS aussi. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Tables livres
Salut, Les tables llx_product_cnv_livre_contrat et llx_product_cnv_livre se retrouvent dans mysql/tables mais pas dans mysql/migration et vraisemblablement il s'agit de nouvelles tables (ajoutées il y a 2 semaines). Est-ce qu'elles peuvent être considérées comme suffisamment stables pour être ajoutées au script de migration maintenant, ou est-ce que je les laisse encore un peu tranquille? Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] [TVA] llx_tva et llx_facture_fourn_tva_sum
Salut, J'ai deux questions en rapport avec la DB et la TVA. 1) À quoi sert la table llx_tva. Apparemment chez nous elle est toujours vide. La définition de la table ressemble à ceci: CREATE TABLE llx_tva ( rowid int(11) NOT NULL auto_increment, tms timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, datep date default NULL, datev date default NULL, amount double NOT NULL default '0', label varchar(255) default NULL, note text, PRIMARY KEY (rowid) ) 2) il y a une table llx_facture_tva_sum qui reprend la somme des montants de TVA versés, mais pas de llx_facture_fourn_tva_sum. Ce qui peut vouloir dire deux choses: a) llx_facture_tva_sum n'est pas utilisée (à part pour y entrer des données) b) il manque une table llx_facture_fourn_tva_sum pour comptabiliser les montants à récupérer de la TVA On dirait (au regard du code dans htdocs/compta/tva ) que llx_facture_tva_sum n'est pas utilisée du tout. Pourrait-on supprimer ces deux tables? Dois-je poster sur la liste user pour savoir si quelqu'un a encore quelque chose dans ces tables avant de les supprimer de Dolibarr? De toute façon, si je les supprime du script d'install, elles ne seront tout simplement plus créées, mais je crois qu'il reste encore un bout de script quelque part qui enregistre quelque chose dans llx_facture_tva_sum... Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] [TVA] llx_tva et llx_facture_fourn_tva_sum
Le mercredi 03 janvier 2007 à 18:27 +, Yannick Warnier a écrit : Salut, J'ai deux questions en rapport avec la DB et la TVA. 1) À quoi sert la table llx_tva. Apparemment chez nous elle est toujours vide. La définition de la table ressemble à ceci: CREATE TABLE llx_tva ( rowid int(11) NOT NULL auto_increment, tms timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, datep date default NULL, datev date default NULL, amount double NOT NULL default '0', label varchar(255) default NULL, note text, PRIMARY KEY (rowid) ) 2) il y a une table llx_facture_tva_sum qui reprend la somme des montants de TVA versés, mais pas de llx_facture_fourn_tva_sum. Ce qui peut vouloir dire deux choses: a) llx_facture_tva_sum n'est pas utilisée (à part pour y entrer des données) b) il manque une table llx_facture_fourn_tva_sum pour comptabiliser les montants à récupérer de la TVA On dirait (au regard du code dans htdocs/compta/tva ) que llx_facture_tva_sum n'est pas utilisée du tout. Pourrait-on supprimer ces deux tables? Dois-je poster sur la liste user pour savoir si quelqu'un a encore quelque chose dans ces tables avant de les supprimer de Dolibarr? De toute façon, si je les supprime du script d'install, elles ne seront tout simplement plus créées, mais je crois qu'il reste encore un bout de script quelque part qui enregistre quelque chose dans llx_facture_tva_sum... Je continue sur ma lancée. En fait llx_facture_tva_sum n'est utilisée directement que dans htdocs/facture.class.php qui y insère et en enlève des lignes, mais le seul usage (SELECT) qu'on en fait est dans la méthode getSumTva() qui n'est par ailleurs utilisée que dans le modèle de facture bernique, qui, je crois, est tombé en désuétude... Donc ça nous donne, à supprimer: - la table llx_tva et la table llx_facture_tva_sum dans le script d'install - les accès à facture_tva_sum dans htdocs/facture.class.php À modifier: - la méthode getSumTva() dans htdocs/facture.class.php pour qu'elle reprenne la TVA à partir du montant total de TVA de la facture, et pas de la table. J'ai le feu vert? Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] [TVA] llx_tva et llx_facture_fourn_tva_sum
Le mercredi 03 janvier 2007 à 18:33 +, Yannick Warnier a écrit : Le mercredi 03 janvier 2007 à 18:27 +, Yannick Warnier a écrit : Salut, J'ai deux questions en rapport avec la DB et la TVA. 1) À quoi sert la table llx_tva. Apparemment chez nous elle est toujours vide. La définition de la table ressemble à ceci: CREATE TABLE llx_tva ( rowid int(11) NOT NULL auto_increment, tms timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, datep date default NULL, datev date default NULL, amount double NOT NULL default '0', label varchar(255) default NULL, note text, PRIMARY KEY (rowid) ) Elle semble être utilisée par compta/tva/index.php mais pour faire la liste de droite dans laquelle rien ne s'affiche jamais pour moi. Je veux bien qu'on me souffle pour celle-ci. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] les traductions
Le dimanche 07 janvier 2007 à 20:08 +0100, Franky Van Liedekerke a écrit : Hi tout le monde, pour le moment le traduction est assez difficile pour maintenir (beaucoup de fichiers different, des doubles traductions, ...). Je suis en train d'essayer un swith vers gettext, qui a assez d'avantages: - plus de variable global $langs (if faut initialiser gettext en php une fois au debut) - un fichier par language - creation automatique des fichiers de language avec les lignes qui manquent (j'ai un script perl qui fait ca) et meme des traductions des mots combines (ca s'appele Fuzzy translation en gettext) Ca va encore me prendre un peut de temps, mais je pense qu'a la fin du semaine, j'aurai finis. Est-ce-que ca serait interessant pour Dolibarr? Je veux faire tout le travail concernant le switch. Salut Franky, Personnellement ça ne m'intéresse pas du tout pour deux raisons: - j'ai modifié l'extension phplangeditor pour Firefox pour permettre l'édition des fichiers de langue de Dolibarr (donc ça ne me simplifie pas la vie d'avoir gettext) - gettext, c'est bien, mais ça pue pour les applications web pour un certain nombre de raisons: 1) il faut le package gettext sur tous les systèmes sur lesquels on installe Dolibarr 2) il y a un système de caching qui est souvent frustrant 3) le même système de caching a apparemment toujours des petits problèmes avec le multi-threading d'Apache 2 (comme PHP d'ailleurs mais apparemment le apache2-mpm-prefork ne résout rien pour gettext) Si tu recherches un peu sur le net, tu trouveras rapidement de nombreuses mentions des problèmes sur lesquels on tombe avec gettext pour les applications web. Si tu veux l'extension modifiée pour Firefox, je te l'envoie en privé, ça simplifie grandement les traductions (surtout quand, comme toi, on fait tout en un coup). Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] les traductions
Le dimanche 07 janvier 2007 à 21:56 +0100, Francois Bayart a écrit : Le dimanche 07 janvier 2007 à 19:47 +, Yannick Warnier a écrit : Si tu veux l'extension modifiée pour Firefox, je te l'envoie en privé, ça simplifie grandement les traductions (surtout quand, comme toi, on fait tout en un coup). Yannick est il possible de l'avoir aussi ? Je vous l'envoie à tous les deux (ou peut-être que je peux la mettre sur le wiki) demain, avec les explications qui vont avec. Le problème c'est que je suis en discussions avec l'auteur de phplangeditor (qui était à l'école avec moi apparemment) pour qu'il intègre mes changements dans l'extension officielle, mais il n'a pas trop le temps pour l'instant. Alors il faut hacker un peu l'extension en remplaçant un des fichiers sur votre ordi par celui que j'enverrai demain (après avoir vérifié qu'il fonctionnait). En attendant, vous pouvez tous installer la vraie extension phplangeditor parce que c'est une première étape obligatoire (ça devrait être la version 2.1.1 qui fonctionne dans Firefox 1.5 et 2) Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] les traductions
Le dimanche 07 janvier 2007 à 21:53 +, Yannick Warnier a écrit : Le dimanche 07 janvier 2007 à 21:56 +0100, Francois Bayart a écrit : Le dimanche 07 janvier 2007 à 19:47 +, Yannick Warnier a écrit : Si tu veux l'extension modifiée pour Firefox, je te l'envoie en privé, ça simplifie grandement les traductions (surtout quand, comme toi, on fait tout en un coup). Yannick est il possible de l'avoir aussi ? Je vous l'envoie à tous les deux (ou peut-être que je peux la mettre sur le wiki) demain, avec les explications qui vont avec. Le problème c'est que je suis en discussions avec l'auteur de phplangeditor (qui était à l'école avec moi apparemment) pour qu'il intègre mes changements dans l'extension officielle, mais il n'a pas trop le temps pour l'instant. Alors il faut hacker un peu l'extension en remplaçant un des fichiers sur votre ordi par celui que j'enverrai demain (après avoir vérifié qu'il fonctionnait). En attendant, vous pouvez tous installer la vraie extension phplangeditor parce que c'est une première étape obligatoire (ça devrait être la version 2.1.1 qui fonctionne dans Firefox 1.5 et 2) Voilà, j'ai ajouté une page au wiki et complété la page des traductions: http://www.dolibarr.com/wikidev/index.php/PhpLangEditor#phpLangEditor_-_Modification_pour_Dolibarr http://www.dolibarr.com/wikidev/index.php/Documentation_traducteur Comme indiqué, j'ai mis le fichier de remplacement pour l'extension ici: http://glouglou.beeznest.org/phplangeditor.jar Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Suivi contacts client
Salut à tous, Je suis en pleine lecture de bouquins de marketing (quelle drôle d'idée) et je m'étonne qu'en fait il y ait si peu de possibilités d'enregistrer des infos personnelles sur les contacts. En fait, il faudrait clairement, dans la section informations personnelles, ajouter un principe de fiche d'information dans laquelle on pourrait rajouter Monsieur X aime le chocolat, Monsieur X a 5 enfants dont les noms et dates de naissance sont Juste pour vérifier, personne n'a fait un tel développement ailleurs que dans la fiche informations personnelles, si? Aussi, je constate un bug (que je m'en vais régler de ce pas) qui m'empêche d'enregistrer la date de naissance de mes contacts. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
RE: [Dolibarr-dev] release stable (était types de produits)
Le dimanche 14 janvier 2007 à 17:17 +0100, Régis Houssin a écrit : Moi je suis intéressé mais j'aimerais avant tout qu'on discute de la release de Dolibarr 2.1 stable (et qu'on puisse rajouter ceci par la suite seulement). Y a personne d'autre que moi qui veuille une stable? J'ai l'impression d'être le seul (développeur) à avoir envie de mettre une release officielle maintenant. Il ne reste pas tellement de bugs à ma connaissance, et passer au développement d'une 2.2 maintenant me paraît raisonnable. Autrement, ça fera plus d'un an entre 2.0.1 stable et 2.1.0 stable (l'annonce de release pour la 2.0.1 stable a été faite le 22 février 2006). Personnellement, j'attends le passage à 2.2 pour ajouter un mode multi-devises. En point parallèle, j'aimerais qu'on discute aussi d'un éventuel passage à l'anglais avec les commentaires du code de Dolibarr, mais ça c'est plus pour démarrer la discussion que d'arriver à une décision. je suis tout à fait d'accord, corrigeons tous les bugs avant d'ajouter des fonctionnalités supplémentaires et clôturons la 2.1 stable pour le salon Linux fin janvier comme l'année dernière !! :)) Je viens de faire un petit tour dans les bugs restants et honnêtement, on dirait bien que 80% peuvent déjà être fermés tout de suite si les responsables veulent bien rajouter des petits commentaires du type mis dans CVS, en attente de remarques ou qqchose comme ça. Le problème du statut Ready for test, c'est que c'est comme ça que je le comprends mais apparemment ce n'est pas toujours dans le code pour autant. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] traduction
Le lundi 15 janvier 2007 à 15:15 +0100, Franky Van Liedekerke a écrit : Salut, je veux traduire les mots suivantes, mais je ne sais pas la signification: Ventilation A ventiler Ventilées Quelqu'un peut me donner les mots anglais pur ventilation comptable etc ...? Je vis en Angleterre mais c'est pas pour autant que je sais comment traduire ventilation comptable :-) La ventilation, c'est le fait de répartir les éléments de ta comptabilité (ventes, achats, etc. pour rester simple) entre les différents comptes de ton code comptable. J'attends confirmation quand même, mais c'est pour t'indiquer la bonne direction. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] [Fwd: Dolibarr lightning talk request]
Mon e-mail aux organisateurs du FOSDEM pour la demande de présentation. Les lightning-talks sont des présentations de 15 minutes chronométrées avec un public de 200 à 400 personnes, généralement développeurs du monde entier. La présentation se fait en anglais je pense, bien que le public soit généralement en grande partie belge (donc mix français/néérlandais). C'est une demande, ça veut dire que ce ne sera pas forcément accepté. Commentaires bienvenus (par sur moi, sur Dolibarr :-)) Yannick Message transféré De: Yannick Warnier À: lightningtalks Sujet: Dolibarr lightning talk request Date: Mon, 15 Jan 2007 18:45:58 + Hello, My name is Yannick Warnier, and I will be coming from the United Kingdom (although I'm belgian). I'd like to know if there is still some room for new lightning talks. I'd like to talk about Dolibarr, a franco-belgian-developed CRM/ERP web application. See http://www.dolibarr.org/ (although this one seems to be down right now) or http://www.dolibarr.com/wikidev/index.php/Accueil for the french wiki. Dolibarr is a web application developed in PHP and oriented towards small and medium european companies management. So far, it has been focused on french and belgian companies, but includes translations in english and portuguese (and dutch, of course). It eases the way to deal with all the aspects of customer relationship management, stock management, financial reporting, suppliers and clients invoices management and other things. It is highly integrable with other web applications like WebCalendar, OSCommerce, LDAP and others thanks to a clever triggers system. Because of all these features, it proves a very useful application for small companies based on services like software development companies, and I am sure it will get most of the public interested. My lightning talk would be about showing what the application can do at the moment and what it can't do (multi-currency, specific stock-related features, BTS-connectivity) and particularly try to have a quick look at the triggers interface to encourage developers of other softs to plug theirs in. I have a software engineer diploma from Institut Paul Lambin in Brussels and I am a Zend certified PHP engineer. I have been developing in PHP for four years in open-source web applications. I am lead developer of Dokeos, the company behind the e-learning software of the same name, and since recently also official developer of Dolibarr (although my contribution so far has been relatively small). Picture attached. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Bravo pour le module associations,
Le mardi 16 janvier 2007 à 10:04 +0100, Franky Van Liedekerke a écrit : [...] - pour le bug de date de naissance: c'estle même problème que Yannick a corrigé pour un autre cas: mktime ne peut pas fonctionner avec une date moins de 1970 (1969, ...). Les dates après 1970 fonctionnent bien (le bug existe aussi sur linux). Si Yannick n'a pas le temps de corriger, je le fais ce soir aussi. Je vois que t'as pas réussi à attendre ce soir :-) Bon, il y a quand même quelques modifs en plus à apporter par rapport à tes changements. Je suis en train de regarder ça, donc pas touche, mais en gros, la date de cotisation suit la même logique et j'ai également remarqué que dans certains cas on a 195436 pour 1954-03-06, ce qui forcément ne va pas, donc présumant qu'une opération sur les entiers est plus rapide qu'une opération sur les strings, j'ai maintenant: $date = ($year*1000)+($month*100)+$day; plutôt que $date = $year.$month.$day; Je corrige cela dans quelques minutes, après avoir bien testé le tout. Patience. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Bravo pour le module associations,
Le mardi 16 janvier 2007 à 13:10 +0100, Franky Van Liedekerke a écrit :
Yannick,
j'ai vu que tu utilise addslashes, mais c'est dangereux si php le fait
déjà (magic_qoutes_gpc, activé par default en php.ini). Alors, je
pense que c'est mieux de créer un fonction doli_addslashes avec le
code suivante:
function doli_addslashes ($string) {
return (! get_magic_quotes_gpc ()) ? addslashes ($string) :
$string;
}
Je vais plutôt faire une autre proposition, basée sur ta remarque...
Étant donné que le but est finalement de mettre la string dans la DB
tout en évitant qu'elle ne crée des problèmes d'injection, est-ce qu'on
ne rajouterait pas une méthode dans les classes DB dans
htdocs/lib/databases/ qui échappent les string à la manière de chaque
DB?
Par exemple, on ajouterait la méthode escape_string() dans chaque
connecteur DB et pour MySQL, ce serait
function escape_string($string)
{
return mysql_real_escape_string($string);
}
Celle-là je veux bien l'ajouter tout de suite dans les trois classes DB
et changer mes addslashes().
Yannick
___
Dolibarr-dev mailing list
Dolibarr-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Bravo pour le module associations,
Le mardi 16 janvier 2007 à 12:36 +, Yannick Warnier a écrit :
Le mardi 16 janvier 2007 à 13:10 +0100, Franky Van Liedekerke a écrit :
Yannick,
j'ai vu que tu utilise addslashes, mais c'est dangereux si php le fait
déjà (magic_qoutes_gpc, activé par default en php.ini). Alors, je
pense que c'est mieux de créer un fonction doli_addslashes avec le
code suivante:
function doli_addslashes ($string) {
return (! get_magic_quotes_gpc ()) ? addslashes ($string) :
$string;
}
Je vais plutôt faire une autre proposition, basée sur ta remarque...
Étant donné que le but est finalement de mettre la string dans la DB
tout en évitant qu'elle ne crée des problèmes d'injection, est-ce qu'on
ne rajouterait pas une méthode dans les classes DB dans
htdocs/lib/databases/ qui échappent les string à la manière de chaque
DB?
Par exemple, on ajouterait la méthode escape_string() dans chaque
connecteur DB et pour MySQL, ce serait
function escape_string($string)
{
return mysql_real_escape_string($string);
}
Celle-là je veux bien l'ajouter tout de suite dans les trois classes DB
et changer mes addslashes().
Bon et voilà, mes changements sont prêts mais pas soumis. J'attends ce
soir pour voir s'il y a des objections avant de soumettre.
Yannick
___
Dolibarr-dev mailing list
Dolibarr-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Bravo pour le module associations,
Le mardi 16 janvier 2007 à 14:15 +0100, Franky Van Liedekerke a écrit :
[...]
Yannick:
Par exemple, on ajouterait la méthode escape_string() dans chaque
connecteur DB et pour MySQL, ce serait
function escape_string($string)
{
return mysql_real_escape_string($string);
}
Celle-là je veux bien l'ajouter tout de suite dans les trois classes
DB
et changer mes addslashes().
Yannick
Je suis d'accord, mais cela ne resoudre pas le problème avec
magic_qotes_gpc(), mais si tu le fais comme cesi (voir
http://www.php.net/manual/en/function.mysql-real-escape-string.php),
ca résoudre tous les problèmes:
function quote_smart($value)
{
// Stripslashes
if (get_magic_quotes_gpc()) {
$value = stripslashes($value);
}
// Quote if not a number or a numeric string
if (!is_numeric($value)) {
$value = ' . mysql_real_escape_string($value) . ';
}
return $value;
}
En effet, je constate à ma grande surprise que
mysql_real_escape_string() ne gère pas tout lui-même.
Je vote quand même pour le nom de méthode escape_string() qui est plus
intuitif, mais elle devrait contenir le code ci-dessus.
Merci,
Yannick
___
Dolibarr-dev mailing list
Dolibarr-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] [Fwd: Dolibarr lightning talk request]
Le mardi 16 janvier 2007 à 10:10 +0100, Rodolphe Quiedeville a écrit : Le 15.01.2007 23:51, Yannick Warnier a ecrit : Mon e-mail aux organisateurs du FOSDEM pour la demande de présentation. Les lightning-talks sont des présentations de 15 minutes chronométrées avec un public de 200 à 400 personnes, généralement développeurs du monde entier. La présentation se fait en anglais je pense, bien que le public soit généralement en grande partie belge (donc mix français/néérlandais). C'est une demande, ça veut dire que ce ne sera pas forcément accepté. Excellente idée, je ne pourrais pas être là pour le FOSDEM mais y aurait assiter avec plaisir, tiens nous au courant d'éventuels retours. Bah... ils viennent de m'envoyer un mail pour me signaler que tout est déjà booké. Ce sera pour l'année prochaine, dommage... Si vous avez connaissance de salons similaires en Angleterre (des fois que vous en entendriez parler et pas moi), n'hésitez pas à me le faire savoir. J'irai très probablement. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Création conditionnelle de table societe_prices
Salut à tous, J'ai deux sujets à discuter, si vous le voulez bien, pour que mon développement puisse se faire de manière plus claire: 1) je trouve ça déstabilisant de faire de la création conditionnelle de tables (par exemple la table societe_prices qui est créée par le script admin/produit.php) 2) que pensez-vous de passer officiellement à l'anglais pour la nomination des tables, des variables, et l'écriture des commentaires, ou alors d'avoir un lexique quelque part qui explique chaque nom de variable en anglais? Pour l'instant c'est inutilisable par un codeur anglophone. Concernant 1, j'étais vraiment épaté, par rapport à d'autres projets en GPL, de voir comment Dolibarr gérait ses tables, mais voir qu'il y a des créations conditionnelles de tables dont la définition est conservée dans un script en PHP, ça m'a un peu déçu... Ici je voulais résoudre un problème que Grégoire a mentionné sur la liste ce matin, je cherche donc la définition de la table pour voir quelle est sa clef primaire pour vérifier ce qui ne peut pas être répété, et je constate qu'elle n'est pas dans mysql/tables. Surpris, je cherche dans mysql/migration. Rien non plus. Enfin, je fais une recherche sur tout le code, pour trouver une référence dans admin/produit.php. Encore plus surpris, je constate que ce n'est pas la seule table qui est créée de cette façon... J'imagine qu'il y a une très bonne raison pour l'avoir mis là, mais j'ai cherché et je ne l'ai pas trouvée. Même si la création est conditionnelle (ce que je trouve incohérent avec la beauté du reste du code), il faudrait quand même profiter de cette superbe hiérarchie de fichiers et placer la définition dans mysql/tables, non? Et puis même si on ne choisit pas le mode multi-prix, je ne pense pas que quelques tables vides dans la base de données dérangeront qui que ce soit (si c'est documenté, par ailleurs). Bref, j'aimerais bien savoir s'il y a des raisons logiques à ça et si on ne pourrait pas mettre ça dans les contraintes de développement, que toutes les définitions de tables doivent se trouver dans le répertoire tables/. Hopla, merci, Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Re: [Dolibarr-cvs] dolibarr/htdocs contact.class.php adherents/adh...
Le mardi 16 janvier 2007 à 21:21 +0100, Franky Van Liedekerke a écrit : Laurent, peut-tu me dire si mktime marche en effet pour les dates 1970 sur linux? Chez moi cela ne marche quand-même pas (mais j'ai pas encore analysé) Chez moi non plus (Debian Etch), Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Dolibarr CVS du 15/01/2007 - Modification du niveau de tarif d'une société - bug non bloquant
Le mardi 16 janvier 2007 à 09:02 +0100, zcp a écrit : Bonjour Avec la version CVS du 15/01/2007 de Dolibarr, lorsque je modifie le niveau de tarif d'une société j'ai une erreur (voir plus loin). Il suffit de recharger la page et c'est pris en compte. (est ce que c'est parce que j'ai déjà des documents qui ont été fait avec un autre niveau de tarif?) Voici l'erreur : Dolibarr a détecté une erreur technique. Voici les informations qui pourront aider au diagnostic: Server: Apache/2.2.3 (Debian) PHP/5.2.0-8 Dolibarr: 2.1-beta Url sollicitée: /dolibarr/htdocs/comm/multiprix.php?id=1 QUERY_STRING: id=1 Referer: http://127.0.0.1/dolibarr/htdocs/comm/multiprix.php?id=1 Type gestionnaire de base de donnée: mysql Requete dernier acces en base en erreur: INSERT INTO llx_societe_prices ( datec, fk_soc, price_level, fk_user_author ) VALUES (now(),1,'2',2) Code retour dernier acces en base: DB_ERROR_RECORD_ALREADY_EXISTS Information sur le dernier accès en base: Duplicate entry '0' for key 1 Warning: Cannot modify header information - headers already sent by (output started at /var/www/dolibarr/htdocs/lib/functions.inc.php:1267) in /var/www/dolibarr/htdocs/comm/multiprix.php on line 50 Salut Grégoire, Ce n'est pas normal, la requête d'insertion ne mentionne pas de rowid et c'est la seule clef primaire. Donc s'il tente d'insérer '0' pour la clef '1' (comme l'indique l'erreur), ça veut dire qu'il tente d'insérer un rowid de '0', ce qui n'est pas normal si le champ est déclaré en auto_increment, comme c'est le cas dans le code de création de la table. Est-ce que tu pourrais m'envoyer un dump SQL de ta table llx_societe_prices? À defaut, si tu peux me faire une copie de la définition de ta table (onglet Structure dans phpMyAdmin) et du contenu (onglet Afficher), ça devrait aller aussi. Si c'est trop gros à envoyer sur la liste, envoie-moi ça en privé. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Dolibarr CVS du 15/01/2007 - Modification du niveau de tarif d'une société - bug non bloquant
Le mardi 16 janvier 2007 à 23:37 +0100, zcp a écrit : Yannick Warnier a écrit : Le mardi 16 janvier 2007 à 09:02 +0100, zcp a écrit : Bonjour Avec la version CVS du 15/01/2007 de Dolibarr, lorsque je modifie le niveau de tarif d'une société j'ai une erreur (voir plus loin). Il suffit de recharger la page et c'est pris en compte. [...] llx_societe_prices ( datec, fk_soc, price_level, fk_user_author ) VALUES (now(),1,'2',2) Code retour dernier acces en base: DB_ERROR_RECORD_ALREADY_EXISTS Information sur le dernier accès en base: Duplicate entry '0' for key 1 [...] Ce n'est pas normal, la requête d'insertion ne mentionne pas de rowid et c'est la seule clef primaire. Donc s'il tente d'insérer '0' pour la clef '1' (comme l'indique l'erreur), ça veut dire qu'il tente d'insérer un rowid de '0', ce qui n'est pas normal si le champ est déclaré en auto_increment, comme c'est le cas dans le code de création de la table. J'ai l'impression qu'il n'y a pas d'auto-incrémentation... Essaie de rajouter une auto-incrémentation. Dans phpMyAdmin c'est très simple en éditant le champ dans l'onglet 'structure' et en ajoutant un attribut AUTO_INCREMENT. Juste pour être sûr que le problème vient de là quoi... Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Dolibarr CVS du 15/01/2007 - Modification du niveau de tarif d'une société - bug non bloquant
Le mercredi 17 janvier 2007 à 16:31 +0100, zcp a écrit : Yannick Warnier a écrit : Le mardi 16 janvier 2007 à 23:37 +0100, zcp a écrit : Yannick Warnier a écrit : Le mardi 16 janvier 2007 à 09:02 +0100, zcp a écrit : Bonjour Avec la version CVS du 15/01/2007 de Dolibarr, lorsque je modifie le niveau de tarif d'une société j'ai une erreur (voir plus loin). Il suffit de recharger la page et c'est pris en compte. [...] llx_societe_prices ( datec, fk_soc, price_level, fk_user_author ) VALUES (now(),1,'2',2) Code retour dernier acces en base: DB_ERROR_RECORD_ALREADY_EXISTS Information sur le dernier accès en base: Duplicate entry '0' for key 1 [...] Ce n'est pas normal, la requête d'insertion ne mentionne pas de rowid et c'est la seule clef primaire. Donc s'il tente d'insérer '0' pour la clef '1' (comme l'indique l'erreur), ça veut dire qu'il tente d'insérer un rowid de '0', ce qui n'est pas normal si le champ est déclaré en auto_increment, comme c'est le cas dans le code de création de la table. J'ai l'impression qu'il n'y a pas d'auto-incrémentation... Essaie de rajouter une auto-incrémentation. Dans phpMyAdmin c'est très simple en éditant le champ dans l'onglet 'structure' et en ajoutant un attribut AUTO_INCREMENT. Juste pour être sûr que le problème vient de là quoi... Yannick Bonjour J'ai ajouté auto-increment comme il faut à rowid et il n'y a plus d'erreurs. De plus, je vois maintenant l'historique des modifications. Merci Un oublie à la création des tables Non, je pense qu'il s'agit plutôt d'un bug dans une des fonctions de création de tables. Je vais vérifier ceci dès que possible. Comme le module est optionnel, il est resté un peu à l'écart de nos yeux affûtés de bons codeurs, si tu vois ce que je veux dire... :-) (en fait ce que je veux dire c'est que la faute est entièrement sur nous d'avoir laissé passé un truc pareil, sauf si une mise-à-jour et une installation fraîche y change quelque chose pour toi, ce qui voudrait dire que le développeur impliqué a changé ça par lui-même déjà). Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Licences non GPL
Salut, Je note, en passant, et sans rajouter de commentaire aucun, que dans le code JavaScript utilisé sur certaines pages de Dolibarr, on retrouve, sans pour autant que ce soit le seul élément de ce genre: 392// 393// NOTICE: You may use this code for any purpose, commercial or 394// private, without any further permission from the author. You may 395// remove this notice from your final code if you wish, however it is 396// appreciated by the author if at least my web site address is kept. 397// 398// You may *NOT* re-distribute this code in any way except through its 399// use. That means, you can include it in your product, or your web 400// site, or any other form where the code is actually being used. You 401// may not put the plain javascript up on your site for download or 402// include it in your javascript libraries for download. 403// If you wish to share this code with others, please just point them 404// to the URL instead. 405// Please DO NOT link directly to my .js files from your site. Copy 406// the files to your server and use them there. Thank you. 407// === Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Impossible de suprimmer un produit (version CVS du 15 ou du 17 janvier 2007)
Le mercredi 17 janvier 2007 à 17:35 +0100, zcp a écrit : Bonjour Je n'arrive pas à suprimmer un produit. Il me dit que le produit est bien suprimmé de la base... mais il est encore présent comme si je n'avais rien fait. J'ai mis le produit hors vente en attendant. Ce produit n'est pas utilisé dans quoique ce soit. Salut Grégoire, Est-ce que tu pourrais rajouter ce bug, ainsi que le précédent duquel on discute avec la clef primaire de la table llx_societe_prices dans le BTS? (Bug Tracking System: https://savannah.nongnu.org/bugs/?group=dolibarr ) Avec un maximum de détail. Les mettre dans le BTS permet de s'assurer qu'on ne perd pas leur trace. Par exemple, pour le moment, je n'ai pas le temps de régler le problème de la clef primaire de llx_societe_prices et ça pourrait, à terme, disparaître sous le poids de mes autres tâches. Merci, Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Licences non GPL
Le jeudi 18 janvier 2007 à 02:27 +0100, Régis Houssin a écrit : Le 17.01.2007 17:24, Yannick Warnier a ecrit : Salut, Je note, en passant, et sans rajouter de commentaire aucun, que dans le code JavaScript utilisé sur certaines pages de Dolibarr, on retrouve, sans pour autant que ce soit le seul élément de ce genre: 392// 393// NOTICE: You may use this code for any purpose, commercial or 394// private, without any further permission from the author. You may 395// remove this notice from your final code if you wish, however it is 396// appreciated by the author if at least my web site address is kept. 397// 398// You may *NOT* re-distribute this code in any way except through its 399// use. That means, you can include it in your product, or your web 400// site, or any other form where the code is actually being used. You 401// may not put the plain javascript up on your site for download or 402// include it in your javascript libraries for download. 403// If you wish to share this code with others, please just point them 404// to the URL instead. 405// Please DO NOT link directly to my .js files from your site. Copy 406// the files to your server and use them there. Thank you. Quoi Il faut supprimer ce code de suite, j'ai toujours été contre le Javascript dans Dolibarr et cela ne va pas arranger mon aversion Merci à l'auteur de supprimer de suite ce code et de vérifier toutes les inclusions de code plus scrupuleusement. en scrutant le cvs nous savons tous qui a mis ce code, par contre Rodolphe je pense que le javascript (ou l'ajax) permet déjà d'ajouter des fonctionnalitées supplémentaires que le php ne peut apporter et qui apportent des fonctions très productives. Comme je respecte ton choix, nous nous efforçons d'ajouter du javascript ou de l'ajax tout en donnant l'option de l'activer ou le désactiver tout en gardant les fonctionnalitées recherchées. Maintenant concernant la licence du script en question, si on relit attentivement il est précisé que si nous avons l'autorisation de l'auteur du script nous pouvons l'utiliser à des fins commerciales. Salut, Je suis d'accord pour les fonctionnalités JavaScript/AJAX ajoutées. Pour ce qui est de la licence, les termes ne sont pas de la GPL et la GPL est très contraignante à ce niveau. Le seul moyen de récupérer ce code est de demander à l'auteur de le rendre GPL ou LGPL ou une licence plus permissive. Il y a aussi un autre bout de code qui exige qu'une mention de l'origine du code (le site web d'où ça vient) reste attachée au code, ce qui l'empêche d'être GPL, et aussi montre une volonté (peut-être inconsciente) de l'auteur de ne pas le mettre en GPL. Cela dit, pour ces deux bouts de code, je suis certain qu'on peut les trouver en GPL (que ce soit dans del.icio.us ou dans Dojo Toolkit ou autre grosse librairie DHTML en GPL). Reste à les trouver. Une première étape passerait par une description de ce qu'elles font, que tout le monde puisse chercher un truc similaire. Personnellement, si on a l'intention de rajouter du DHTML, je serais pour une intégration d'une et une seule grosse librairie qui gère ça de façon cohérente. del.icio.us fait ça pour DHTML Dojo Toolkit est beaucoup plus complet, plus stable et fait apparemment une espèce de bootstrapping de code JS où il ne charge le JS qu'à la demande (évitant ainsi d'avoir 300K de JavaScript pour une page qui ne l'utilise pas). Cela dit la librairie en soi est grande et la doc est, paraît-il, pas terrible. XAJAX est une librairie centrée sur AJAX mais qui permet d'abstraire le niveau JavaScript (c'est en PHP qu'on code quasi tout). Enfin, il y a matière à discussion mais je crois que ce seraient les 3 les plus appropriés pour une application complète comme Dolibarr. Et ça ne presse pas, mais ça vaut la peine d'en discuter un jour, peut-être même oralement. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
RE: [Dolibarr-dev] [André] Création conditionnelle de table societe_prices
Le lundi 22 janvier 2007 à 01:23 +0100, Régis Houssin a écrit : Hello, Et bien de mémoire (ça remonte à pas mal de temps quand même), j'avais fait ce choix pour éviter d'encombrer inutilement la BD, pensant que peu de personnes allaient utiliser ce module. J'avais constaté que d'autres avait procédé ainsi dans d'autres modules. C'est quoi en fait le blème ? J'ai pas eu le début de vos échanges. A+ P.-S. : pas trop fort le fouet régis, j'ai encore une côte douloureuse ;-) C'était juste le fait de créer les tables mêmes si elles ne servent pas et de ne pas les créer dynamiquement lors de l'activation du module. Et puis je m'en fous de ta côte cassée, tu auras des coups de fouet quand même !!! ;-)) Tout me semble se diriger vers la suppression de la création de ces tables dynamiques (et les coups de fouet :-)). Personnellement, je ne le ferai pas par envie d'éviter l'erreur, mais je mets une note sur le wiki pour que ça ne se reproduise plus, et je rappelle que pour l'instant il y a un problème dans la fonction qui crée ces tables, qui fait que la clef primaire n'est apparemment pas définie ou pas auto-incrémentée (ce qui pose problème à l'utilisation du module). Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] demo
Le mardi 23 janvier 2007 à 20:58 +0100, Franky Van Liedekerke a écrit : On Tue, 23 Jan 2007 17:08:47 +0100 zcp [EMAIL PROTECTED] wrote: - ne permet pas qqn de créer un loop pour des sous-produits - types de produits: raw, assembly, stockkit - stock mouvements corrigé pour sous-produits et aussi cancel/delete d'un commande [...] Regarde le structure du produit prod2 pour les sous-produits (du type assembly), et aussi celui du prod5 (type stockkit). Pour assembly, les sous-produits n'apparaissent pas sur la facture (et le stock est seulement correct quand le commande est fermé), contraire aux type stockkit. J'ai un peu de mal avec ces termes anglais : stokkit, assembly (ça, c'est du produit monté/assemblé) Et pour les services? stockkit: ca devient visible sur la facture, assembly pas (parce-que c'est assemblé) Est-ce-qu'il y a des services combinés? Oui, je pense que si tu proposes un service du genre installation de Dolibarr sur site. Ce serait plutôt en stock-kit. Ça pourrait contenir (comme kit de services): - analyse des besoins (1 journée) - réservation nom de domaine (1 heure) - configuration du serveur (4 heures) - installation de Dolibarr (1 heure) - préconfiguration de Dolibarr (1 journée) Et un autre kit pourrait être installation de Joomla!: - analyse des besoins (1 journée) - réservation de nom de domaine (1 heure) - configuration du serveur (4 heures) - installation de Joomla! (1 heure) - préconfiguration de Joomla! (1 journée) Enfin... c'est un exemple, mais je pense qu'à terme c'est réaliste. Ça ne change bien sûr rien au fait que je pense qu'il serait mieux de faire une release de la 2.1.0 avant d'intégrer ces changements spécifiques... Yannick Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] demo
Le mercredi 24 janvier 2007 à 00:35 +0100, zcp a écrit : Yannick Warnier a écrit : Le mardi 23 janvier 2007 à 20:58 +0100, Franky Van Liedekerke a écrit : On Tue, 23 Jan 2007 17:08:47 +0100 zcp wrote: - ne permet pas qqn de créer un loop pour des sous-produits - types de produits: raw, assembly, stockkit - stock mouvements corrigé pour sous-produits et aussi cancel/delete d'un commande [...] Regarde le structure du produit prod2 pour les sous-produits (du type assembly), et aussi celui du prod5 (type stockkit). Pour assembly, les sous-produits n'apparaissent pas sur la facture (et le stock est seulement correct quand le commande est fermé), contraire aux type stockkit. [...] stockkit: ca devient visible sur la facture, assembly pas (parce-que c'est assemblé) Est-ce-qu'il y a des services combinés? Oui, je pense que si tu proposes un service du genre installation de Dolibarr sur site. Ce serait plutôt en stock-kit. Ça pourrait contenir (comme kit de services): - analyse des besoins (1 journée) - réservation nom de domaine (1 heure) - configuration du serveur (4 heures) - installation de Dolibarr (1 heure) - préconfiguration de Dolibarr (1 journée) Bonsoir En gros, il faut que je combine produits et services? D'ailleurs, est ce que services et produits fonctionnent de la même manière? ce n'est qu'un numéro dans la BD 0,1... C'est vrai qu'il n'y a pas de livraison pour un service, et pourtant, l'analyse des besoin est un service, livré en 1 journée. Non non, un service n'est définitivement pas livré. Même s'il y a déplacement, ça n'est toujours pas une livraison (c-à-d engendrant des frais supplémentaires ou un enregistrement d'une livraison). Un service a des dates de validité ou d'étendue, c'est comme on veut bien le comprendre, mais je crois que c'est suffisant à ce niveau-là. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Quelques correction de bug ou de features en vrac
Le mercredi 24 janvier 2007 à 17:32 +0100, zcp a écrit : Yannick Warnier a écrit : Salut Grégoire et Franky, L'accès de Franky, contrairement aux protestations qui ont suivies et sont restées sans réponses, principalement pour ne pas agrandir le conflit, lui a été retiré pour des raisons précises (introduction d'un facteur risque trop important, non-communication autour de certains correctifs risqués, non-limitation aux correctifs de bugs signalés sur Savannah) qui étaient au départ des conditions à son ajout aux accès en écriture CVS. Bonjour Je suis d'accord avec l'ensemble de ton message. J'ai qune questions : Que signifie non limitations aux correctifs de bugs signalés sur Savannah ? Est ce que c'est lorsque que l'on corrige plus que le bug et que l'on fait un patch pour ce bug (et d'autres) sans précisier les autres correction? Oui, et ça se reflète parfois par une modification qui cause un problème B en fixant un problème A. C'est pour ça qu'il faut passer par un vérificateur. Enfin, je dis pas que la majorité était mauvais, loin de là, mais un petit peu d'erreurs, sans communication, ça suffit pour causer de gros dégâts. [...] [...] L'envoi de patches est documenté dans la doc développeur sur le wiki, et c'est une solution valable pour un développeur. C'est comme ça que fonctionnent un grand nombre d'autres projets libre. Cela répond donc à ton problème d'autre moyen pas trop pénible. Je vais aller regarder. Je pense que, comme le souligne la réponse de Rodolphe à un autre post il y a quelques minutes, il est bon de laisser un peu de temps aux développeurs principaux pour revoir le code de Franky (ou d'autres comme Jean par exemple) avant de l'intégrer. Le monde ne s'est pas créé en un jour, et pourtant même lui il a plein de bugs. C'est ce que je sous entendais avec l'incorporation ... j'ai pensé à un gateau au chocolat... Oui, il faut du temps, bien sur, c'est même souhaitable, parce que cela donne une cohérence au code. C'est pas mal l'idée du gâteau au chocolat... Si le travaille de Franky est modifié pour être intégré, pourquoi pas. C'est l'idée. Pour ce qui à été fait aujourd'hui par Franky, je ne le perçois pas comme des ajouts de fonctionnalités, mais plutôt comme des corrections de failles de sécurité (terme peut être exagéré ici). Donc, au contraire, le travail de Franky doit être supervisé, par un regard neuf et avisé. (et si ça peu éviter le stress...) Alors je crois qu'on est tous sur la même longueur d'ondes, même si le message est peut-être passé de travers. Le travail de Franky est très bien, on voudrait juste l'accompagner un peu au début pour éviter de le laisser faire plein de choses trop vite, et que par manque de temps nous laissions passer des erreurs dangereuses. Rien de plus, rien de moins. Je parle en mon nom ici, libre aux autres de me suivre ou pas, mais je pense que la clarification pourra aider à retrouver le chemin de la bonne entente sur la liste. Ben, il me semblait qu'il y à encore de la bonne entente. Franky à trouvé un moyen pour faire son travail et le faire tester. S'il avait vraiment été découragé, il ne l'aurait pas fait (et j'aurais été le premier ennuyé). CQFD. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
RE: [Dolibarr-dev] tout mes changes
Le samedi 27 janvier 2007 à 08:02 +0100, Vianney ASSOFI a écrit : Salut à tous, :) Vu l'investissement de Franky, je vais peut être repenser à upgrader mon code ... :p Avant j'hésitais, n'étant pas développeur je risquais de trouver des bugs qui mettraient du temps à être corrigés du fait du manque de temps (compréhensible) de chacun ... mais la ... waooo que de modifications et si vite ... alors je me prends à imaginer que si je trouve des bugs bloquants j'aurais peut être plus de facilité à trouver des réponses rapides :p qu'à un moment, il y a quelques mois ... J'imagine que pas mal de gens sont peut être dans mon cas :p Ca serait d'ailleurs peut être pas mal d'avoir un mode d'installation du genre : Upgrade déporté qui serait capable de collecter les données du site ancien, de les recopier sur le site nouveau et ENSUITE de faire l'install en upgrade et cela de manière automatique ;) a j'en demande trop ? :) Bref je ne veux pas encore relancer de polémique, mais de voir une telle activité m'a donné envie de réessayer de passer à la dernière version bien que je sache que depuis ma version il y a eu tellement de changement que je vais devoir me rechier mes modèles (facture et propale) à la main (ce qui me prend des heures à chaque fois ...) -de plus j'aurais un problème de compatibilité entre le passé et le futur si je dois re-générer- Salut, Vu qu'on est tous motivés à sortir la 2.1.0 bientôt, je te recommande d'attendre encore un peu. Les derniers changements causent quelques problèmes par-ci par-là. Par contre, si tu veux aider à tester, ce que tu peux faire c'est faire un dump de ta base de données (mysqldump -u login -p --result-file=base.sql nom_de_la_base) et la régénérer sous un autre nom ailleurs, et faire une copie de ton répertoire d'install et régénérer la copie ailleurs, puis remettre le tout ensemble et upgrader à la dernière version de développement. M... je crois que je vais faire une page wiki pour ça tiens, histoire d'aider les testeurs à ne pas envoyer leur install en l'air pour tester. Voilà, j'ai rajouté une section Testeurs sur le wiki... Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] tout mes changes
Le samedi 27 janvier 2007 à 10:17 +0100, Franky Van Liedekerke a écrit : On Sat, 27 Jan 2007 08:21:54 + Yannick Warnier [EMAIL PROTECTED] wrote: Salut, Vu qu'on est tous motivés à sortir la 2.1.0 bientôt, je te recommande d'attendre encore un peu. Les derniers changements causent quelques problèmes par-ci par-là. sauf qu'il-y-a encore des bugs dans CVS (voir la description de mes changements) pour different choses. Oui Franky, j'ai bien compris, seulement je suis aussi *dangereux* que toi au niveau connaissance du code, alors je préfère attendre que quelqu'un intègre tes propositions de changement plutôt que de le faire moi-même. Par ailleurs, pourrais-tu envoyer tes changements (pas changes) en udiff comme tu le proposes, afin que celui qui veut les revoir ait directement tout ce qu'il faut à disposition? Tu peux les envoyer sur la liste, séparés par bug (pas par fichier) par exemple, et quelqu'un finira bien par s'en occuper. Ou tout ensemble c'est bien aussi mais ce sera plus compliqué d'analyser le code problème par problème. Merci, Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Gestion des arrondis dans les prix
Le lundi 29 janvier 2007 à 16:45 -1000, Jean a écrit : Bonjour, En Polynésie la monnaie locale est le franc pacifique qui n'a pas de décimale, donc on se retrouve régulièrement avec des problèmes d'arrondis. dolibarr stocke les valeurs avec deux décimales par ex PrixHT 45.35 TVA 3.25 PTTC 48.60 Si j'arrondis (nb décimales à 0), je vais afficher prixHT 45, TVA 3 et PTTC 49 (au lieu de 48). Comment feriez-vous ? Je crois que ça nécessite un choix lorsque l'on configure Dolibarr (tout comme on choisit la devise dans laquelle on travaille). Je suggère que l'on intègre ce choix dans la fonction price() qui sert à afficher tous les prix dans Dolibarr, pour la version 2.2.0 de Dolibarr. Yannick PS: C'est bien qu'il soit pacifique, votre franc! :-) ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] gestion des arrondis
Le mardi 30 janvier 2007 à 13:08 -1000, Tahiti Rimai (Jean) a écrit :
Voici comment je propose de patcher la fonction price :
création d'un variable NB_DECIMALES positionnée à 2 ajout de la
propriété nbdecimals à l'objet Translate et une méthode function
setDefaultDecimals($nbdec)
{
$this-nbdecimals = $nbdec;
}
initialisation de l'objet global $langs dans master.inc.php
$nbdec=dolibarr_get_const($db, 'NB_DECIMALES');
$langs-setDefaultDecimals($nbdec);
modification dans functions.inc.php fonction price()
// On pose par defaut 2 decimales
$decimal = $langs-nbdecimals;
ainsi en Polynésie on met la variable globale NB_DECIMALES à 0 et
l'affichage devrait être bon.
Et c'est là qu'est le hic : On ne règle que l'affichage, dans la base de
données on stocke toujours les valeurs avec décimales et on calcule avec
les décimales donc on va tomber sur des cas comme l'exemple cité où
l'arrondi de la somme est différent de la somme des arrondis. 3.25 +
4.32 = 7.57 et si tu arrondis à l'affichage (fonction price) : 3 + 4 = 8
Pourrait-on appeler la fonction price() avant l'insertion en base de
données, ou une fonction équivalente qui n'est pas liée à l'affichage ?
Salut Jean,
Je ne crois pas que la classe Translate soit un bon endroit pour faire
ça. En fait il faudrait plutôt une nouvelle classe Localisation ou un
truc comme ça. Je m'explique.
Dans certains pays, il y a plusieurs langues nationales (la Belgique,
par exemple, en compte 3 + l'anglais qui est fort pratiqué mais n'est
pas national).
D'autres pays ont des réglementations différentes selon les états, comme
les États-Unis, qui ont pourtant la même langue nationale.
Par ailleurs, la langue que tu utilises dans Dolibarr n'est pas d'office
la langue nationale du pays dans lequel tu pratiques (dans lequel ta
société se trouve). La langue change aussi selon les utilisateurs,
parfois, et ça ne doit pas changer le fonctionnement des décimales pour
autant.
Je suggère donc d'avoir une classe Localisation ou Legal ou quelque
chose comme ça, qui soit en relation avec une ou deux tables dans la DB
et qui définissent un certain nombre de règles par pays+état ou pays
+région peut-être. Ces règles seraient donc stockées dans la base de
données et permettraient, à la longue, d'avoir une superbe adaptation
aux règles en vigueur en choisissant, à la configuration de Dolibarr, de
quel pays+état on veut les règles.
On aurait donc:
- 1 table llx_pays (on l'a déjà)
- 1 table llx_region (on l'a déjà, je crois) qui dépend de pays
- 1 table llx_legal_var qui contient 1 id de région, 1 nom de variable
et sa valeur.
Elle contiendrait des variables comme:
- decimal_precision (la précision des arrondis)
- currency (la monnaie utilisée) (et peut-être aussi sa valeur par
rapport à l'euro ou par rapport au dollar ou un truc qui permet de
comparer plus ou moins)
- tax_return_day (le jour de la fin de l'année financière et/ou du dépôt
de la déclaration au bureau des impôts)
... (autres choses qui ne manqueront pas d'apparaître petit à petit)
Franchement, ça m'a l'air nettement mieux comme ça, ça offre de la
flexibilité et en même temps ça empêche le blocage plus loin.
Je le mettrai dans la Roadmap pour la 2.2.0 après discussion et avis. De
toute façon je suis déjà prêt à me lancer dans le développement du
traitement des conversions multi-devises, alors ça n'est pas un gros
problème de faire ce genre de truc-là en plus.
Yannick
PS: On sent qu'on a la moitié de l'effectif au salon Solutions Linux...
___
Dolibarr-dev mailing list
Dolibarr-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] facturedet.fk_product NULL et script de migration 2.0-2.1
Salut, J'ai un bug dans ma version CVS de décembre, mais je viens de vérifier les dernières versions et le problème est toujours là d'une certaine façon. Mes tables ont été crées il y a longtemps, mais j'ai souvent mis à jour avec le script dans mysql/migration/ de la 2.0 à la 2.1. La table llx_facturedet, chez moi, est déclarée comme suit: fk_product integer NOT NULL default 0 Or la définition de la table dans mysql/tables/ dit maintenant: fk_product integer NULL, Le code qui insère des rangées là-dedans (htdocs/facture.class.php) insère NULL quand il n'y a pas de produit, mais ma table est toujours en NOT NULL, ce qui m'incite à penser qu'il manque quelque chose dans le script de migration, soit ceci: ALTER TABLE llx_facturedet modify fk_product integer NULL; UPDATE llx_facturedet SET fk_product=NULL WHERE fk_product=0; Est-ce que je me trompe? Je fais la modif dans CVS, vu que de toute façon au pire ça met le champ à sa déclaration courante, mais au cas où quelque chose est mauvais dans mon raisonnement, merci de me le faire savoir. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Licence MIT
Salut, Je vois qu'on a une licence MIT qui vient de passer. Je *pense* que c'est compatible GPL, mais est-ce qu'il y a quelqu'un qui en est certain? La seule différence directement visible c'est que le MIT demande que la note de licence soit conservée. Je pense que étant donné que la licence GPL impose que ce qui l'utilise devienne GPL (en gros hein, parce que c'est uniquement dans certains cas), ça ne devrait pas poser de problème... Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] different types de produits
Le lundi 12 février 2007 à 13:00 +0100, Franky Van Liedekerke a écrit : (je m'excuse, ctrl-return trop vite ...) Bonjour, sur mon site de test, vous pouvez tester encore toujours mon patch avec: - correction gestions de stock - différent types de produits Si les devs y sont intéressés, je veux bien envoyer mon patch vers le liste. Salut Franky, Je pense que tu peux toujours envoyer le patch au lieu de demander si nous sommes intéressés. La dernière fois aussi tu as demandé, et je t'ai demandé de l'envoyer et il a ensuite été intégré. Autant éviter les étapes inutiles... Merci, Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] patch: different types de produits
On en a déjà discuté sur cette liste (mail de Franky justement, le 14 janvier à 14h34 ou 15h34). Ça correspond à un produit qui regroupe plusieurs produits tout en montrant le détail des produits composants. Yannick Le lundi 12 février 2007 à 17:14 +0100, Régis Houssin a écrit : Je viens de regarder et j'avais une question, a quoi correspond le stockkit ? Merci Régis Bonjour, sur mon site de test, vous pouvez tester encore toujours mon patch avec: - correction gestions de stock - différent types de produits (les sousproduits maintenant sont le type assembly, avec un tout petit query sql on peut converter les sousproduits qui existent déjà ). https://holem.belnet.be/dolibarr/htdocs (j'ai fait un sync avec cvs ce matin, et fait un update du db avec le script de migration) Dans attach, vous trouvez le patch qui fait tout. Franky ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Dolibarr-dev] Encryption de mots de passe et rappel par e-mail
Salut,
Lors de l'utilisation de mots de passe encryptés, l'envoi du mot de
passe ne semble pas fonctionner du tout. Je dois encore procéder à
quelques vérifications, mais ça me semble possible puisque l'ajout de
l'encryption s'est fait récemment.
Enfin, si quelqu'un peut confirmer que c'est toujours le cas avec la
dernière version CVS, je rajoute ça dans les feature requests.
Dans le cas de l'encryption, les autres applications qui font ce genre
de choses utilisent généralement un lien contenant un hash md5 ou un
truc du genre qui permet d'identifier directement l'utilisateur et de
lui générer un nouveau mot de passe qu'on lui envoie par e-mail. Ça
reste dangereux mais apparemment c'est ce qu'on fait dans ce genre de
cas.
Donc l'algorithme pseudo-code c'est:
//génération du lien
$lien =
'login.php?reset='.md5($secret_key.$user-email).'id='.$user-id;
mail($mailFrom, $user-email, 'pass reset',$lien);
//reset du mot de passe
if($_GET['reset'] $_GET['id']){
//compare l'email contenu dans le lien et celui de l'ID
//de l'utilisateur
//si correct, génération nouveau pass et envoi par e-mail
$newpass = generate_new_pass('...');
$body = 'New pass: '.$newpass;
$user-pass = $newpass;
mail(..,$body);
}
Yannick
___
Dolibarr-dev mailing list
Dolibarr-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Encryption de mots de passe et rappel par e-mail
Le lundi 12 février 2007 à 18:48 +0100, herve couvelard a écrit :
//génération du lien
$lien =
'login.php?reset='.md5($secret_key.$user-email).'id='.$user-id;
mail($mailFrom, $user-email, 'pass reset',$lien);
//reset du mot de passe
if($_GET['reset'] $_GET['id']){
//compare l'email contenu dans le lien et celui de l'ID
//de l'utilisateur
//si correct, génération nouveau pass et envoi par e-mail
$newpass = generate_new_pass('...');
$body = 'New pass: '.$newpass;
$user-pass = $newpass;
mail(..,$body);
}
les actions (par rapport aux consultations) se font plus généralement en
POST et non en get.
Mais dans ce cas-ci on vient directement d'un e-mail, c'est pourquoi les
variables sont dans l'URL (on évite ainsi de devoir envoyer à
l'utilisateur un mail contenant une page HTML et un formulaire).
Yannick
___
Dolibarr-dev mailing list
Dolibarr-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Encryption de mots de passe et rappel par e-mail
Le lundi 12 février 2007 à 18:49 +0100, zcp a écrit : Yannick Warnier a écrit : Salut, Lors de l'utilisation de mots de passe encryptés, l'envoi du mot de passe ne semble pas fonctionner du tout. Je dois encore procéder à quelques vérifications, mais ça me semble possible puisque l'ajout de l'encryption s'est fait récemment. Enfin, si quelqu'un peut confirmer que c'est toujours le cas avec la dernière version CVS, je rajoute ça dans les feature requests. Dans le cas de l'encryption, les autres applications qui font ce genre de choses utilisent généralement un lien contenant un hash md5 ou un truc du genre qui permet d'identifier directement l'utilisateur et de lui générer un nouveau mot de passe qu'on lui envoie par e-mail. Ça reste dangereux mais apparemment c'est ce qu'on fait dans ce genre de cas. Bonsoir Personnellement, j'aime bien la méthode employée par Spip. Déjà, c'est basé sur un ticket qui change à chaque session, et, le mot de passe saisi par l'utilisateur subie un premier hachage MD5 (avec le ticket aléatoire) et ensuite le serveur refait un hachage md5, puis fait les comparaisons. Dans le cas d'un oublie de mot de passe, l'utilisateur fait une demande avec son e-mail et reçois par e-mail un lien qui va lui permettre de changer son mot de passe. Je ne vois pas bien ce que tu veux dire par ticket unique (qui m'a fort l'air d'être un simple identifiant de session), ni par premier hachage MD5 et hachage MD5 par le serveur, mais je comprends ce que tu décris comme le système qu'on a actuellement dans Dolibarr. L'ajout de l'encryption au niveau de la base de données se fait uniquement pour éviter le vol (volontaire ou involontaire) de mots de passe par des utilisateurs qui n'ont pas besoin de les voir. Yannick ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Gestion des droits à propos des Documents
Salut Jean-René, Pourrais-tu ajouter ce point au BTS (Bug Tracking System) sur Savannah, histoire qu'on ne le perde pas de vue? Pour l'instant on est plus ou moins en feature-freeze (pas de nouvelles fonctionnalités) jusqu'à la release de la 2.1 stable, et ton idée est bonne mais elle devrait attendre ce moment pour être intégrée. Yannick Le mercredi 21 février 2007 à 16:23 +0100, ATHANASE Jean-René a écrit : Hello, Au niveau des droits assujettissant l'objet société, il faudrait rajouter les options suivantes à propos des documents et cela vaut aux différents endroits ou apparaît cet objet comme les factures, propositions, etc. : 1. consultation ; 2. importation ; 3. suppression. Cordialement. JR ATHANASE ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
