https://doc2-fr.openflyers.com/api.php?action=feedcontributions&feedformat=atom&user=Zebuline 2026-05-01T02:39:15Z Contributions de l’utilisateur MediaWiki 1.24.1 https://doc2-fr.openflyers.com/index.php?title=Discussion:TODO&diff=5746 2006-10-13T13:22:41Z

<p>Zebuline : /* OF 2.0beta */</p> <hr /> <div></div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Discussion:TODO&diff=5465 2006-09-05T20:47:27Z

<p>Zebuline : /* OF 2.0beta */</p> <hr /> <div>=OF 2.0beta=<br /> *Page de saisie des réglements. Modifier très légèrement la validation de cette page de façon à ce que lorsque un réglement est saisi, on revienne sur cette page (formulaire donc) avec affiché en haut le réglement qui vient juste d'être saisi. Le but est permettre au trésorier ou secrétaire qui saisit les réglements les uns après les autres de pouvoir aller aussi vite que possible.<br /> <br /> Déjà fait non ? Ou c'est pas complet ? :) --[[User:Zebuline|Zebuline]] 18:27, 3 September 2006 (CEST)<br /> <br /> non, ce n'est pas fait. Lorsqu'on saisi un réglement on va sur une page qui dit : &quot;Transaction enregistrée&quot;. C'est tout.<br /> <br /> c'est quoi la page de saisie des règlement en question ? --[[User:Zebuline|Zebuline]] 07:53, 4 September 2006 (CEST)<br /> <br /> C'est le menu &quot;Comptes/Approvisionner un compte&quot;. A propos, lorsqu'on est sur cette page, le titre est &quot;Comptes • Liste des comptes&quot; pas forcément logique...--[[User:Claratte|Christophe]] 13:53, 5 September 2006 (CEST)<br /> <br /> C'est une erreur :) (je corrige de suite)<br /> <br /> Sinon, je ne vois pas le rapport avec le trésorier : c'est un formulaire côté cahier, réservé à l'utilisateur connecté, afin d'approvisionner _ses_ comptes. Donc pourquoi aurait-il besoin d'aller plus vite pour saisir un approvisionnement à la fois ?? Pour le trésorier, tout se fait côté admin, et là on reste sur le formulaire, &quot;pour qu'il aille plus vite&quot; --[[User:Zebuline|Zebuline]] 22:47, 5 September 2006 (CEST)</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Discussion:TODO&diff=5455 2006-09-04T05:53:34Z

<p>Zebuline : </p> <hr /> <div>=OF 2.0beta=<br /> *Page de saisie des réglements. Modifier très légèrement la validation de cette page de façon à ce que lorsque un réglement est saisi, on revienne sur cette page (formulaire donc) avec affiché en haut le réglement qui vient juste d'être saisi. Le but est permettre au trésorier ou secrétaire qui saisit les réglements les uns après les autres de pouvoir aller aussi vite que possible.<br /> *Dans l'interface de validation des réglements, rajouter une ligne &quot;supprimer&quot; permettant de supprimer les réglements ne devant pas être validés (fausses saisies donc). Rajouter également une ligne &quot;modifier&quot; permettant de corriger une saisie de réglement.<br /> <br /> <br /> Déjà fait non ? Ou c'est pas complet ? :) --[[User:Zebuline|Zebuline]] 18:27, 3 September 2006 (CEST)<br /> <br /> Point 1 : non, ce n'est pas fait. Lorsqu'on saisi un réglement on va sur une page qui dit : &quot;Transaction enregistrée&quot;. C'est tout.<br /> <br /> Point 2 : Oui, c'est fait. J'efface<br /> <br /> Point 1 : c'est quoi la page de saisie des règlement en question ? --[[User:Zebuline|Zebuline]] 07:53, 4 September 2006 (CEST)</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Discussion:TODO&diff=5452 2006-09-03T16:27:33Z

<p>Zebuline : </p> <hr /> <div>=OF 2.0beta=<br /> *Page de saisie des réglements. Modifier très légèrement la validation de cette page de façon à ce que lorsque un réglement est saisi, on revienne sur cette page (formulaire donc) avec affiché en haut le réglement qui vient juste d'être saisi. Le but est permettre au trésorier ou secrétaire qui saisit les réglements les uns après les autres de pouvoir aller aussi vite que possible.<br /> *Dans l'interface de validation des réglements, rajouter une ligne &quot;supprimer&quot; permettant de supprimer les réglements ne devant pas être validés (fausses saisies donc). Rajouter également une ligne &quot;modifier&quot; permettant de corriger une saisie de réglement.<br /> <br /> <br /> Déjà fait non ? Ou c'est pas complet ? :) --[[User:Zebuline|Zebuline]] 18:27, 3 September 2006 (CEST)</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Discussion:Pricing-management&diff=5369 2006-06-21T15:58:08Z

<p>Zebuline : </p> <hr /> <div>Juste une remarque quant à la seconde solution («donner en vecteur d'entrée la liste des comptes du membre», et «la moulinette effectuera une &quot;identification&quot; de la notion &quot;catégorie de membre&quot; avec &quot;existance de tel compte&quot;») :<br /> <br /> Pour le moment, on n'a que des comptes membres, dans une seule table. Ils se distinguent uniquement par leur intitulé, ou pourquoi pas par leur code comptable. Ce qui ne me semblent pas être des informations suffisantes pour distinguer un compte CE A d'un compte CE B.<br /> <br /> Donc je pencherais plus sur la notion de groupe de membre :)<br /> <br /> Juste une question : tu comptes avoir un système de formule pour calculer le coût d'un vol en fonction du type de vol, de la catégorie du membre, de l'âge du capitaine (oups, commandant de bord :p) ... comme pour le calcul des temps de vols ? :)<br /> <br /> --[[User:Zebuline|Zebuline]] 17:58, 21 June 2006 (CEST)</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Documentation_de_la_solution_web_de_gestion_OpenFlyers_version_2:Community-Portal&diff=4978 2006-04-17T16:13:12Z

<p>Zebuline : </p> <hr /> <div>[[OpenFlyers:About|Présentation d'OF]]<br /> =Communauté OpenFlyers=<br /> == Membres de l'association OpenFlyers ==<br /> [[User:Scroses|Stéphane CROSES (Conseiller)]]<br /> <br /> [[User:Jdepardieu|Jean DE PARDIEU (Président )]]<br /> <br /> [[User:Pgodard|Patrice GODARD (Conseiller)]]<br /> <br /> [[User:KAeL|Mickaël GUERIN (Conseiller)]]<br /> <br /> [[User:Claratte|Christophe LARATTE (Trésorier)]]<br /> <br /> [[User:Zebuline|Lauréline PROVOST (Conseillère)]]<br /> <br /> [[User:Joel|Joël TREMBLET (Secrétaire)]]<br /> <br /> ==Contributeurs==<br /> <br /> [[User:Oracle56|Kamel BELHOUCHET]]<br /> <br /> [[User:Drpiquouze|Denis ROUSSEAUX]]<br /> <br /> [[User:Sadoche|Jacques SAADA]]<br /> <br /> [[User:Hthepaut|Hervé THEPAULT]]<br /> <br /> duplantristan<br /> <br /> redge<br /> <br /> soeren<br /> <br /> == Béta-testeurs ==<br /> alexisdepoux Alexis DEPOUX<br /> <br /> anthony613 LEBAILLY Anthony<br /> <br /> bcaux bernard CAUX<br /> <br /> bossy Jean BOSSY<br /> <br /> chakram Patrick HUBSCHER<br /> <br /> dhorvath<br /> <br /> flyingtotof Christophe MILIAN<br /> <br /> fred Frédéric NAUDIN<br /> <br /> helipat<br /> <br /> manuchao Emmanuel CHAILLOU<br /> <br /> Nicolas Nicolas LE CORRE<br /> <br /> nouzarede nouzarede<br /> <br /> PHKUHN Philippe KUHN<br /> <br /> smaire Soeren MAIRE<br /> <br /> toto69 FLAMAIN</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Formules-de-calcul&diff=4917 2006-04-05T15:31:29Z

<p>Zebuline : /* Différence des heures arrondi à 5 minutes */</p> <hr /> <div>=Introduction=<br /> Pour calculer le temps de vol, chaque club utilise en général une méthode bien à lui.<br /> <br /> Par conséquent comme il nous semble illusoire de proposer toutes les méthodes possibles directement dans OpenFlyers, nous avons préféré mettre en place une zone de saisie libre devant contenir la formule choisie par le club.<br /> <br /> Afin de faciliter la démarche de détermination de formule, nous vous proposons ci-après une liste de formules avec la description de leur comportement attendu.<br /> <br /> Ci vous ne trouvez pas votre bonheur, n'hésitez-pas à rajouter de nouvelles formules ou à utiliser [[Talk:Formula_pool|l'onglet discussion]] de cette page pour demander de l'aide.<br /> =Définitions=<br /> ==variables==<br /> ===%TIME_DEPARTURE===<br /> Heure de début saisie dans le formulaire<br /> ===%TIME_ARRIVAL===<br /> Heure de fin saisie dans le formulaire<br /> ===%COUNTER_DEPARTURE===<br /> Compteur départ saisi dans le formulaire<br /> ===%COUNTER_ARRIVAL===<br /> Compteur arrivé saisi dans le formulaire<br /> ==Fonctions==<br /> ===roundDuration===<br /> roundDuration(X,Y)<br /> Arrondi la valeur X à l'unité Y la plus proche<br /> Exemple :<br /> roundDuration(114,100) donne 100<br /> <br /> roundDuration(114,10) donne 110<br /> <br /> '''Attention :''' Les valeurs de temps de vols sont en &quot;[[time unit|sexacentimal]]&quot;.<br /> 1 minute = 10 sexacentièmes<br /> 5 minutes = 50 sexacentièmes<br /> <br /> 1 centième de minute = 6 sexacentièmes<br /> 10 centième de minute (=1 dixième de minute) = 60 sexacentièmes<br /> <br /> Exemples :<br /> pour arrondir à 5 minutes : roundDuration(X,50)<br /> <br /> pour arrondir à 10 centièmes : roundDUration(X,60)<br /> <br /> ===max===<br /> max(X,Y)<br /> donne le max entre X et Y<br /> =Formules=<br /> ==Différence des heures==<br /> %TIME_ARRIVAL - %TIME_DEPARTURE<br /> ==Différence des compteurs==<br /> %COUNTER_ARRIVAL - %COUNTER_DEPARTURE<br /> ==Différence des heures arrondie à 5 minutes==<br /> roundDuration(%TIME_ARRIVAL - %TIME_DEPARTURE, 50)<br /> <br /> ==Différence des compteurs plus 5 minutes ==<br /> %COUNTER_ARRIVAL - %COUNTER_DEPARTURE + 50<br /> ==Différence des compteurs arrondie à 10 centièmes==<br /> roundDuration(%COUNTER_ARRIVAL - %COUNTER_DEPARTURE, 60)<br /> <br /> ==Le plus grand entre la différence des heures et la différence des compteurs==<br /> max(%TIME_ARRIVAL - %TIME_DEPARTURE, %COUNTER_ARRIVAL - %COUNTER_DEPARTURE)<br /> ==Le plus grand entre la différence des heures et la différence des compteurs arrondie à 5 minutes==<br /> max(%TIME_ARRIVAL - %TIME_DEPARTURE,roundDuration(%COUNTER_ARRIVAL - %COUNTER_DEPARTURE, 50))<br /> Une petite explication, car là ça devient un peu compliqué. Cette formule calcule :<br /> *la différence des compteurs et l'arrondi à 5 minutes<br /> *la valeur du temps de vol saisi par le pilote<br /> Puis elle prend le plus grand des deux</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Formules-de-calcul&diff=4916 2006-04-05T15:31:20Z

<p>Zebuline : /* Différence des compteurs arrondi à 10 centièmes */</p> <hr /> <div>=Introduction=<br /> Pour calculer le temps de vol, chaque club utilise en général une méthode bien à lui.<br /> <br /> Par conséquent comme il nous semble illusoire de proposer toutes les méthodes possibles directement dans OpenFlyers, nous avons préféré mettre en place une zone de saisie libre devant contenir la formule choisie par le club.<br /> <br /> Afin de faciliter la démarche de détermination de formule, nous vous proposons ci-après une liste de formules avec la description de leur comportement attendu.<br /> <br /> Ci vous ne trouvez pas votre bonheur, n'hésitez-pas à rajouter de nouvelles formules ou à utiliser [[Talk:Formula_pool|l'onglet discussion]] de cette page pour demander de l'aide.<br /> =Définitions=<br /> ==variables==<br /> ===%TIME_DEPARTURE===<br /> Heure de début saisie dans le formulaire<br /> ===%TIME_ARRIVAL===<br /> Heure de fin saisie dans le formulaire<br /> ===%COUNTER_DEPARTURE===<br /> Compteur départ saisi dans le formulaire<br /> ===%COUNTER_ARRIVAL===<br /> Compteur arrivé saisi dans le formulaire<br /> ==Fonctions==<br /> ===roundDuration===<br /> roundDuration(X,Y)<br /> Arrondi la valeur X à l'unité Y la plus proche<br /> Exemple :<br /> roundDuration(114,100) donne 100<br /> <br /> roundDuration(114,10) donne 110<br /> <br /> '''Attention :''' Les valeurs de temps de vols sont en &quot;[[time unit|sexacentimal]]&quot;.<br /> 1 minute = 10 sexacentièmes<br /> 5 minutes = 50 sexacentièmes<br /> <br /> 1 centième de minute = 6 sexacentièmes<br /> 10 centième de minute (=1 dixième de minute) = 60 sexacentièmes<br /> <br /> Exemples :<br /> pour arrondir à 5 minutes : roundDuration(X,50)<br /> <br /> pour arrondir à 10 centièmes : roundDUration(X,60)<br /> <br /> ===max===<br /> max(X,Y)<br /> donne le max entre X et Y<br /> =Formules=<br /> ==Différence des heures==<br /> %TIME_ARRIVAL - %TIME_DEPARTURE<br /> ==Différence des compteurs==<br /> %COUNTER_ARRIVAL - %COUNTER_DEPARTURE<br /> ==Différence des heures arrondi à 5 minutes==<br /> roundDuration(%TIME_ARRIVAL - %TIME_DEPARTURE, 50)<br /> ==Différence des compteurs plus 5 minutes ==<br /> %COUNTER_ARRIVAL - %COUNTER_DEPARTURE + 50<br /> ==Différence des compteurs arrondie à 10 centièmes==<br /> roundDuration(%COUNTER_ARRIVAL - %COUNTER_DEPARTURE, 60)<br /> <br /> ==Le plus grand entre la différence des heures et la différence des compteurs==<br /> max(%TIME_ARRIVAL - %TIME_DEPARTURE, %COUNTER_ARRIVAL - %COUNTER_DEPARTURE)<br /> ==Le plus grand entre la différence des heures et la différence des compteurs arrondie à 5 minutes==<br /> max(%TIME_ARRIVAL - %TIME_DEPARTURE,roundDuration(%COUNTER_ARRIVAL - %COUNTER_DEPARTURE, 50))<br /> Une petite explication, car là ça devient un peu compliqué. Cette formule calcule :<br /> *la différence des compteurs et l'arrondi à 5 minutes<br /> *la valeur du temps de vol saisi par le pilote<br /> Puis elle prend le plus grand des deux</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Discussion:Main-Page&diff=4915 2006-04-05T14:50:26Z

<p>Zebuline : </p> <hr /> <div>''Cette page de discussion peut être l'équivalent du &quot;bar du coin&quot; où on parle des choses en général.''<br /> <br /> ==Multilinguisme &amp; xml/xsl==<br /> Plusieurs possibilités s'offrent à nous sur la façon de &quot;moderniser&quot; l'implémentation existante dans la version 1.2 d'OF du multilinguisme.<br /> <br /> ===But===<br /> Actuellement le multilinguisme est géré par des fichiers langues sur le modèle :<br /> $lang['ITEM'] = 'traduction dans une langue';<br /> <br /> Cette méthode a plusieurs inconvénients :<br /> *elle ne permet pas de voir si un item a une traduction dans une langue ou non (il faut ouvrir le fichier de la langue concernée et rechercher l'item). Cela rend les mises à jour très lourdes.<br /> *cela ne permet pas de trouver les &quot;items morts&quot;, c'est à dire les items qui devraient être supprimés.<br /> *au fil du temps, les fichiers s'étoffent et il n'y a pas de hiérarchisation de l'information. Le parcours en devient difficile.<br /> Pour résumer ces points :<br /> la méthode actuelle empêche la création d'une interface de gestion facilitant la vie des traducteurs.<br /> Un dernier inconvénient :<br /> *il n'y a pas possibilité d'avoir dynamiquement la traduction d'un item dans plusieurs langues. Une fois qu'un fichier langue est ouvert on n'utilise que celui-là.<br /> ===Tout d'abord, il y a deux méthodes de stockage des traductions :===<br /> *par base de données (dans ce cas on se tournerait vers la classe Translation2)<br /> *en mettant les textes dans du xml. Mais on perd en facilité de maintenance, ou alors on crée (ou on trouve) une classe qui gère ça.<br /> <br /> Mon avis : <br /> la base de donnée n'est pas adaptée : les données sont statiques, et la base de données c'est trop lent (on ne va pas faire 40 requêtes par page).<br /> xml : soit on parse à chaque fois le fichier pour trouver la traduction (trop lent), soit on le parse une fois et on le met en mémoire (et donc, autant utiliser un fichier type .ini avec identifiant=valeur, c'est plus léger)<br /> --[[Utilisateur:KAeL|KAeL]] 3 Nov 2005 à 14:29 (CET)<br /> <br /> le fichier .ini c'est ce qu'on fait aujourd'hui. J'en présente les inconvénients dans les buts recherchés ci-dessus. (mais peut-être que je n'ai pas tout compris sur ce qu'on pouvait faire avec les fichiers .ini--[[Utilisateur:Claratte|Christophe]] 3 Nov 2005 à 23:40 (CET)<br /> <br /> ===Ensuite, vient la méthode de conversion de la feuille xsl :===<br /> Dans les deux cas, on part d'une feuille xsl qui va contenir des balises &lt;text&gt; définissant le texte à remplacer dans la bonne langue par exemple :<br /> <br /> &lt;nowiki&gt;&lt;b&gt;&lt;center&gt;<br /> &lt;text&gt;aircraft list&lt;/text&gt;<br /> &lt;xsl:value-of select=&quot;registration&quot;/&gt;<br /> &lt;/center&gt;&lt;/b&gt;&lt;/nowiki&gt;<br /> <br /> On a donc deux choix :<br /> <br /> *soit on effectue la transformation du &lt;text&gt;aircraft list&lt;/text&gt; en premier puis on obtient une deuxième feuille XSL (en fait la même que celle de Joël)<br /> *soit on effectue la transformation du xml via la feuille de style &quot;générique&quot;, on obtient alors une sortie presque-html avec les &lt;text&gt; puis on les remplace par la langue finale.<br /> <br /> Intérêt de la première méthode : on peut mettre en cache nos feuilles de styles adaptées à chaque langue, sachant que les modifications sur les langues ne doivent pas apparaître dans une version stable d'OF.<br /> <br /> Intérêt de la seconde méthode : elle me paraît plus simple...<br /> <br /> Ça me paraît assez lourd comme approche --[[Utilisateur:KAeL|KAeL]] 3 Nov 2005 à 14:30 (CET)<br /> <br /> ===Dernier point : mappage xml/base de données===<br /> Dans translation2, les textes sont référencés selon 2 éléments (cf. [[Translation_Table]]) : un id qui &quot;nomme&quot; le texte et un page_id. Ainsi on peut avoir deux ids identiques mais sur des pages différentes. D'où ma question : comment en verriez-vous l'utilisation concrète ? (quelles règles on se fixe ?)<br /> <br /> Je vous propose la suivante, on fait un &quot;mappage&quot; base de données/xml ainsi :<br /> <br /> &lt;text page=&quot;admin&quot;&gt;aircraft list&lt;/text&gt;<br /> <br /> avec le contenu élément de text qui correspond à l'id de la base de données et l'attribut page qui correspond au page_id.<br /> <br /> Avantage : on peut définir une page générique (champ page_id vide dans la base et sans attribut page sur le xml) qui contient les intitulés qui reviennent le plus souvent (comme &quot;valider&quot;, &quot;annuler&quot;, etc.)<br /> <br /> Inconvénient : la présence très fréquente de l'attribut page qui n'apporte pas grand chose.<br /> <br /> Une autre méthode : on ne met pas d'attribut page, et pour faire la relation on utilise le nom de la feuille xsl comme page_id.<br /> <br /> Avantage : c'est plus léger pour la page xsl<br /> <br /> Inconvénient : faut ré-écrire pour chaque page des mots identiques<br /> <br /> J'attends vos avis ;-)<br /> --[[Utilisateur:Claratte|Christophe]] 30 Sep 2005 à 01:47 (CEST)<br /> <br /> pareil qu'avant, je ne pense pas que ni xml ni une base de données ne soient les plus adaptés à la situation --[[Utilisateur:KAeL|KAeL]] 3 Nov 2005 à 14:32 (CET)<br /> <br /> == Dans tous les cas ==<br /> <br /> Je pense que dans tous les cas, on devrait commencer par se faire une classe OfTranslator avec qq méthodes génériques :<br /> setLang('fr')<br /> getLang() -&gt; renvoie 'fr'<br /> getAvailableLangs() -&gt; renvoie array('fr', 'en', ...)<br /> tr('hi') -&gt; salut (tr comme translate)<br /> <br /> Après derrière, on peut coder nos fonctions à nous ou utiliser une classe PEAR comme Translation2.<br /> <br /> La question est : comment on stocke les données ?<br /> * en xml (quand on choisit la langue, on stocke les traductions en mémoire)<br /> * ds un fichier .ini (même remarque)<br /> * en base de données (lent, pas adapté)<br /> * en utilisant gettext (des infos ici : [http://www.gnu.org/software/gettext/manual/html_mono/gettext.html#SEC1 GNU gettext]) (supporté par Translation2)<br /> <br /> --[[Utilisateur:KAeL|KAeL]] 3 Nov 2005 à 14:40 (CET)<br /> <br /> Pour le stockage des données de traductions, il y a sqlite, c'est la bdd intégrée à php5, pour les perf je vous renvoie sur leur site [http://www.sqlite.org/speed.html perf]<br /> <br /> Concernant gettext, je trouve ça par mal comme solution, c'est pas apache/php qui travaille, c'est gettext qui redirige vers la bonnes traduction, et vu qu'il est fait pour, il est sûrement plus optimisé que d'envoyer php à la recherche de traduc dans une bdd.<br /> <br /> De plus il existe des logiciels pour éditer les fichiers de langues, c'est plus digeste que d'éditer les fichiers textes à la main.<br /> <br /> <br /> Une explication de l'utilisation de gettext sur le [http://developpeur.journaldunet.com/tutoriel/php/030120php_localisation1b.shtml journal du net]<br /> <br /> Je vote pour gettext !!<br /> --[[Utilisateur:Scroses|Scroses]] 3 Nov 2005 à 20:05 (CET)<br /> <br /> (Pense à rajouter ta signature (avant dernière icône dans le formulaire d'édition), sinon on a du mal à suivre qui dit quoi)<br /> <br /> Merci pour le lien sur le journal du net, parce que l'introduction de gettext m'a laissé perplexe...<br /> <br /> Concernant sqlite, y'a pas plus de raison de l'utiliser comme base de données pour les traductions que pour le reste...<br /> <br /> Sinon pour gettext, je ne suis pas contre a priori mais je lui vois trois inconvénients :<br /> *il faut qu'il soit present sur le serveur.<br /> *les outils sont plutôt pour le monde linux alors que le but est de faire une interface de gestion accessible pour le commun des mortels.<br /> *je n'ai pas bien compris si les outils devaient être sur le serveur ou si on pouvait éditer les fichiers n'importe où... (et j'ai cru comprendre qu'il fallait compiler les fichiers langues, ce qui est plutôt lourd)<br /> --[[Utilisateur:Claratte|Christophe]] 3 Nov 2005 à 23:53 (CET)<br /> <br /> <br /> Les outils doivent être sur le serveur, gettext fait partie des outils installés par défaut sur les distribs linux, après il faut savoir si les hébergeurs ont désactivé l'option lors de l'installation, pour le savoir, il faut relire le phpinfo() du serveur.<br /> Pour les serveurs wamp ou easyphp, il faut aller décommenter php_gettext.dll dans php.ini.<br /> <br /> Même si les outils sont issus du monde linux (comme apache par ex :-) ça ne concerne que le serveur et pas les utilisateurs finaux devant leur pc.<br /> <br /> pour l'histoire de la compilation des fichiers de langue, pour moi non plus ce n'est pas très clair...Je creuse la question.<br /> <br /> ps j'ai quelques pour signer...<br /> <br /> --[[Utilisateur:Scroses|Scroses]]<br /> <br /> Bon j'ai fait quelques recherches, en fait quand ils parlent de compilation, c'est en fait la fabrication à partir du fichier de traduction *.po du fichier catalogue *.mo. Des scripts php peuvent faire ça, mais des logiciels de traduction comme [http://www.poedit.org/index.php poedit] les génèrent automatiquement.<br /> <br /> J'ai même vu des application php de traduction.<br /> <br /> --Utopie 4 Nov 2005 à 10:07 (CET)</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Discussion:Training-courses&diff=4797 2006-03-01T20:57:04Z

<p>Zebuline : </p> <hr /> <div>=Sujets de stage=<br /> ==Mise en miroir des serveurs et en temps réel==<br /> Pour ca je pense avoir trouvé la solution, mais de la la mettre en oeuvre..., c'est la mise en place d'un cluster de serveur mysql !!!. Je pense que c'est aussi un excellent sujet de stage.<br /> <br /> *[http://www.nexen.net/news/gen.php/2005/12/20/4877,0,0,0,0.php cluster how to]<br /> *[http://dev.mysql.com/doc/refman/5.0/fr/ndbcluster.html doc de mysql.com]<br /> =Liste d'écoles=<br /> {| {{prettytable}}<br /> !Lien!!Localisation!!Contact!!Commentaires<br /> |-<br /> |[http://www.epita.fr/ http://www.epita.fr/]||Kremlin-Bicêtre (Région parisienne)||||pub sur SVM<br /> |-<br /> |[http://www.enseeiht.fr/ http://www.enseeiht.fr/]||Toulouse||cf. courrier||école de Mickaël et Lauréline<br /> |-<br /> |[http://www.info.iut.u-bordeaux1.fr/site-departement/accueil.html http://www.info.iut.u-bordeaux1.fr/site-departement/accueil.html]||Bordeaux||||<br /> |}</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Discussion:Account-Reporting&diff=4597 2006-01-04T21:30:11Z

<p>Zebuline : </p> <hr /> <div>J'ai juste un (ou plus) problème métaphysique :<br /> * Si le pilote n'a pas le droit de saisir ses règlement, il a néanmoins la possibilité de saisir le montant à se faire rembourser pour un avitaillement lors de la fermeture de son vol. Si on ne lui permet pas la saisie du montant, tel que c'est fait ça pose une erreur : le pilote a dit qu'il avait mis de l'essence/de l'huile, avant/après le vol, qu'il avait payé de sa poche (compte pilote dans la combo, intitulé à changer d'ailleurs, mais nos traducteurs trouveront mieux :) ), mais le montant est nul. On peut toujours récupérer l'exception jetée pas le script php et enregistrer une ligne (deux pour la double écriture) dans account_entry avec un montant nul pour signifier le remboursement, dont le trésorier va ensuite modifier le montant, mais ça me gêne :p<br /> * Si le trésorier constate une anomalie dans un approvisionnement, il a la possibilité de le modifier. D'accord. Mais si il remarque une anomalie dans un remboursement avitaillement, pour le modifier il faut soit le faire resaisir par le pilote, ce qui implique qu'il a le droit checkflight ou que l'avion n'a pas redécollé, ou bien le trésorier doit modifier le vol lui-même : il lui faut donc le droit checkflight, ou déléguer au gen qui va bien.<br /> <br /> Ce dernier point va vous embêter, vous aller dire que le trésorier doit avoir à sa disposition une interface pour modifier les remboursements avitaillement. Je veux bien, mais il ne pourra que modifier le montant, et pas supprimer le remboursement : ça demande beacoup de vérification de cas, et de modifier la ligne qui va bien dans la table fuelling ou lubricant (car soit il n'y a pas eu avitaillement du tout, dans ce cas il faut carrément supprimer la ligne, soit le pilote n'a pas payé de sa poche, et dans ce cas il faut modifier le champ fuel/lubricant_pay_type). Or le trésorier peut ne pas avoir tous les éléments en main, et décider que non il n'y a pas eu avitaillement, alors que si.<br /> <br /> Enfin, si j'envisage très bien la possibilité de modifier le montant d'un avitaillement, je n'envisage pas du tout la possibilité de le supprimer. Si la suppression est vraiment nécessaire, il faut qu'un utilisateur ayant le droit checkflight modifie le vol en conséquence.<br /> <br /> --[[User:Zebuline|Zebuline]] 23:55, 19 December 2005 (CET)<br /> <br /> Mes avis :<br /> *Il ne faut pas saisir des choses fausses (donc pas de ligne contenant 0 €)<br /> *Le droit de saisir une quantité d'essence n'est pas lié au droit de saisir le montant à se faire rembourser :<br /> **Un pilote (en fait quelqu'un qui a le droit &quot;saisir un vol&quot;) doit pouvoir saisir une quantité d'essence ajoutée à l'avion. Il s'agit d'une écriture sur le même papier que pour les heures de vols : le carnet de route.<br /> **Saisir un remboursement est lié à un autre papier : la compta.<br /> Donc :<br /> *Il faut dissocier la possibilité de saisir un vol de la possibilité de saisir un remboursement. Ou plutot, on peut avoir le droit de saisir un vol sans pour autant avoir le droit de saisir un remboursement pour soi.<br /> *Il faut créer un droit permettant de gérer les remboursements (et donc donnant le droit d'en ajouter et d'en supprimer). Il seront par la suite validés par le trésorier comme pour les paiements.<br /> *Il faut donc une interface spécifique à la gestion des remboursements.<br /> *Ces derniers doivent apparaitre en italique ou autre comme pour les paiements non validés (et jusqu'à temps de la validation).<br /> <br /> Ainsi voici la gestion de différents scénarii :<br /> *Si le pilote n'a pas le droit de saisir ses remboursements :<br /> **il saisit son vol et la quantité d'essence ajoutée.<br /> **il dépose dans la boite aux lettres prévue à cet effet la facture d'essence<br /> **le secrétaire disposant du droit permettant de gérer les remboursements saisie la facture d'essence en remboursement<br /> **le tresorier valide la saisie<br /> *Si le pilote a le droit de saisir ses remboursements :<br /> **il saisit son vol et la quantité d'essence ajoutée.<br /> **OF lui propose d'où vient l'essence (il dit que sa vient de l'extérieur et que c'est à rembourser sur son compte)<br /> **il saisit le montant de la facture d'essence<br /> **le trésorier valide le montant<br /> <br /> J'ai beau chercher mais je ne vois pas où on est obligé de coller une écriture en double avec un montant nul.<br /> <br /> Si j'ai bien compris, ce qui te gène c'est que si le trésorier annule un remboursement il faudrait que t'ailles chercher la quantité d'essence ajoutée dans l'avion et que tu la supprimes. Alors là, je t'arrête tout de suite : on s'en fout ! Ce n'est pas lié. L'écriture sur le carnet de route, n'a rien à voir avec l'écriture sur la compta ;-) Ce que je viens de dire, c'est la réalité du moment. Mais nous, on est plus malin ;-)<br /> <br /> Donc on va rajouter un petit 0 dans les possibilités du champ FUEL_PAY_TYPE dans la table fuelling qui vaudra &quot;Inconnu&quot; et qui ne sera pas proposable dans les combos. Il sera utilisé pour justement &quot;supprimer&quot; les paiements de type 3 (Pilot) refusés par le trésorier.<br /> <br /> Après bien sûr, on fera un système qui affichera les &quot;Unknown&quot; pour les gérer et puis aussi des alertes par mails pour les pilotes qui se sont vus refusés leur remboursement.<br /> <br /> --[[User:Claratte|Christophe]] 23:41, 26 December 2005 (CET)<br /> <br /> <br /> Ce qui me dérangeait, c'est le fait d'avoir des écritures dans account_entry en rapport avec un remboursement essence/huile, mais qui n'ait pas de lien avec un approvisionnement dans la table fuelling ou lubricant. Mais apparemment c'est pas grave :)<br /> <br /> Si j'ai bien compris, ce dont je doute, ça doit se passer comme ceci :<br /> * le pilote a le droit de saisir un remboursement. Le comptable, qui valide les remboursements, en trouve un dans les remboursements en attente de validation dont la somme ne correspond pas. En admettant qu'il ne se trompe pas, que ce qu'il croit ne pas correspondre est en effet une erreur de saisie de la part du pilote, et pas un autre approvisionnement à rembourser dont il n'a pas encore la facture, il peut modifier le montant de cet approvisionnement. Sont alors modifiés les champs credit et debit de la ligne account_entry correspondante. On a toujours la double_entry dans lubricant ou fuelling.<br /> * le pilote n'a pas le droit de saisir un remboursement. Il va renseigner les champs qui sont à sa portée dans le formulaire de fermeture de vol. Que doit-il renseigner comme moyen de paiement ? (je suis dans le cas ou il veut un remboursement) compte pilote (numéro 3), sans écriture dans account_entry ? ou bien unknown (numéro 0), et on lui grise la possibilité 3 ?<br /> * le comptable trouve une facture dans son tas de factures à rembourser, et ne voit pas de remboursement correspondant dans la liste des remboursements à valider (on est dans le cas où le pilote a oublié de saisir son approvisionnement, ou bien n'a pas le droit de saisir de remboursement). Il en saisit un nouveau. Ce remboursement (deux lignes dans account_entry), n'aura pas de lien avec la table fuelling ou lubricant.<br /> * problème : le comptable est allé trop vite, il a ajouté un remboursement à la main en recopiant une facture, et le pilote se rappelle qu'il a approvisionné l'avion en essence ou en huile, modifie son vol et ajoute l'approvisionnement et le remboursement. Le comptable se retrouve avec 2 remboursements pour le même approvisionnement. Peut-il en supprimer un ? (je crois qu'on a dit qu'on ne supprimait rien, pour éviter des abus de pouvoirs et des trucs qui disparaissent comme par magie) Ou faut-il que le pilote, s'il en a le droit, ou un utilisateur avec le droit checkFlight modifie le vol et change le moyen de paiment en unknown ? (ça me plait la dernière solution)<br /> <br /> --[[User:Zebuline|Zebuline]] 20:06, 29 December 2005 (CET)<br /> <br /> *Je ne comprend pas &quot;''On a toujours la double_entry dans lubricant ou fuelling.''&quot;. Y'a qu'une ligne dans lubricant ou fuelling ? || On a un champ dans la table fuelling et la table lubricant, qui pointe sur une éventuelle double entrée dans la table acount_entry.--[[User:Zebuline|Zebuline]] 14:19, 30 December 2005 (CET)<br /> *Si le pilote n'a pas le droit de saisir un remboursement, alors il n'a comme moyen de paiement que la cuve du club ou unknown (qu'on appelera plutot &quot;autre&quot;).<br /> *&quot;''le comptable trouve une facture''&quot; : on a le choix. Soit on fait comme tu dis, soit on crée également une entrée dans fuelling ou lubricant. Je préfèrerais créer une entrée...<br /> *&quot;''problème''&quot; : d'où l'intérêt de ma préférence pour le point précédent : si le comptable saisie le remboursement, alors le pilote verra que l'essence a été rajouté quand il voudra effectuer lui-même la correction de son erreur.<br /> <br /> Sinon pour la partie &quot;compta&quot;, y'a deux choses : soit l'écriture de remboursement est en italique dans les comptes (=non validée) et dans ce cas elle peut être supprimée, soit elle a été validée par le comptable et elle ne peut plus être supprimée et doit faire l'objet d'une écriture de correction.<br /> <br /> Ce qu'il faut bien voir c'est que la secrétaire peut très bien avoir le droit de saisir les remboursements (et pas les pilotes) mais que la validation se fasse par le trésorier.<br /> <br /> Donc :<br /> *tout pendant qu'on est en italique, on peut ajouter/modifier/supprimer les remboursements et faire la modif correspondante sur la table lubricant/fuel.<br /> *dès que l'écriture de remboursement est validée, on ne peut plus la supprimer et dans ce cas seule une écriture comptable de correction peut être faite. Dans ce cas, il n'y a plus de lien avec la table lubricant/fuel. On est en pure compta.<br /> <br /> Si on veut néanmoins pouvoir modifier les tables lubricant/fuel, faudrait donner la possibilité de modifier ces éléments là pour n'importe quel vol et à tout moment. Ce n'est pas très sain. Mais je ne l'exclue pas. Faudra y refléchir plus tard.<br /> <br /> Exemples d'oublis :<br /> *le pilote saisi son vol, oublie l'essence.<br /> **Si l'avion a revolé, il ne peut plus modifier son vol, donc il ne peut plus saisir l'essence. (si je me trompe tu me corriges)<br /> **Si l'avion n'a pas revolé, il peut modifier son vol et saisir l'essence (avec ou sans le remboursement suivant ses droits).<br /> *Le pilote saisi son vol, oublie l'essence, la secrétaire voit son remboursement le saisit et attribue l'essence sur le vol du pilote.<br /> **L'avion n'a toujours pas volé, et le pilote repense à son essence : il va pour modifier son vol, et là, voit que l'essence a été rajoutée. Il ne corrige donc pas.<br /> *Le pilote saisi son vol, oublie l'essence, la secrétaire voit son remboursement le saisit et attribue l'essence sur un autre vol que celui du pilote concerné.<br /> **L'avion n'a toujours pas volé, et le pilote repense à son essence : il va pour modifier son vol, et là, comme il ne voit rien, il saisit l'essence pour son vol.<br /> **Option A: Lors de la validation le trésorier pointe les remboursements et voit apparaitre deux fois le même montant saisi alors qu'il n'a qu'une facture. Il en supprime une. L'honneur est sauf.<br /> **Option B: Lors de la validation le trésorier pointe les remboursements et voit apparaitre deux fois le même montant, il est distrait et valide deux fois. L'honneur n'est pas sauf. L'erreur ne pourra alors être détectée qu'au moment du calcul du compte de résultat en fin d'année. Il y aura un écart entre :<br /> ***d'une part, le solde total des pilotes<br /> ***d'autre part, la différence des paiements des pilotes et des factures remboursées aux pilotes<br /> Pour isoler l'erreur faudra pointer !<br /> <br /> Mais je te rassure pour isoler l'erreur faut déjà faire le total des factures essences, au vu des factures. Ce type de travail, seul les assesseurs peuvent se le permettre. En général, ils ne vont pas jusque là. Donc l'erreur ne sera pas détectée et un pilote aura profité d'un remboursement indue.<br /> <br /> &lt;nowiki&gt;:D&lt;/nowiki&gt; --[[User:Claratte|Christophe]] 01:40, 30 December 2005 (CET)<br /> <br /> Bon alors :)<br /> * Si le comptable trouve une facture et ne voit pas de remboursement correspondant dans la liste des remboursements à valider, deux possibilités :<br /> ** la première : il faut modifier le vol pour ajouter directement l'approvisionnement, comme ça tous les liens sont créés : dans la table fueliing si c'est un approvisionnement essence, ou dans la table lubricant si c'est un approvisionnement huile, l'id du vol correspondant à cet approvisionnement; dans le champ qui va bien on renseigne la double entrée vers account_entry.<br /> ** la seconde, que je préfère : un formulaire de saisie des approvisionnements côté admin : on peut avoir une liste des vols les plus récents par avion (ou du moins les 30 derniers, ça devrait suffire, avec la possibilité d'afficher les 30 suivants, si le pilote a donné la facture 6 mois après, etc.), on clique sur le vol correspondant, et on saisit un approvisionnement. Comme ça on crée tous les liens qui vont bien, et le pilote, si d'un coup il se rappelle qu'il a oublié de saisir son approvisionnement et veut le faire, voit qu'il a déjà été rajouté par le secrétaire.<br /> <br /> Il faut bien comprendre que le point qui me dérnage le plus, c'est l'édition des liens entre les tables. Ca me dérange d'écrire des trucs dans account_entry en rapport avec un remboursement, et ne pas trouver l'approvisionnement correspondant. Pareil, saisir un approvisionnement sans trouver le vol.<br /> <br /> Sinon j'ai un autre problème : Tu as dit que quand le comptable a validé un approvisionnement, alors on ne peut plus y toucher. Je suis d'accord. (si on doit quand même rectifer qqch, le comptable fera un virement pour rétablir les choses, avec un commentaires explicatif, mais on ne touche plus à la ligne remboursement validée). Ce qui me dérange, c'est que tant que l'avion n'a pas volé, le pilote peut modifier son vol. Il faut, si la gestion des comptes est activée et qu'on trouve au moins un remoubrsement validé, lui masquer les sous-formulaires d'approvisionnement. L'ajout d'approvisionnements oubliés se fera côté admin (si on adopte ma seconde solution). Sinon, quand une personne ayant le droit checkFlight, de la même façon, si on trouve au moins un remboursement validé, il faut masquer les sous-formulaires. C'est la condition pour garantir l'intégrité des données comptables !<br /> <br /> --[[User:Zebuline|Zebuline]] 14:19, 30 December 2005 (CET)<br /> <br /> Si personne ne contredit je fais comme j'ai dit :p<br /> <br /> --[[User:Zebuline|Zebuline]] 22:30, 4 January 2006 (CET)</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Discussion:Coding-rules&diff=4539 2006-01-03T22:56:35Z

<p>Zebuline : /* Votes */</p> <hr /> <div>=Format des variables=<br /> Je suis pour le respect du format suivant concernant les variables :<br /> $thisIsAnExample<br /> <br /> J'ai pas trouvé de telle obligation dans PEAR alors que je pensais que c'était le cas... En fait c'est restreint aux fonctions. De même je pensais que c'était clairement décrit dans notre propres règles et il n'en n'est rien.<br /> <br /> Donc le sujet est ouvert...<br /> <br /> --[[User:Claratte|Christophe]] 15:53, 30 December 2005 (CET)<br /> <br /> Je suis d'accord, j'aime aussi ce format, mais uniquement pour les variables php.<br /> <br /> Par contre, pour les variables html (ce qui passe en POST ou en GET), je préfère les underscore, tout simplement parce que je n'aime pas voir des majuscules dans la barre d'adresse :)<br /> <br /> En gros, j'aime assez le format suivant :<br /> Variables php : <br /> $thisIsAnExemple<br /> &quot;Variables&quot; html : <br /> this_is_an_exemple<br /> Functions php : <br /> thisIsAnExemple()<br /> Et les noms de classes avec une majuscule<br /> <br /> --[[User:Zebuline|Zebuline]] 15:59, 30 December 2005 (CET)<br /> <br /> Dans ce cas pourquoi ne pas re-formater lors de &quot;l'import&quot; :<br /> $thisIsAnExample = getPost('this_is_an_example')<br /> <br /> Néanmoins, je préfère même pour html utiliser la règle générale. Je ne vois pas où est le problème (avec html).<br /> <br /> Y'a un truc aussi : normalement dans la barre d'adresse doit y avoir que l'adresse, pas de variable. Ces dernières doivent être passées par POST.<br /> <br /> --[[User:Claratte|Christophe]] 16:06, 30 December 2005 (CET)<br /> <br /> Heu, le reformattage, je le fais déjà ? Où est le pb ? --[[User:Zebuline|Zebuline]] 16:13, 30 December 2005 (CET)<br /> <br /> Je voyais tellement de fois aircraft_id dans ton fichier open_flight que je pensais qu'il s'agissait de la variable php...<br /> <br /> Sinon, voici un lien concernant les [http://www.port80software.com/support/articles/nextgenerationurls urls propres]<br /> <br /> --[[User:Claratte|Christophe]] 16:17, 30 December 2005 (CET)<br /> <br /> Je n'ai aps donné mon avis pour le format javascript ...<br /> <br /> D'ailleurs, qu'appelles-tu variable javascript ? Les trucs avec un var devant ? Si oui, je suis favorable au format thisIsAnExample. Sinon, si tu appelles des variables javascript ce qu'on récupère sur un formulaire, comme c'est du html, je suis pour le format this_is_an_example.<br /> <br /> --[[User:Zebuline|Zebuline]] 23:38, 3 January 2006 (CET)<br /> <br /> Je parlais des deux à la fois. Mais on peut encore plus dissocier. Je rectifie donc la présentation du vote.<br /> <br /> --[[User:Claratte|Christophe]] 23:52, 3 January 2006 (CET)<br /> ==Votes==<br /> Concensus pour utiliser le format thisIsAnExample dans les variables PHP et JavaScript.<br /> <br /> Vote sur le format des variables transmises dans les formulaires HTML :<br /> {| {{prettytable}}<br /> !Proposition!!Votant pour<br /> |-<br /> |utiliser le format thisIsAnExample||--[[User:Claratte|Christophe]] 15:58, 30 December 2005 (CET)<br /> |-<br /> |format this_is_an_example, par analogie avec les varaibles qui passent en GET : pour ne pas avoir de majuscules dans l'url ||--[[User:Zebuline|Zebuline]] 23:56, 3 January 2006 (CET)<br /> |}</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Discussion:Coding-rules&diff=4534 2006-01-03T22:40:58Z

<p>Zebuline : /* Format des variables */</p> <hr /> <div>=Format des variables=<br /> Je suis pour le respect du format suivant concernant les variables :<br /> $thisIsAnExample<br /> <br /> J'ai pas trouvé de telle obligation dans PEAR alors que je pensais que c'était le cas... En fait c'est restreint aux fonctions. De même je pensais que c'était clairement décrit dans notre propres règles et il n'en n'est rien.<br /> <br /> Donc le sujet est ouvert...<br /> <br /> --[[User:Claratte|Christophe]] 15:53, 30 December 2005 (CET)<br /> <br /> Je suis d'accord, j'aime aussi ce format, mais uniquement pour les variables php.<br /> <br /> Par contre, pour les variables html (ce qui passe en POST ou en GET), je préfère les underscore, tout simplement parce que je n'aime pas voir des majuscules dans la barre d'adresse :)<br /> <br /> En gros, j'aime assez le format suivant :<br /> Variables php : <br /> $thisIsAnExemple<br /> &quot;Variables&quot; html : <br /> this_is_an_exemple<br /> Functions php : <br /> thisIsAnExemple()<br /> Et les noms de classes avec une majuscule<br /> <br /> --[[User:Zebuline|Zebuline]] 15:59, 30 December 2005 (CET)<br /> <br /> Dans ce cas pourquoi ne pas re-formater lors de &quot;l'import&quot; :<br /> $thisIsAnExample = getPost('this_is_an_example')<br /> <br /> Néanmoins, je préfère même pour html utiliser la règle générale. Je ne vois pas où est le problème (avec html).<br /> <br /> Y'a un truc aussi : normalement dans la barre d'adresse doit y avoir que l'adresse, pas de variable. Ces dernières doivent être passées par POST.<br /> <br /> --[[User:Claratte|Christophe]] 16:06, 30 December 2005 (CET)<br /> <br /> Heu, le reformattage, je le fais déjà ? Où est le pb ? --[[User:Zebuline|Zebuline]] 16:13, 30 December 2005 (CET)<br /> <br /> Je voyais tellement de fois aircraft_id dans ton fichier open_flight que je pensais qu'il s'agissait de la variable php...<br /> <br /> Sinon, voici un lien concernant les [http://www.port80software.com/support/articles/nextgenerationurls urls propres]<br /> <br /> --[[User:Claratte|Christophe]] 16:17, 30 December 2005 (CET)<br /> <br /> Je n'ai aps donné mon avis pour le format javascript ...<br /> <br /> D'ailleurs, qu'appelles-tu variable javascript ? Les trucs avec un var devant ? Si oui, je suis favorable au format thisIsAnExample. Sinon, si tu appelles des variables javascript ce qu'on récupère sur un formulaire, comme c'est du html, je suis pour le format this_is_an_example.<br /> <br /> --[[User:Zebuline|Zebuline]] 23:38, 3 January 2006 (CET)<br /> ==Votes==<br /> Concensus pour utiliser le formet $thisIsAnExample dans les variables PHP.<br /> <br /> Vote sur le format des variables en JavaScript.<br /> {| {{prettytable}}<br /> !Proposition!!Votant pour<br /> |-<br /> |utiliser le format thisIsAnExample||--[[User:Claratte|Christophe]] 15:58, 30 December 2005 (CET)<br /> |}</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Discussion:Coding-rules&diff=4530 2006-01-03T22:38:33Z

<p>Zebuline : /* Format des variables */</p> <hr /> <div>=Format des variables=<br /> Je suis pour le respect du format suivant concernant les variables :<br /> $thisIsAnExample<br /> <br /> J'ai pas trouvé de telle obligation dans PEAR alors que je pensais que c'était le cas... En fait c'est restreint aux fonctions. De même je pensais que c'était clairement décrit dans notre propres règles et il n'en n'est rien.<br /> <br /> Donc le sujet est ouvert...<br /> <br /> --[[User:Claratte|Christophe]] 15:53, 30 December 2005 (CET)<br /> <br /> Je suis d'accord, j'aime aussi ce format, mais uniquement pour les variables php.<br /> <br /> Par contre, pour les variables html (ce qui passe en POST ou en GET), je préfère les underscore, tout simplement parce que je n'aime pas voir des majuscules dans la barre d'adresse :)<br /> <br /> En gros, j'aime assez le format suivant :<br /> Variables php : <br /> $thisIsAnExemple<br /> &quot;Variables&quot; html : <br /> this_is_an_exemple<br /> Functions php : <br /> thisIsAnExemple()<br /> Et les noms de classes avec une majuscule<br /> <br /> --[[User:Zebuline|Zebuline]] 15:59, 30 December 2005 (CET)<br /> <br /> Dans ce cas pourquoi ne pas re-formater lors de &quot;l'import&quot; :<br /> $thisIsAnExample = getPost('this_is_an_example')<br /> <br /> Néanmoins, je préfère même pour html utiliser la règle générale. Je ne vois pas où est le problème (avec html).<br /> <br /> Y'a un truc aussi : normalement dans la barre d'adresse doit y avoir que l'adresse, pas de variable. Ces dernières doivent être passées par POST.<br /> <br /> --[[User:Claratte|Christophe]] 16:06, 30 December 2005 (CET)<br /> <br /> Heu, le reformattage, je le fais déjà ? Où est le pb ? --[[User:Zebuline|Zebuline]] 16:13, 30 December 2005 (CET)<br /> <br /> Je voyais tellement de fois aircraft_id dans ton fichier open_flight que je pensais qu'il s'agissait de la variable php...<br /> <br /> Sinon, voici un lien concernant les [http://www.port80software.com/support/articles/nextgenerationurls urls propres]<br /> <br /> --[[User:Claratte|Christophe]] 16:17, 30 December 2005 (CET)<br /> <br /> J'ai rien dit sur mon avis pour le format javascript ...<br /> --[[User:Zebuline|Zebuline]] 23:38, 3 January 2006 (CET)<br /> ==Votes==<br /> Concensus pour utiliser le formet $thisIsAnExample dans les variables PHP.<br /> <br /> Vote sur le format des variables en JavaScript.<br /> {| {{prettytable}}<br /> !Proposition!!Votant pour<br /> |-<br /> |utiliser le format thisIsAnExample||--[[User:Claratte|Christophe]] 15:58, 30 December 2005 (CET)<br /> |}</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Discussion:Coding-rules&diff=4529 2006-01-03T22:38:12Z

<p>Zebuline : /* Votes */</p> <hr /> <div>=Format des variables=<br /> Je suis pour le respect du format suivant concernant les variables :<br /> $thisIsAnExample<br /> <br /> J'ai pas trouvé de telle obligation dans PEAR alors que je pensais que c'était le cas... En fait c'est restreint aux fonctions. De même je pensais que c'était clairement décrit dans notre propres règles et il n'en n'est rien.<br /> <br /> Donc le sujet est ouvert...<br /> <br /> --[[User:Claratte|Christophe]] 15:53, 30 December 2005 (CET)<br /> <br /> Je suis d'accord, j'aime aussi ce format, mais uniquement pour les variables php.<br /> <br /> Par contre, pour les variables html (ce qui passe en POST ou en GET), je préfère les underscore, tout simplement parce que je n'aime pas voir des majuscules dans la barre d'adresse :)<br /> <br /> En gros, j'aime assez le format suivant :<br /> Variables php : <br /> $thisIsAnExemple<br /> &quot;Variables&quot; html : <br /> this_is_an_exemple<br /> Functions php : <br /> thisIsAnExemple()<br /> Et les noms de classes avec une majuscule<br /> <br /> --[[User:Zebuline|Zebuline]] 15:59, 30 December 2005 (CET)<br /> <br /> Dans ce cas pourquoi ne pas re-formater lors de &quot;l'import&quot; :<br /> $thisIsAnExample = getPost('this_is_an_example')<br /> <br /> Néanmoins, je préfère même pour html utiliser la règle générale. Je ne vois pas où est le problème (avec html).<br /> <br /> Y'a un truc aussi : normalement dans la barre d'adresse doit y avoir que l'adresse, pas de variable. Ces dernières doivent être passées par POST.<br /> <br /> --[[User:Claratte|Christophe]] 16:06, 30 December 2005 (CET)<br /> <br /> Heu, le reformattage, je le fais déjà ? Où est le pb ? --[[User:Zebuline|Zebuline]] 16:13, 30 December 2005 (CET)<br /> <br /> Je voyais tellement de fois aircraft_id dans ton fichier open_flight que je pensais qu'il s'agissait de la variable php...<br /> <br /> Sinon, voici un lien concernant les [http://www.port80software.com/support/articles/nextgenerationurls urls propres]<br /> <br /> --[[User:Claratte|Christophe]] 16:17, 30 December 2005 (CET)<br /> ==Votes==<br /> Concensus pour utiliser le formet $thisIsAnExample dans les variables PHP.<br /> <br /> Vote sur le format des variables en JavaScript.<br /> {| {{prettytable}}<br /> !Proposition!!Votant pour<br /> |-<br /> |utiliser le format thisIsAnExample||--[[User:Claratte|Christophe]] 15:58, 30 December 2005 (CET)<br /> |}</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Discussion:Coding-rules&diff=4452 2005-12-30T15:13:07Z

<p>Zebuline : </p> <hr /> <div>=Format des variables=<br /> Je suis pour le respect du format suivant concernant les variables :<br /> $thisIsAnExample<br /> <br /> J'ai pas trouvé de telle obligation dans PEAR alors que je pensais que c'était le cas... En fait c'est restreint aux fonctions. De même je pensais que c'était clairement décrit dans notre propres règles et il n'en n'est rien.<br /> <br /> Donc le sujet est ouvert...<br /> <br /> --[[User:Claratte|Christophe]] 15:53, 30 December 2005 (CET)<br /> <br /> Je suis d'accord, j'aime aussi ce format, mais uniquement pour les variables php.<br /> <br /> Par contre, pour les variables html (ce qui passe en POST ou en GET), je préfère les underscore, tout simplement parce que je n'aime pas voir des majuscules dans la barre d'adresse :)<br /> <br /> En gros, j'aime assez le format suivant :<br /> Variables php : <br /> $thisIsAnExemple<br /> &quot;Variables&quot; html : <br /> this_is_an_exemple<br /> Functions php : <br /> thisIsAnExemple()<br /> Et les noms de classes avec une majuscule<br /> <br /> --[[User:Zebuline|Zebuline]] 15:59, 30 December 2005 (CET)<br /> <br /> Dans ce cas pourquoi ne pas re-formater lors de &quot;l'import&quot; :<br /> $thisIsAnExample = getPost('this_is_an_example')<br /> <br /> Néanmoins, je préfère même pour html utiliser la règle générale. Je ne vois pas où est le problème (avec html).<br /> <br /> Y'a un truc aussi : normalement dans la barre d'adresse doit y avoir que l'adresse, pas de variable. Ces dernières doivent être passées par POST.<br /> <br /> --[[User:Claratte|Christophe]] 16:06, 30 December 2005 (CET)<br /> <br /> Heu, le reformattage, je le fais déjà ? Où est le pb ? --[[User:Zebuline|Zebuline]] 16:13, 30 December 2005 (CET)<br /> ==Votes==<br /> {| {{prettytable}}<br /> !Proposition!!Votant pour<br /> |-<br /> |utiliser dans tous les cas pour toutes les variables le format $thisIsAnExample (sauf les variables locales qui sont préfixées d'un underscore)||--[[User:Claratte|Christophe]] 15:58, 30 December 2005 (CET)<br /> |}</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Discussion:Coding-rules&diff=4447 2005-12-30T15:02:17Z

<p>Zebuline : /* Format des variables */</p> <hr /> <div>=Format des variables=<br /> Je suis pour le respect du format suivant concernant les variables :<br /> $thisIsAnExample<br /> <br /> J'ai pas trouvé de telle obligation dans PEAR alors que je pensais que c'était le cas... En fait c'est restreint aux fonctions. De même je pensais que c'était clairement décrit dans notre propres règles et il n'en n'est rien.<br /> <br /> Donc le sujet est ouvert...<br /> <br /> --[[User:Claratte|Christophe]] 15:53, 30 December 2005 (CET)<br /> <br /> Je suis d'accord, j'aime aussi ce format, mais uniquement pour les variables php.<br /> <br /> Par contre, pour les variables html (ce qui passe en POST ou en GET), je préfère les underscore, tout simplement parce que je n'aime pas voir des majuscules dans la barre d'adresse :)<br /> <br /> --[[User:Zebuline|Zebuline]] 15:59, 30 December 2005 (CET)<br /> <br /> ==Votes==<br /> {| {{prettytable}}<br /> !Proposition!!Votant pour<br /> |-<br /> |utiliser dans tous les cas pour toutes les variables le format $thisIsAnExample (sauf les variables locales qui sont préfixées d'un underscore)||--[[User:Claratte|Christophe]] 15:58, 30 December 2005 (CET)<br /> |}</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Discussion:Coding-rules&diff=4446 2005-12-30T14:59:39Z

<p>Zebuline : </p> <hr /> <div>=Format des variables=<br /> Je suis pour le respect du format suivant concernant les variables :<br /> $thisIsAnExample<br /> <br /> J'ai pas trouvé de telle obligation dans PEAR alors que je pensais que c'était le cas... En fait c'est restreint aux fonctions. De même je pensais que c'était clairement décrit dans notre propres règles et il n'en n'est rien.<br /> <br /> Donc le sujet est ouvert...<br /> <br /> Je suis d'accord, j'aime aussi ce format, mais uniquement pour les variables php.<br /> <br /> Par contre, pour les variables html (ce qui passe en POST ou en GET), je préfère les underscore, tout simplement parce que je n'aime pas voir des majuscules dans la barre d'adresse :)<br /> <br /> --[[User:Zebuline|Zebuline]] 15:59, 30 December 2005 (CET)<br /> <br /> --[[User:Claratte|Christophe]] 15:53, 30 December 2005 (CET)<br /> <br /> ==Votes==<br /> {| {{prettytable}}<br /> !Proposition!!Votant pour<br /> |-<br /> |utiliser dans tous les cas pour toutes les variables le format $thisIsAnExample (sauf les variables locales qui sont préfixées d'un underscore)||--[[User:Claratte|Christophe]] 15:58, 30 December 2005 (CET)<br /> |}</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Formules-de-calcul&diff=4418 2005-12-30T13:56:29Z

<p>Zebuline : </p> <hr /> <div>En vrac :<br /> <br /> =Formules sans notion de compteurs=<br /> Différence des heures départ/arrivée : <br /> %TIME_ARRIVAL - %TIME_DEPARTURE<br /> <br /> ==Temps de vol en Centièmes==<br /> Différence des heures départ/arrivée arrondie à 10 centièmes : <br /> roundDuration(%TIME_ARRIVAL - %TIME_DEPARTURE, 60)<br /> <br /> ==Temps de vol en Minutes==<br /> Différence des heures départ/arrivée arrondie à 5 minutes : <br /> roundDuration(%TIME_ARRIVAL - %TIME_DEPARTURE, 50)<br /> <br /> =Formules avec notion de compteurs=<br /> <br /> Différence des compteurs : <br /> %COUNTER_ARRIVAL - %COUNTER_DEPARTURE<br /> <br /> ==Temps de vol en Centièmes==<br /> Différence des compteurs arrondie à 10 centièmes : <br /> roundDuration(%COUNTER_ARRIVAL - %COUNTER_DEPARTURE, 60)<br /> Max des différences heures/(compteurs + 10 centièmes) : <br /> max(%TIME_ARRIVAL - %TIME_DEPARTURE, %COUNTER_ARRIVAL - %COUNTER_DEPARTURE + 60)<br /> <br /> ==Temps de vol en Minutes==<br /> Différence des compteurs arrondie à 5 minutes : <br /> roundDuration(%COUNTER_ARRIVAL - %COUNTER_DEPARTURE, 50)<br /> Max des différences heures/(compteurs + 5 minutes) : <br /> max(%TIME_ARRIVAL - %TIME_DEPARTURE, %COUNTER_ARRIVAL - %COUNTER_DEPARTURE + 50)</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Formules-de-calcul&diff=4417 2005-12-30T13:52:20Z

<p>Zebuline : </p> <hr /> <div>En vrac :<br /> <br /> =Formules sans notion de compteurs=<br /> Différence des heures départ/arrivée : &lt;nowiki&gt;%TIME_ARRIVAL - %TIME_DEPARTURE&lt;/nowiki&gt;<br /> <br /> ==Temps de vol en Centièmes==<br /> Différence des heures départ/arrivée arrondie à 10 centièmes : &lt;nowiki&gt;roundDuration(%TIME_ARRIVAL - %TIME_DEPARTURE, 60)&lt;/nowiki&gt;<br /> <br /> ==Temps de vol en Minutes==<br /> Différence des heures départ/arrivée arrondie à 5 minutes : &lt;nowiki&gt;roundDuration(%TIME_ARRIVAL - %TIME_DEPARTURE, 50)&lt;/nowiki&gt;<br /> <br /> =Formules avec notion de compteurs=<br /> <br /> Différence des compteurs : &lt;nowiki&gt;%COUNTER_ARRIVAL - %COUNTER_DEPARTURE&lt;/nowiki&gt;<br /> <br /> ==Temps de vol en Centièmes==<br /> Différence des compteurs arrondie à 10 centièmes : &lt;nowiki&gt;roundDuration(%COUNTER_ARRIVAL - %COUNTER_DEPARTURE, 60)&lt;/nowiki&gt;<br /> Max des différences heures/(compteurs + 10 centièmes) : &lt;nowiki&gt;max(%TIME_ARRIVAL - %TIME_DEPARTURE, %COUNTER_ARRIVAL - %COUNTER_DEPARTURE + 60)&lt;/nowiki&gt;<br /> <br /> ==Temps de vol en Minutes==<br /> Différence des compteurs arrondie à 5 minutes : &lt;nowiki&gt;roundDuration(%COUNTER_ARRIVAL - %COUNTER_DEPARTURE, 50)&lt;/nowiki&gt;<br /> Max des différences heures/(compteurs + 5 minutes) : &lt;nowiki&gt;max(%TIME_ARRIVAL - %TIME_DEPARTURE, %COUNTER_ARRIVAL - %COUNTER_DEPARTURE + 50)&lt;/nowiki&gt;</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Discussion:Account-Reporting&diff=4411 2005-12-30T13:19:13Z

<p>Zebuline : </p> <hr /> <div>J'ai juste un (ou plus) problème métaphysique :<br /> * Si le pilote n'a pas le droit de saisir ses règlement, il a néanmoins la possibilité de saisir le montant à se faire rembourser pour un avitaillement lors de la fermeture de son vol. Si on ne lui permet pas la saisie du montant, tel que c'est fait ça pose une erreur : le pilote a dit qu'il avait mis de l'essence/de l'huile, avant/après le vol, qu'il avait payé de sa poche (compte pilote dans la combo, intitulé à changer d'ailleurs, mais nos traducteurs trouveront mieux :) ), mais le montant est nul. On peut toujours récupérer l'exception jetée pas le script php et enregistrer une ligne (deux pour la double écriture) dans account_entry avec un montant nul pour signifier le remboursement, dont le trésorier va ensuite modifier le montant, mais ça me gêne :p<br /> * Si le trésorier constate une anomalie dans un approvisionnement, il a la possibilité de le modifier. D'accord. Mais si il remarque une anomalie dans un remboursement avitaillement, pour le modifier il faut soit le faire resaisir par le pilote, ce qui implique qu'il a le droit checkflight ou que l'avion n'a pas redécollé, ou bien le trésorier doit modifier le vol lui-même : il lui faut donc le droit checkflight, ou déléguer au gen qui va bien.<br /> <br /> Ce dernier point va vous embêter, vous aller dire que le trésorier doit avoir à sa disposition une interface pour modifier les remboursements avitaillement. Je veux bien, mais il ne pourra que modifier le montant, et pas supprimer le remboursement : ça demande beacoup de vérification de cas, et de modifier la ligne qui va bien dans la table fuelling ou lubricant (car soit il n'y a pas eu avitaillement du tout, dans ce cas il faut carrément supprimer la ligne, soit le pilote n'a pas payé de sa poche, et dans ce cas il faut modifier le champ fuel/lubricant_pay_type). Or le trésorier peut ne pas avoir tous les éléments en main, et décider que non il n'y a pas eu avitaillement, alors que si.<br /> <br /> Enfin, si j'envisage très bien la possibilité de modifier le montant d'un avitaillement, je n'envisage pas du tout la possibilité de le supprimer. Si la suppression est vraiment nécessaire, il faut qu'un utilisateur ayant le droit checkflight modifie le vol en conséquence.<br /> <br /> --[[User:Zebuline|Zebuline]] 23:55, 19 December 2005 (CET)<br /> <br /> Mes avis :<br /> *Il ne faut pas saisir des choses fausses (donc pas de ligne contenant 0 €)<br /> *Le droit de saisir une quantité d'essence n'est pas lié au droit de saisir le montant à se faire rembourser :<br /> **Un pilote (en fait quelqu'un qui a le droit &quot;saisir un vol&quot;) doit pouvoir saisir une quantité d'essence ajoutée à l'avion. Il s'agit d'une écriture sur le même papier que pour les heures de vols : le carnet de route.<br /> **Saisir un remboursement est lié à un autre papier : la compta.<br /> Donc :<br /> *Il faut dissocier la possibilité de saisir un vol de la possibilité de saisir un remboursement. Ou plutot, on peut avoir le droit de saisir un vol sans pour autant avoir le droit de saisir un remboursement pour soi.<br /> *Il faut créer un droit permettant de gérer les remboursements (et donc donnant le droit d'en ajouter et d'en supprimer). Il seront par la suite validés par le trésorier comme pour les paiements.<br /> *Il faut donc une interface spécifique à la gestion des remboursements.<br /> *Ces derniers doivent apparaitre en italique ou autre comme pour les paiements non validés (et jusqu'à temps de la validation).<br /> <br /> Ainsi voici la gestion de différents scénarii :<br /> *Si le pilote n'a pas le droit de saisir ses remboursements :<br /> **il saisit son vol et la quantité d'essence ajoutée.<br /> **il dépose dans la boite aux lettres prévue à cet effet la facture d'essence<br /> **le secrétaire disposant du droit permettant de gérer les remboursements saisie la facture d'essence en remboursement<br /> **le tresorier valide la saisie<br /> *Si le pilote a le droit de saisir ses remboursements :<br /> **il saisit son vol et la quantité d'essence ajoutée.<br /> **OF lui propose d'où vient l'essence (il dit que sa vient de l'extérieur et que c'est à rembourser sur son compte)<br /> **il saisit le montant de la facture d'essence<br /> **le trésorier valide le montant<br /> <br /> J'ai beau chercher mais je ne vois pas où on est obligé de coller une écriture en double avec un montant nul.<br /> <br /> Si j'ai bien compris, ce qui te gène c'est que si le trésorier annule un remboursement il faudrait que t'ailles chercher la quantité d'essence ajoutée dans l'avion et que tu la supprimes. Alors là, je t'arrête tout de suite : on s'en fout ! Ce n'est pas lié. L'écriture sur le carnet de route, n'a rien à voir avec l'écriture sur la compta ;-) Ce que je viens de dire, c'est la réalité du moment. Mais nous, on est plus malin ;-)<br /> <br /> Donc on va rajouter un petit 0 dans les possibilités du champ FUEL_PAY_TYPE dans la table fuelling qui vaudra &quot;Inconnu&quot; et qui ne sera pas proposable dans les combos. Il sera utilisé pour justement &quot;supprimer&quot; les paiements de type 3 (Pilot) refusés par le trésorier.<br /> <br /> Après bien sûr, on fera un système qui affichera les &quot;Unknown&quot; pour les gérer et puis aussi des alertes par mails pour les pilotes qui se sont vus refusés leur remboursement.<br /> <br /> --[[User:Claratte|Christophe]] 23:41, 26 December 2005 (CET)<br /> <br /> <br /> Ce qui me dérangeait, c'est le fait d'avoir des écritures dans account_entry en rapport avec un remboursement essence/huile, mais qui n'ait pas de lien avec un approvisionnement dans la table fuelling ou lubricant. Mais apparemment c'est pas grave :)<br /> <br /> Si j'ai bien compris, ce dont je doute, ça doit se passer comme ceci :<br /> * le pilote a le droit de saisir un remboursement. Le comptable, qui valide les remboursements, en trouve un dans les remboursements en attente de validation dont la somme ne correspond pas. En admettant qu'il ne se trompe pas, que ce qu'il croit ne pas correspondre est en effet une erreur de saisie de la part du pilote, et pas un autre approvisionnement à rembourser dont il n'a pas encore la facture, il peut modifier le montant de cet approvisionnement. Sont alors modifiés les champs credit et debit de la ligne account_entry correspondante. On a toujours la double_entry dans lubricant ou fuelling.<br /> * le pilote n'a pas le droit de saisir un remboursement. Il va renseigner les champs qui sont à sa portée dans le formulaire de fermeture de vol. Que doit-il renseigner comme moyen de paiement ? (je suis dans le cas ou il veut un remboursement) compte pilote (numéro 3), sans écriture dans account_entry ? ou bien unknown (numéro 0), et on lui grise la possibilité 3 ?<br /> * le comptable trouve une facture dans son tas de factures à rembourser, et ne voit pas de remboursement correspondant dans la liste des remboursements à valider (on est dans le cas où le pilote a oublié de saisir son approvisionnement, ou bien n'a pas le droit de saisir de remboursement). Il en saisit un nouveau. Ce remboursement (deux lignes dans account_entry), n'aura pas de lien avec la table fuelling ou lubricant.<br /> * problème : le comptable est allé trop vite, il a ajouté un remboursement à la main en recopiant une facture, et le pilote se rappelle qu'il a approvisionné l'avion en essence ou en huile, modifie son vol et ajoute l'approvisionnement et le remboursement. Le comptable se retrouve avec 2 remboursements pour le même approvisionnement. Peut-il en supprimer un ? (je crois qu'on a dit qu'on ne supprimait rien, pour éviter des abus de pouvoirs et des trucs qui disparaissent comme par magie) Ou faut-il que le pilote, s'il en a le droit, ou un utilisateur avec le droit checkFlight modifie le vol et change le moyen de paiment en unknown ? (ça me plait la dernière solution)<br /> <br /> --[[User:Zebuline|Zebuline]] 20:06, 29 December 2005 (CET)<br /> <br /> *Je ne comprend pas &quot;''On a toujours la double_entry dans lubricant ou fuelling.''&quot;. Y'a qu'une ligne dans lubricant ou fuelling ? || On a un champ dans la table fuelling et la table lubricant, qui pointe sur une éventuelle double entrée dans la table acount_entry.--[[User:Zebuline|Zebuline]] 14:19, 30 December 2005 (CET)<br /> *Si le pilote n'a pas le droit de saisir un remboursement, alors il n'a comme moyen de paiement que la cuve du club ou unknown (qu'on appelera plutot &quot;autre&quot;).<br /> *&quot;''le comptable trouve une facture''&quot; : on a le choix. Soit on fait comme tu dis, soit on crée également une entrée dans fuelling ou lubricant. Je préfèrerais créer une entrée...<br /> *&quot;''problème''&quot; : d'où l'intérêt de ma préférence pour le point précédent : si le comptable saisie le remboursement, alors le pilote verra que l'essence a été rajouté quand il voudra effectuer lui-même la correction de son erreur.<br /> <br /> Sinon pour la partie &quot;compta&quot;, y'a deux choses : soit l'écriture de remboursement est en italique dans les comptes (=non validée) et dans ce cas elle peut être supprimée, soit elle a été validée par le comptable et elle ne peut plus être supprimée et doit faire l'objet d'une écriture de correction.<br /> <br /> Ce qu'il faut bien voir c'est que la secrétaire peut très bien avoir le droit de saisir les remboursements (et pas les pilotes) mais que la validation se fasse par le trésorier.<br /> <br /> Donc :<br /> *tout pendant qu'on est en italique, on peut ajouter/modifier/supprimer les remboursements et faire la modif correspondante sur la table lubricant/fuel.<br /> *dès que l'écriture de remboursement est validée, on ne peut plus la supprimer et dans ce cas seule une écriture comptable de correction peut être faite. Dans ce cas, il n'y a plus de lien avec la table lubricant/fuel. On est en pure compta.<br /> <br /> Si on veut néanmoins pouvoir modifier les tables lubricant/fuel, faudrait donner la possibilité de modifier ces éléments là pour n'importe quel vol et à tout moment. Ce n'est pas très sain. Mais je ne l'exclue pas. Faudra y refléchir plus tard.<br /> <br /> Exemples d'oublis :<br /> *le pilote saisi son vol, oublie l'essence.<br /> **Si l'avion a revolé, il ne peut plus modifier son vol, donc il ne peut plus saisir l'essence. (si je me trompe tu me corriges)<br /> **Si l'avion n'a pas revolé, il peut modifier son vol et saisir l'essence (avec ou sans le remboursement suivant ses droits).<br /> *Le pilote saisi son vol, oublie l'essence, la secrétaire voit son remboursement le saisit et attribue l'essence sur le vol du pilote.<br /> **L'avion n'a toujours pas volé, et le pilote repense à son essence : il va pour modifier son vol, et là, voit que l'essence a été rajoutée. Il ne corrige donc pas.<br /> *Le pilote saisi son vol, oublie l'essence, la secrétaire voit son remboursement le saisit et attribue l'essence sur un autre vol que celui du pilote concerné.<br /> **L'avion n'a toujours pas volé, et le pilote repense à son essence : il va pour modifier son vol, et là, comme il ne voit rien, il saisit l'essence pour son vol.<br /> **Option A: Lors de la validation le trésorier pointe les remboursements et voit apparaitre deux fois le même montant saisi alors qu'il n'a qu'une facture. Il en supprime une. L'honneur est sauf.<br /> **Option B: Lors de la validation le trésorier pointe les remboursements et voit apparaitre deux fois le même montant, il est distrait et valide deux fois. L'honneur n'est pas sauf. L'erreur ne pourra alors être détectée qu'au moment du calcul du compte de résultat en fin d'année. Il y aura un écart entre :<br /> ***d'une part, le solde total des pilotes<br /> ***d'autre part, la différence des paiements des pilotes et des factures remboursées aux pilotes<br /> Pour isoler l'erreur faudra pointer !<br /> <br /> Mais je te rassure pour isoler l'erreur faut déjà faire le total des factures essences, au vu des factures. Ce type de travail, seul les assesseurs peuvent se le permettre. En général, ils ne vont pas jusque là. Donc l'erreur ne sera pas détectée et un pilote aura profité d'un remboursement indue.<br /> <br /> &lt;nowiki&gt;:D&lt;/nowiki&gt; --[[User:Claratte|Christophe]] 01:40, 30 December 2005 (CET)<br /> <br /> Bon alors :)<br /> * Si le comptable trouve une facture et ne voit pas de remboursement correspondant dans la liste des remboursements à valider, deux possibilités :<br /> ** la première : il faut modifier le vol pour ajouter directement l'approvisionnement, comme ça tous les liens sont créés : dans la table fueliing si c'est un approvisionnement essence, ou dans la table lubricant si c'est un approvisionnement huile, l'id du vol correspondant à cet approvisionnement; dans le champ qui va bien on renseigne la double entrée vers account_entry.<br /> ** la seconde, que je préfère : un formulaire de saisie des approvisionnements côté admin : on peut avoir une liste des vols les plus récents par avion (ou du moins les 30 derniers, ça devrait suffire, avec la possibilité d'afficher les 30 suivants, si le pilote a donné la facture 6 mois après, etc.), on clique sur le vol correspondant, et on saisit un approvisionnement. Comme ça on crée tous les liens qui vont bien, et le pilote, si d'un coup il se rappelle qu'il a oublié de saisir son approvisionnement et veut le faire, voit qu'il a déjà été rajouté par le secrétaire.<br /> <br /> Il faut bien comprendre que le point qui me dérnage le plus, c'est l'édition des liens entre les tables. Ca me dérange d'écrire des trucs dans account_entry en rapport avec un remboursement, et ne pas trouver l'approvisionnement correspondant. Pareil, saisir un approvisionnement sans trouver le vol.<br /> <br /> Sinon j'ai un autre problème : Tu as dit que quand le comptable a validé un approvisionnement, alors on ne peut plus y toucher. Je suis d'accord. (si on doit quand même rectifer qqch, le comptable fera un virement pour rétablir les choses, avec un commentaires explicatif, mais on ne touche plus à la ligne remboursement validée). Ce qui me dérange, c'est que tant que l'avion n'a pas volé, le pilote peut modifier son vol. Il faut, si la gestion des comptes est activée et qu'on trouve au moins un remoubrsement validé, lui masquer les sous-formulaires d'approvisionnement. L'ajout d'approvisionnements oubliés se fera côté admin (si on adopte ma seconde solution). Sinon, quand une personne ayant le droit checkFlight, de la même façon, si on trouve au moins un remboursement validé, il faut masquer les sous-formulaires. C'est la condition pour garantir l'intégrité des données comptables !<br /> <br /> --[[User:Zebuline|Zebuline]] 14:19, 30 December 2005 (CET)</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Discussion:Account-Reporting&diff=4399 2005-12-29T19:06:07Z

<p>Zebuline : </p> <hr /> <div>J'ai juste un (ou plus) problème métaphysique :<br /> * Si le pilote n'a pas le droit de saisir ses règlement, il a néanmoins la possibilité de saisir le montant à se faire rembourser pour un avitaillement lors de la fermeture de son vol. Si on ne lui permet pas la saisie du montant, tel que c'est fait ça pose une erreur : le pilote a dit qu'il avait mis de l'essence/de l'huile, avant/après le vol, qu'il avait payé de sa poche (compte pilote dans la combo, intitulé à changer d'ailleurs, mais nos traducteurs trouveront mieux :) ), mais le montant est nul. On peut toujours récupérer l'exception jetée pas le script php et enregistrer une ligne (deux pour la double écriture) dans account_entry avec un montant nul pour signifier le remboursement, dont le trésorier va ensuite modifier le montant, mais ça me gêne :p<br /> * Si le trésorier constate une anomalie dans un approvisionnement, il a la possibilité de le modifier. D'accord. Mais si il remarque une anomalie dans un remboursement avitaillement, pour le modifier il faut soit le faire resaisir par le pilote, ce qui implique qu'il a le droit checkflight ou que l'avion n'a pas redécollé, ou bien le trésorier doit modifier le vol lui-même : il lui faut donc le droit checkflight, ou déléguer au gen qui va bien.<br /> <br /> Ce dernier point va vous embêter, vous aller dire que le trésorier doit avoir à sa disposition une interface pour modifier les remboursements avitaillement. Je veux bien, mais il ne pourra que modifier le montant, et pas supprimer le remboursement : ça demande beacoup de vérification de cas, et de modifier la ligne qui va bien dans la table fuelling ou lubricant (car soit il n'y a pas eu avitaillement du tout, dans ce cas il faut carrément supprimer la ligne, soit le pilote n'a pas payé de sa poche, et dans ce cas il faut modifier le champ fuel/lubricant_pay_type). Or le trésorier peut ne pas avoir tous les éléments en main, et décider que non il n'y a pas eu avitaillement, alors que si.<br /> <br /> Enfin, si j'envisage très bien la possibilité de modifier le montant d'un avitaillement, je n'envisage pas du tout la possibilité de le supprimer. Si la suppression est vraiment nécessaire, il faut qu'un utilisateur ayant le droit checkflight modifie le vol en conséquence.<br /> <br /> --[[User:Zebuline|Zebuline]] 23:55, 19 December 2005 (CET)<br /> <br /> Mes avis :<br /> *Il ne faut pas saisir des choses fausses (donc pas de ligne contenant 0 €)<br /> *Le droit de saisir une quantité d'essence n'est pas lié au droit de saisir le montant à se faire rembourser :<br /> **Un pilote (en fait quelqu'un qui a le droit &quot;saisir un vol&quot;) doit pouvoir saisir une quantité d'essence ajoutée à l'avion. Il s'agit d'une écriture sur le même papier que pour les heures de vols : le carnet de route.<br /> **Saisir un remboursement est lié à un autre papier : la compta.<br /> Donc :<br /> *Il faut dissocier la possibilité de saisir un vol de la possibilité de saisir un remboursement. Ou plutot, on peut avoir le droit de saisir un vol sans pour autant avoir le droit de saisir un remboursement pour soi.<br /> *Il faut créer un droit permettant de gérer les remboursements (et donc donnant le droit d'en ajouter et d'en supprimer). Il seront par la suite validés par le trésorier comme pour les paiements.<br /> *Il faut donc une interface spécifique à la gestion des remboursements.<br /> *Ces derniers doivent apparaitre en italique ou autre comme pour les paiements non validés (et jusqu'à temps de la validation).<br /> <br /> Ainsi voici la gestion de différents scénarii :<br /> *Si le pilote n'a pas le droit de saisir ses remboursements :<br /> **il saisit son vol et la quantité d'essence ajoutée.<br /> **il dépose dans la boite aux lettres prévue à cet effet la facture d'essence<br /> **le secrétaire disposant du droit permettant de gérer les remboursements saisie la facture d'essence en remboursement<br /> **le tresorier valide la saisie<br /> *Si le pilote a le droit de saisir ses remboursements :<br /> **il saisit son vol et la quantité d'essence ajoutée.<br /> **OF lui propose d'où vient l'essence (il dit que sa vient de l'extérieur et que c'est à rembourser sur son compte)<br /> **il saisit le montant de la facture d'essence<br /> **le trésorier valide le montant<br /> <br /> J'ai beau chercher mais je ne vois pas où on est obligé de coller une écriture en double avec un montant nul.<br /> <br /> Si j'ai bien compris, ce qui te gène c'est que si le trésorier annule un remboursement il faudrait que t'ailles chercher la quantité d'essence ajoutée dans l'avion et que tu la supprimes. Alors là, je t'arrête tout de suite : on s'en fout ! Ce n'est pas lié. L'écriture sur le carnet de route, n'a rien à voir avec l'écriture sur la compta ;-) Ce que je viens de dire, c'est la réalité du moment. Mais nous, on est plus malin ;-)<br /> <br /> Donc on va rajouter un petit 0 dans les possibilités du champ FUEL_PAY_TYPE dans la table fuelling qui vaudra &quot;Inconnu&quot; et qui ne sera pas proposable dans les combos. Il sera utilisé pour justement &quot;supprimer&quot; les paiements de type 3 (Pilot) refusés par le trésorier.<br /> <br /> Après bien sûr, on fera un système qui affichera les &quot;Unknown&quot; pour les gérer et puis aussi des alertes par mails pour les pilotes qui se sont vus refusés leur remboursement.<br /> <br /> --[[User:Claratte|Christophe]] 23:41, 26 December 2005 (CET)<br /> <br /> <br /> Ce qui me dérangeait, c'est le fait d'avoir des écritures dans account_entry en rapport avec un remboursement essence/huile, mais qui n'ait pas de lien avec un approvisionnement dans la table fuelling ou lubricant. Mais apparemment c'est pas grave :)<br /> <br /> Si j'ai bien compris, ce dont je doute, ça doit se passer comme ceci :<br /> * le pilote a le droit de saisir un remboursement. Le comptable, qui valide les remboursements, en trouve un dans les remboursements en attente de validation dont la somme ne correspond pas. En admettant qu'il ne se trompe pas, que ce qu'il croit ne pas correspondre est en effet une erreur de saisie de la part du pilote, et pas un autre approvisionnement à rembourser dont il n'a pas encore la facture, il peut modifier le montant de cet approvisionnement. Sont alors modifiés les champs credit et debit de la ligne account_entry correspondante. On a toujours la double_entry dans lubricant ou fuelling.<br /> * le pilote n'a pas le droit de saisir un remboursement. Il va renseigner les champs qui sont à sa portée dans le formulaire de fermeture de vol. Que doit-il renseigner comme moyen de paiement ? (je suis dans le cas ou il veut un remboursement) compte pilote (numéro 3), sans écriture dans account_entry ? ou bien unknown (numéro 0), et on lui grise la possibilité 3 ?<br /> * le comptable trouve une facture dans son tas de factures à rembourser, et ne voit pas de remboursement correspondant dans la liste des remboursements à valider (on est dans le cas où le pilote a oublié de saisir son approvisionnement, ou bien n'a pas le droit de saisir de remboursement). Il en saisit un nouveau. Ce remboursement (deux lignes dans account_entry), n'aura pas de lien avec la table fuelling ou lubricant.<br /> * problème : le comptable est allé trop vite, il a ajouté un remboursement à la main en recopiant une facture, et le pilote se rappelle qu'il a approvisionné l'avion en essence ou en huile, modifie son vol et ajoute l'approvisionnement et le remboursement. Le comptable se retrouve avec 2 remboursements pour le même approvisionnement. Peut-il en supprimer un ? (je crois qu'on a dit qu'on ne supprimait rien, pour éviter des abus de pouvoirs et des trucs qui disparaissent comme par magie) Ou faut-il que le pilote, s'il en a le droit, ou un utilisateur avec le droit checkFlight modifie le vol et change le moyen de paiment en unknown ? (ça me plait la dernière solution)</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Discussion:Rights&diff=4342 2005-12-19T23:05:56Z

<p>Zebuline : </p> <hr /> <div>Autre cas peut-être à envisager : <br /> * cas où le pilote pourrait créditer lui-même son compte (chèque, chèque vacances), versement qui sera évidemment à faire valider par le gestionnaire des comptes.<br /> * cas où le pilote est un pilote baptême : il reçoit de l'argent (chèque, espèce), et le crédite sur le compte baptême.<br /> --[[User:194.51.20.123|194.51.20.123]] 09:08, 29 November 2005 (CET)philepil<br /> <br /> Effectivement il faut un droit donnant la possibilité de saisir une écriture correspondant à un encaissement autre qu'espèce.--[[User:Claratte|Christophe]] 14:36, 29 November 2005 (CET)<br /> <br /> <br /> Ca va faire beacoup de droit là :)<br /> Déjà qu'avec les droits liès à la gestion des vols ça dépasse de la page ...<br /> <br /> Solution qui ne plaît guère car elle ne va pas simplifier la vision globale de l'administrateur :<br /> Séparer les droits, et en faire plusieurs tableaux<br /> * un premier tableau avec tous les droits d'OF1.X<br /> * un second tableau avec tous les droits liès à la gestion des vols<br /> * un troisième tableau avec tous les droits liès à la gestion des comptes<br /> * (un quatrième avec les droits liès à la gestion de la mécanique ?)<br /> <br /> Ceci est facile à mettre en oeuvre, grâce à l'attribut parameter des éléments right dans le fichier xml. J'utilise déjà ce paramètre pour savoir si je montre ou pas les droits de la gestion des vols, en fonction de son activation dans OF. Donc fragmenter en plusieurs tableaux est simple à mettre en oeuvre.<br /> <br /> Sinon on pourrait faire en plus joli, et rajouter un autre attribut, appelé group par exemple, pour grouper les droits. Ainsi on pourrait créer les tableaux en fonction de cet attribut, et faire un tableau pour les droits liés au cahier, à l'administration ... On pourrait même éventuellement s'en servir pour des futurs codes couleur ?<br /> <br /> Le problème, je me répète, c'est que ça va multiplier les lignes, et pour avoir une vue d'ensemble des droits d'un profil, l'admin va devoir scroler dans son navigateur web. Mais si on fait bien les choses et qu'on regroupe bien par catégories, ça ne devrait pas être trop gênant. et puis ça ne dépasserait plus de la page dans le sens de la largeur, ce qui donne un truc tout laid avec les css actuels. Je ne suis pas très forte en css, je ne sais pas comment arranger ce débordement ;)<br /> <br /> --[[User:Zebuline|Zebuline]] 00:05, 20 December 2005 (CET)</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Discussion:Account-Reporting&diff=4341 2005-12-19T22:55:50Z

<p>Zebuline : </p> <hr /> <div>J'ai juste un (ou plus) problème métaphysique :<br /> * Si le pilote n'a pas le droit de saisir ses règlement, il a néanmoins la possibilité de saisir le montant à se faire rembourser pour un avitaillement lors de la fermeture de son vol. Si on ne lui permet pas la saisie du montant, tel que c'est fait ça pose une erreur : le pilote a dit qu'il avait mis de l'essence/de l'huile, avant/après le vol, qu'il avait payé de sa poche (compte pilote dans la combo, intitulé à changer d'ailleurs, mais nos traducteurs trouveront mieux :) ), mais le montant est nul. On peut toujours récupérer l'exception jetée pas le script php et enregistrer une ligne (deux pour la double écriture) dans account_entry avec un montant nul pour signifier le remboursement, dont le trésorier va ensuite modifier le montant, mais ça me gêne :p<br /> * Si le trésorier constate une anomalie dans un approvisionnement, il a la possibilité de le modifier. D'accord. Mais si il remarque une anomalie dans un remboursement avitaillement, pour le modifier il faut soit le faire resaisir par le pilote, ce qui implique qu'il a le droit checkflight ou que l'avion n'a pas redécollé, ou bien le trésorier doit modifier le vol lui-même : il lui faut donc le droit checkflight, ou déléguer au gen qui va bien.<br /> <br /> Ce dernier point va vous embêter, vous aller dire que le trésorier doit avoir à sa disposition une interface pour modifier les remboursements avitaillement. Je veux bien, mais il ne pourra que modifier le montant, et pas supprimer le remboursement : ça demande beacoup de vérification de cas, et de modifier la ligne qui va bien dans la table fuelling ou lubricant (car soit il n'y a pas eu avitaillement du tout, dans ce cas il faut carrément supprimer la ligne, soit le pilote n'a pas payé de sa poche, et dans ce cas il faut modifier le champ fuel/lubricant_pay_type). Or le trésorier peut ne pas avoir tous les éléments en main, et décider que non il n'y a pas eu avitaillement, alors que si.<br /> <br /> Enfin, si j'envisage très bien la possibilité de modifier le montant d'un avitaillement, je n'envisage pas du tout la possibilité de le supprimer. Si la suppression est vraiment nécessaire, il faut qu'un utilisateur ayant le droit checkflight modifie le vol en conséquence.<br /> <br /> --[[User:Zebuline|Zebuline]] 23:55, 19 December 2005 (CET)</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Discussion:Main-Page&diff=4169 2005-12-09T21:56:00Z

<p>Zebuline : Reverted edit of DedMoroz6, changed back to last version by Claratte</p> <hr /> <div>''Cette page de discussion peut être l'équivalent du &quot;bar du coin&quot; ou on parle des choses en général.''<br /> <br /> ==Multilanguisme &amp; xml/xsl==<br /> Plusieurs possibilités s'offrent à nous sur la façon de &quot;moderniser&quot; l'implémentation existante dans la version 1.2 d'OF du mulilanguisme.<br /> <br /> ===But===<br /> Actuellement le multilinguisme est gere par des fichiers langues sur le modele :<br /> $lang['ITEM'] = 'traduction dans une langue';<br /> <br /> Cette methode a plusieurs inconvenients :<br /> *elle ne permet pas de voir si un item a une traduction dans une langue ou non (il faut ouvrir le fichier de la langue concernee et rechercher l'item). Cela rend les mises a jour tres lourdes.<br /> *cela ne permet pas de trouver les &quot;items morts&quot;, c'est a dire les items qui devraient etre supprimes.<br /> *au fil du temps, les fichiers s'ettoffent et il n'y a pas de hierarchisation de l'information. Le parcours en devient difficile.<br /> Pour resumer ces points :<br /> la methode actuelle empeche la creation d'une interface de gestion facilitant la vie des traducteurs<br /> Un dernier inconvenient :<br /> *il n'y a pas possibilite d'avoir dynamiquement la traduction d'un item dans plusieurs langues. Une fois qu'un fichier langue est ouvert on n'utilise que celui-la.<br /> ===Tout d'abord, il y a deux méthodes de stockage des traductions :===<br /> *par base de données (dans ce cas on se tournerait vers la classe Translation2)<br /> *en mettant les textes dans du xml. Mais on perd en facilité de maintenance, ou alors on crée (ou on trouve) une classe qui gère ça.<br /> <br /> Mon avis : <br /> la base de donnée n'est pas adapté : les données sont statiques, et la base de données c'est trop lent (on va pas faire 40 requetes par page).<br /> xml : soit on parse à chauqe fois le fichier pour trouver la traduction (trop lent), soit on le parse une fois et on le met en mémoire (et donc, autant utiliser un fichier type .ini avec identifiant=valeur, c'est plus léger)<br /> --[[Utilisateur:KAeL|KAeL]] 3 Nov 2005 à 14:29 (CET)<br /> <br /> le fichier .ini c'est ce qu'on fait aujourd'hui. J'en presente les inconvenients dans les buts recherches ci-dessus. (mais peut-etre que je n'ai pas tout compris sur ce qu'on pouvait faire avec les fichiers .ini--[[Utilisateur:Claratte|Christophe]] 3 Nov 2005 à 23:40 (CET)<br /> <br /> ===Ensuite, vient la méthode de conversion de la feuille xsl :===<br /> Dans les deux cas, on part d'une feuille xsl qui va contenir des balises &lt;text&gt; définissant le texte à remplacer dans la bonne langue par exemple :<br /> <br /> &lt;nowiki&gt;&lt;b&gt;&lt;center&gt;<br /> &lt;text&gt;aircraft list&lt;/text&gt;<br /> &lt;xsl:value-of select=&quot;registration&quot;/&gt;<br /> &lt;/center&gt;&lt;/b&gt;&lt;/nowiki&gt;<br /> <br /> On a donc deux choix :<br /> <br /> *soit on effectue la transformation du &lt;text&gt;aircraft list&lt;/text&gt; en premier puis on obtient une deuxième feuille XSL (en fait la même que celle de Joël)<br /> *soit on effectue la transformation du xml via la feuille de style &quot;générique&quot;, on obtient alors une sortie presque-html avec les &lt;text&gt; puis on les remplace par la langue finale.<br /> <br /> Intérêt de la première méthode : on peut mettre en cache nos feuilles de styles adaptées à chaque langue, sachant que les modifications sur les langues ne doivent pas apparaitre dans une version stable d'OF.<br /> <br /> Intérêt de la seconde méthode : elle me parait plus simple...<br /> <br /> Ça me parait assez lourd comme approche --[[Utilisateur:KAeL|KAeL]] 3 Nov 2005 à 14:30 (CET)<br /> <br /> ===Dernier point : mappage xml/base de données===<br /> Dans translation2, les textes sont référencés selon 2 éléments (cf. [[Translation_Table]]) : un id qui &quot;nomme&quot; le texte et un page_id. Ainsi on peut avoir deux ids identiques mais sur des pages différentes. D'ou ma question : comment en verriez-vous l'utilisation concrète ? (quelles règles on se fixe ?)<br /> <br /> Je vous propose la suivante, on fait un &quot;mappage&quot; base de données/xml ainsi :<br /> <br /> &lt;text page=&quot;admin&quot;&gt;aircraft list&lt;/text&gt;<br /> <br /> avec le contenu élément de text qui correspond à l'id de la base de données et l'attribut page qui correspond au page_id.<br /> <br /> Avantage : on peut définir une page générique (champ page_id vide dans la base et sans attribut page sur le xml) qui contient les intitulés qui reviennent le plus souvent (comme &quot;valider&quot;, &quot;annuler&quot;, etc.)<br /> <br /> Inconvénient : la présence très fréquente de l'attribut page qui n'apporte pas grand chose.<br /> <br /> Une autre méthode : on ne met pas d'attribut page, et pour faire la relation on utilise le nom de la feuille xsl comme page_id.<br /> <br /> Avantage : c'est plus léger pour la page xsl<br /> <br /> Inconvénient : faut ré-écrire pour chaque page des mots identiques<br /> <br /> J'attend vos avis ;-)<br /> --[[Utilisateur:Claratte|Christophe]] 30 Sep 2005 à 01:47 (CEST)<br /> <br /> pareil qu'avant, je ne pense pas que ni xml ni une base de données ne soient les plus adaptés à la situation --[[Utilisateur:KAeL|KAeL]] 3 Nov 2005 à 14:32 (CET)<br /> <br /> == Dans tous les cas ==<br /> <br /> Je pense que dans tous les cas, on devrait commencer par se faire une classe OfTranslator avec qq méthodes génériques :<br /> setLang('fr')<br /> getLang() -&gt; renvoie 'fr'<br /> getAvailableLangs() -&gt; renvoie array('fr', 'en', ...)<br /> tr('hi') -&gt; salut (tr comme translate)<br /> <br /> Après derrière, on peut coder nos fonctions à nous où utiliser une classe PEAR comme Translation2.<br /> <br /> La question est : comment on stocke les données ?<br /> * en xml (qd on choisit la langue, on stocke les traductions en mémoire)<br /> * ds un fichier .ini (même remarque)<br /> * en base de données (lent, pas adapté)<br /> * en utilisant gettext (des infos ici : [http://www.gnu.org/software/gettext/manual/html_mono/gettext.html#SEC1 GNU gettext]) (supporté par Translation2)<br /> <br /> --[[Utilisateur:KAeL|KAeL]] 3 Nov 2005 à 14:40 (CET)<br /> <br /> Pour le stockage des données de traductions, il y a sqlite, c'est la bdd integrée a php5, pour les perf je vous revois sur leur site [http://www.sqlite.org/speed.html perf]<br /> <br /> Concernant gettext, je trouve ca par mal comme solution, c'est pas apache/php qui travaille, c'est gettext qui redirige vers la bonnes traduction, et vu qu'il est fait pour, il est surement plus optimisé que d'envoyer php a la recherche de traduc dans une bdd.<br /> <br /> De plus il existe des logiciels pour editer les fichiers de langues, c'est plus digeste que d'éditer les fichiers textes a la main<br /> <br /> <br /> Une explication de l'utilisation de gettext sur le [http://developpeur.journaldunet.com/tutoriel/php/030120php_localisation1b.shtml journal du net]<br /> <br /> Je vote pour gettext !!<br /> --[[Utilisateur:Scroses|Scroses]] 3 Nov 2005 à 20:05 (CET)<br /> <br /> (Pense a rajouter ta signature (avant derniere icone dans le formulaire d'edition), sinon on a du mal a suivre qui dit quoi)<br /> <br /> Merci pour le lien sur le journal du net, parce que l'introduction de gettext m'a laisse perplexe...<br /> <br /> Concernant sqlite, y'a pas plus de raison de l'utiliser comme base de donnes pour les traductions que pour le reste...<br /> <br /> Sinon pour gettext, je ne suis pas contre a priori mais je lui vois trois inconvenients :<br /> *il faut qu'il soit present sur le serveur<br /> *les outils sont plutot pour le monde linux alors que le but est de faire une interface de gestion accessible pour le commun des mortels<br /> *j'ai pas bien compris si les outils devaient etre sur le serveur ou si on pouvait editer les fichiers n'importe ou... (et j'ai cru comprendre qu'il fallait compiler les fichiers langues, ce qui est plutot lourd)<br /> --[[Utilisateur:Claratte|Christophe]] 3 Nov 2005 à 23:53 (CET)<br /> <br /> <br /> Les outils doivent etre sur le serveur, gettext fait parti des outils installés par defaut sur les distribs linux, apres il fatu savoir si les hebergeurs ont desactives l'options lors de l'installation, pour le savoir, il faut relire le phpinfo() du serveur.<br /> Pour les serveurs wamp ou easyphp, il faut aller decomenter php_gettext.dll dans php.ini<br /> <br /> Meme si les outils sont issus du monde linux (comme apache par ex :-) ca ne concerne que le serveur et pas les utilisateurs finaux devant leur pc<br /> <br /> pour l'histoire de la compilation des fichiers de langue, pour moi non plus c'est pas tres clair...Je creuse la question<br /> <br /> ps j'ai quelques pour signer...<br /> <br /> --[[Utilisateur:Scroses|Scroses]]<br /> <br /> Bon j'ai fais quelques recherches, en fait quand ils parlent de compilation, c'est en fait la fabrication a partir du fichier de traduction *.po du fichier catalogue *.mo. Des scripts php peuvent faire ca, mais des logiciels de traduction comme [http://www.poedit.org/index.php poedit] les generent automatiquement.<br /> <br /> J'ai meme vu des application php de traductions<br /> <br /> --Utopie 4 Nov 2005 à 10:07 (CET)</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=BTS&diff=3939 2005-11-29T19:08:04Z

<p>Zebuline : /* Traitement des bugs dans Mantis (pour les développeurs) */</p> <hr /> <div>= Introduction =<br /> <br /> Nous utilisons comme outil de &quot;traceur de bugs&quot; (ou Bug Tracking System) [http://mantis.openflyers.org/ Mantis].<br /> <br /> Pour pouvoir éditer des informations, il faut d'abord vous identifier.<br /> <br /> Lors de la création de votre compte, un mail vous est envoyé. Si vous ne le recevez pas, vérifiez qu'il n'a pas été mis de côté (voir supprimé) par un outil anti-spam attaché à votre messagerie.<br /> <br /> = Rapporter un bug dans Mantis (pour les testeurs/rapporteurs) =<br /> <br /> Avant de rapporter un bug, prenez le temps d'effectuer les actions suivantes :<br /> *Vérifier que le bug n'est pas déjà rapporté<br /> *Renseigner les items des le débuts pour éviter l'envoi dans une rubrique non adaptée<br /> *Choisissez la bonne catégorie :<br /> <br /> {| {{prettytable}}<br /> !Intitulé!!Rubrique<br /> |- <br /> |Admin||si cela touche la partie configuration/administration<br /> |-<br /> | Cahier des resa||si cela touche la partie &quot;cahier de réservations&quot;<br /> |- <br /> |Gestions des vols|| si cela touche la partie la saisie des vols<br /> |-<br /> | Gestions des comptes||si cela touche la partie financiers<br /> |-<br /> | Documentation|| si cela concerne des précision sur la documentation<br /> |-<br /> |UpDate||si cela touche l'utilitaire de changement de version<br /> |}<br /> *Choisissez la bonne version d'OpenFlyers sur laquelle vous avez constatée le bug (en effet nous filtrons et pouvons donc passer à côté d'un bug repertorié sous une mauvaise version). Le numéro de version se trouve en haut à gauche de la page d'accueil d'OF.<br /> 1.2<br /> 2.0 X<br /> 2.0<br /> <br /> *Résumé :<br /> Rédiger un intitulé explicite<br /> <br /> *Dans la description<br /> Si le bug est sur une version en ligne indiquer sur quelle base vous avez tester<br /> Si c'est une version en local indiquer l'état dans laquelle est votre Base de données. Faire éventuellement une sauvegarde pour la figer dans un stade ou le bug est reproductible<br /> <br /> Le descriptif doit être complet pour que les developpeurs sache identifier l'endroit du problème<br /> **La nature &quot;réelle&quot; (non affichage, warning, etc.) du problème et sa manifestation <br /> **Communiquer TOUS les éléments minimaux pour commencer à réfléchir au pourquoi du problème, c'est à dire:<br /> **OS utilisé (Windows 98, Windows XP, Linux, UNIX, Jaguar, etc.)<br /> **Navigateur utilisé (Safari, Internet Explorer, Netscape Navigator, Firefox, etc.)<br /> **La version du navigateur<br /> <br /> *Si vous utilisez une version d'OpenFlyers qui n'est pas hébergée par l'association OpenFlyers (si la version que vous utilisez est hébergée par l'association, alors son adresse internet est de la forme nomduclub.openflyers.org), merci de nous communiquez également les éléments suivants :<br /> **phpinfo() peut être utile pour pouvoir détecter un éventuel problème de configuration de votre serveur<br /> **il serait souhaitable, pour épargner un temps précieux, de s'assurer avant de signaler un bug que tous les fichiers sont uploadés correctement (présents sur le serveur, modifications maîtrisées).<br /> '''A noter que nous n'assurons pas le support pour les hébergeurs gratuits'''. En effet, ces derniers imposent souvent des limitations qui sont sans rapport avec les hébergeurs payant. Notre application fonctionne correctement sur un serveur Linux &quot;standard&quot; (avec quelques variantes possibles) mais avec des options qui peuvent parfois n'exister que sur des hébergeurs payants. La version 2.0 pourrait, par exemple, se révéler bien plus exigeante que la 1.2 au niveau des prérequis.<br /> <br /> * Joindres une copie d'écran est parfois plus explicite que de long discours. Ne pas en abuser, on ne cherche pas à documenter un bug pour le contourner mais à fournir des explications au développeur pour traitement<br /> <br /> * En cours de traitement, utiliser les notes pour ajouter des informations, évter les échéanges par email parrallèle<br /> Si le bug est sur une version en ligne indiquer sur quelle base vous avez tester.<br /> Si c'est une version en local indiquer l'état dans laquelle est votre Base de données. Faire éventuellement une sauvegarde pour la figer dans un stade ou le bug est reproductible.<br /> <br /> Le descriptif doit être complet pour que les developpeurs sache identifier l'endroit du problème<br /> <br /> Indiquer : votre système d'exploitation et le navigateur utilisé<br /> <br /> Joindres une copie d'écran et parfois plus explicite que de long discours mais ne pas en abuser, on ne cherche pas à documenter un bug pour le contourner mais à fournir des explication au développeur pour traitement<br /> <br /> * En cours de traitement, utiliser les notes pour ajouter des informations<br /> <br /> *Lorsque le bug est résolu vous recevrez un email d'information. Vous devez '''fermer vos bugs'''. Si vous constater que la solution ne correspond à votre description (totale ou parielle), relancez le sujet en le changeant d'etat. Par contre si vous détectez une nouvelles annomalie rédiger un nouveau bug.<br /> <br /> *La fermeture du Bug doit être effectué par celui qui l'a émis.<br /> <br /> *En l'absence d'action de votre part dans un temps raisonnable le developpeur ou un administrateur le fermera.<br /> <br /> = Traitement des bugs dans Mantis (pour les développeurs) =<br /> <br /> *Lorsqu'un bug est résolu il faut faire attention à le marquer comme tel dans la '''version en cours''' de modif (=donc normalement la future version publiée)<br /> <br /> *La fermeture du Bug doit être effectuée par celui qui l'a reporté.<br /> <br /> *En l'absence d'action de sa part dans un temps raisonnable le développeur ou un adminstrateur le fermera.<br /> <br /> '''Suivez vos bugs'''</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=BTS&diff=1832 2005-07-15T18:00:54Z

<p>Zebuline : /* Traitement des bugs dans Mantis (pour les développeurs) */</p> <hr /> <div>= Introduction =<br /> <br /> Nous utilisons comme outil de &quot;traceur de bugs&quot; (ou Bug Tracking System) [http://mantis.openflyers.org/ Mantis].<br /> <br /> Pour pouvoir éditer des informations, il faut d'abord vous identifier.<br /> <br /> Lors de la création de votre compte, un mail vous est envoyé. Si vous ne le recevez pas, vérifiez qu'il n'a pas été mis de côté (voir supprimé) par un outil anti-spam attaché à votre messagerie.<br /> <br /> = Rapporter un bug dans Mantis (pour les testeurs/rapporteurs) =<br /> <br /> Avant de rapporter un bug, prenez le temps d'effectuer les actions suivantes :<br /> *Vérifier que le bug n'est pas déjà rapporté<br /> *Communiquer TOUS les éléments minimaux pour commencer à réfléchir au pourquoi du problème, c'est à dire:<br /> **OS utilisé (Windows 98, Windows XP, Linux, UNIX, Jaguar, etc.)<br /> **Navigateur utilisé (Safari, Internet Explorer, Netscape Navigator, Firefox, etc.)<br /> **La version du navigateur<br /> **La nature &quot;réelle&quot; (non affichage, warning, etc.) du problème et sa manifestation (message d'erreur obtenu).<br /> *Choisissez la bonne version d'OpenFlyers sur laquelle vous avez constaté le bug (en effet nous filtrons et pouvons donc passer à côté d'un bug repertorié sous une mauvaise version). Le numéro de version se trouve en haut à gauche de la page d'accueil d'OF.<br /> *Choisissez la bonne catégorie :<br /> **Admin si cela touche la partie &quot;administration&quot;<br /> **Cahier de résa si cela touche la partie &quot;cahier&quot;<br /> *Si vous utilisez une version d'OpenFlyers qui n'est pas hébergée par l'association OpenFlyers (si la version que vous utilisez est hébergée par l'association, alors son adresse internet est de la forme nomduclub.openflyers.org), merci de nous communiquez également les éléments suivants :<br /> **phpinfo() peut être utile pour pouvoir détecter un éventuel problème de configuration de votre serveur<br /> **il serait souhaitable, pour épargner un temps précieux, de s'assurer avant de signaler un bug que tous les fichiers sont uploadés correctement (présents sur le serveur, modifications maîtrisées).<br /> <br /> '''A noter que nous n'assurons pas le support pour les hébergeurs gratuits'''. En effet, ces derniers imposent souvent des limitations qui sont sans rapport avec les hébergeurs payant. Notre application fonctionne correctement sur un serveur Linux &quot;standard&quot; (avec quelques variantes possibles) mais avec des options qui peuvent parfois n'exister que sur des hébergeurs payants. La version 1.2 pourrait, par exemple, se révéler bien plus exigeante que la 1.1 au niveau des prérequis.<br /> <br /> = Traitement des bugs dans Mantis (pour les développeurs) =<br /> Lorsqu'un bug est résolu il faut faire attention de bien :<br /> *marquer le bug résolu dans la version en cours de modif (=donc normalement la future version publiée)<br /> *puis fermer le bug</div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Fichier:Planning-sous.png&diff=1807 2005-06-07T17:41:31Z

<p>Zebuline : </p> <hr /> <div></div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Fichier:Reservation.png&diff=1802 2005-06-07T17:34:40Z

<p>Zebuline : </p> <hr /> <div></div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Fichier:Reglement.png&diff=1804 2005-06-07T17:34:29Z

<p>Zebuline : </p> <hr /> <div></div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Fichier:Planning-cote.png&diff=1803 2005-06-07T17:34:04Z

<p>Zebuline : </p> <hr /> <div></div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Fichier:Ouverture-vol.png&diff=1806 2005-06-07T17:33:38Z

<p>Zebuline : </p> <hr /> <div></div>

Zebuline https://doc2-fr.openflyers.com/index.php?title=Fichier:Fermeture-vol.png&diff=1805 2005-06-07T17:31:41Z

<p>Zebuline : </p> <hr /> <div></div>

Zebuline