Documentation de la solution web de gestion OpenFlyers version 3 - Contributions de l’utilisateur [fr]

Formules de calcul

2011-01-25T17:54:32Z

Drpiquouze : /* Formules */

=Calcul du temps de vol=
==Introduction==
Pour calculer le temps de vol, chaque club utilise en général une méthode bien à lui.

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.

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.

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.
==Définitions==
===variables===
====%TIME_DEPARTURE====
Heure de début saisie dans le formulaire
====%TIME_ARRIVAL====
Heure de fin saisie dans le formulaire
====%COUNTER_DEPARTURE====
Compteur départ saisi dans le formulaire
====%COUNTER_ARRIVAL====
Compteur arrivé saisi dans le formulaire
===Fonctions===
====roundDuration====
roundDuration(X,Y)
Arrondi la valeur X à l'unité Y la plus proche
Exemple :
roundDuration(114,100) donne 100

roundDuration(114,10) donne 110

'''Attention :''' Les valeurs de temps de vols sont en "[[time unit|sexacentimal]]".
1 minute = 10 sexacentièmes
5 minutes = 50 sexacentièmes

1 centième de minute = 6 sexacentièmes
10 centième de minute (=1 dixième de minute) = 60 sexacentièmes

Exemples :
pour arrondir à 5 minutes : roundDuration(X,50)

pour arrondir à 10 centièmes : roundDUration(X,60)

====max====
max(X,Y)
donne le max entre X et Y
==Formules==

*Les fonctions autorisées sont

max(valeur1,valeur2) : retient la plus grande des 2 valeurs

abs(valeur) : retour la valeur absolue

roundCeil(valeur,cible) : arrondie la valeur jusqu'à la cible

*Les mots clé autorisés

%DURATION : durée du vol

%COUNTERDEPARTURE : valeur du compteur de départ

%COUNTERARRIVAL : valeur du compteur d'arrivée

===Durée du vol===
%DURATION

===Différence des compteurs===
%COUNTER_ARRIVAL - %COUNTER_DEPARTURE
===Durée du vol arrondie à 5 minutes===
roundCeil(%DURATION, 50)

===Différence des compteurs plus 5 minutes ===
%COUNTER_ARRIVAL - %COUNTER_DEPARTURE + 50
===Différence des compteurs arrondie à 10 centièmes===
roundCeil(%COUNTER_ARRIVAL - %COUNTER_DEPARTURE, 60)

===Le plus grand entre la durée du vol et la différence des compteurs===
max(%DURATION, %COUNTER_ARRIVAL - %COUNTER_DEPARTURE)

===Le plus grand entre la durée du vol et la différence des compteurs arrondie à 5 minutes===
max(%DURATION,roundCeil(%COUNTER_ARRIVAL - %COUNTER_DEPARTURE, 50))
Cette formule calcule :
*la différence des compteurs et l'arrondi à 5 minutes
*la valeur de la durée de vol saisie par le pilote
Puis elle prend le plus grand des deux

===Le plus grand entre la durée du vol, arrondie à 5 minutes, et la différence des compteurs, arrondie à 5 minutes,===
max(roundCeil(%DURATION,50),roundCeil(%COUNTER_ARRIVAL - %COUNTER_DEPARTURE, 50))
Cette formule calcule :
*la différence des compteurs et l'arrondi à 5 minutes
*la valeur de la durée de vol saisie par le pilote et l'arrondi à 5 minutes
Puis elle prend le plus grand des deux
=Formules de tarification=
==Définitions==
Outre les définitions toujours valides pour le calcul du temps de vol, voici d'autres définitions :
''A rédiger''

Voir [http://doc-en.openflyers.com/index.php?title=AdminDoc2.1 Formules en anglais]

==Formules==
===Motoplaneur : tarification à l'heure de vol ET à l'utilisation du moteur===
Pour cela, on suppose que les compteurs sont utilisés et qu'ils prennent en compte le temps d'utilisation du moteur :
%DURATION * $FLIGHT_HOUR_PRICE + (%COUNTER_ARRIVAL - %COUNTER_DEPARTURE) * $ENGINE_HOUR_PRICE

===Avion : réduction lorsque le compte pilote a un solde positif===
$C2 concerne le tarif horaire de l'avion 
$S le solde positif qui doit être atteint pour bénéficier de la réduction 
$R le montant horaire de la réduction obtenue dans ce cas 

roundCeil((((getBalance(%PILOT)>$S ? ($C2-$R) : $C2)*%DURATION/600)-0.5),1)

===Avion : réduction lorsque le vol se fait après une certaine heure===

$C2 concerne le tarif horaire de l'avion 
$C2R concerne le tarif horaire réduit de l'avion après une certaine heure 
659 correspond à 06:59 en temps UTC 
Dans ce cas la formule considère que dès 700, la réduction s'applique. 

roundCeil(((((formatDate('hmm',%START_DATE)>659)?$C2R:$C2)*%DURATION/600)-0.5),1)

Formules de calcul

2011-01-10T14:24:32Z

Drpiquouze : /* Avion : réduction lorsque le compte pilote a un solde positif */

Formules de calcul

2011-01-10T13:24:22Z

Drpiquouze : /* Formules */

Kiosque PC

2009-06-27T18:25:19Z

Drpiquouze : /* iCab */

=Introduction=
Le but de cette page est de référencer et de proposer des solutions de configuration pour les ordinateurs en accès public, dans les aéro-clubs par exemple.
=Solutions Mac=
==iCab==
Pour réaliser un kiosque sur Mac, il est possible d'utiliser un iMac G3 (ordinateur tout en un) auquel on enlève le lecteur de CD/DVD, pour éviter les redémarrages sur un disque système, et sur lequel on installe [http://www.icab.de/ iCab], qui possède un mode kiosque très intéressant (Outils, Mode public), protégé par un mot de passe, et dans lequel ni le Dock de Mac Os X, ni la barre de menu n'apparaissent.

Malheureusement, iCab n'existe pas sous Windows.

Pour arriver directement sur la page de réservation, il faut mettre dans les ouvertures au démarrage un script en applescript, qui démarre automatiquement iCab en ouverture de session, en mode kiosque, et avec l'identifiant et le mot de passe d'un utilisateur invité, ce qui permet à la page de réservation de rester affichée et de se réactualiser régulièrement.

tell application "iCab"
Activate
enter kiosk mode with password "password"
-- ''le mot de passe qui permettra de sortir du mode kiosque avec le raccourci [Commande-k]''
OpenURL "http://monsite.org/?login=monidentifiant&password=monmotdepasse" toWindow -1
-- ''ouvre la page en question dans iCab et au premier plan, en introduisant identifiant et MdP de l'utilisateur invité''
end tell

Il faut supprimer toutes les barres d'affichage : Adresse, Barre d'état, Signets, Liens standards, dans les Préférences du mode Kiosk, et mettre la page d'OF en page d'accueil.

Il est néanmoins nécessaire dans le mode kiosque de garder la barre de navigation, pour relancer le navigateur lors des pertes de connexion.

Comme il est possible de n'autoriser la connexion qu'à un ou plusieurs sites nommément désignés par un système de filtres, il est très facile de bloquer le navigateur sur OF.

Bien entendu, ce mode kiosque doit être lancé depuis une session d'un utilisateur lancée sans mot de passe (permet les ouvertures et extinctions automatiques la nuit), utilisateur qui n'a aucun droit de gestion sur l'ordinateur et qui travaille sur un Finder restreint.

Une version Free existe, une version Pro sans limitations est disponible pour $20.

==Opera==
[http://www.opera.com/ Opera] qui est récemment devenu gratuit, possède également un mode kiosque, malheureusement perturbe complètement l'affichage d'OF.

==wKiosk Browser==
Il existe également [http://www.app4mac.com/wkioskbrowser.html wKiosk Browser], créé spécifiquement pour cet usage, mais payant ($69 pour un seul poste, la version d'essai quitte après une heure ). Il a des paramétrages très complets et en particulier relance la connexion lors du boot jusqu'à la connexion au site.
=Solutions PC=
==XNet==
Apparemment base sur Windows XP Pro. N'a pas l'air d'etre gratuit...
==Tout navigateur==
En l'absence d'un mode kiosque, il est toujours possible de mettre OpenFlyers en page par défaut du navigateur.
*Pour Firefox ou Internet Explorer, aller dans Outils-->Options... puis dans l'onglet "Général" et préciser "Afficher ma page d'accueil" avec l'adresse du site.
*Pour pousser la personnalisation, il est possible de mettre dans l'adresse le login et le mot de passe de l'utilisateur sans droit (type visiteur) afin de garder la page de cahier journalier affichée en permanence et dès le lancement du navigateur. Pour cela, suivre la méthode expliquée dans la partie "iCab" : <nowiki>http://www.mon_aero_club.fr/resa/</nowiki>'''?login=visiteur&password=visiteur''' si login et mot de passe du profil visiteur sont "visiteur" et "visiteur". Attention, ceci ne fonctionne que pour les comptes qui n'ont uniquement que le profil visiteur (profil sans aucun droits)
*Si vous mettez un raccourci vers votre navigateur dans le menu Démarrer-->Programmes-->Démarrage, le navigateur affichera le cahier en mode visiteur dès l'allumage du PC.

==Firefox==
Il existe des thèmes et extensions permettant de transformer Firefox en kiosque.
Par exemple R-kiosk.

Discussion:OF2.0

2006-08-11T18:59:28Z

Drpiquouze : /* Unités */

== Et l'huile ?? ==

De la meme manière que l'on saisit l'avitaillement en essence, il faudrait prévoir la même chose pour l'huile

== Sémantique ==

Je ne sais pas où placer les rêgles de construction des noms pour les tables. De plus, il me semble qu'on en a déjà parlé sur le forum, mais où ?

--[[User:Claratte|Christophe]] 16:41, 8 Jun 2005 (CEST)

== Unités ==

Il va falloir choisir des unités pour le carburant (et l'huile ;-)

--[[User:Claratte|Christophe]] 16:41, 8 Jun 2005 (CEST)

A cause de l'internationalisation, il va falloir prévoir plusieurs unités de mesures avec des tables de conversions, ce qui nous donne des litres, des imperials gallons, des US gallons

L'autre possibilité c'est de se limiter aux litres qui est l'unité internationale des volumes ( en aviation aussi ?) --[[User:Scroses|Stéphane]]

Eh eh ! C'est plus compliqué que cela, il faut aussi prévoir des unités de poids. Je ne sais pas si c'est utilisé en aviation légère mais c'est utilisé dès qu'on se met à couler des quantités raisonnables et que parler en tonnes pour le carburant est courant. En fait, l'essencier coule toujours des litres (débitmètres) et facture en tant que tel, mais dans l'avion l'autonomie est déterminée en fonction du poids. En effet, 10.000 L ne font par le même poids (et donc la même "énergie") qu'il fasse moins -20°C ou +40°C (à cause de la dilatation).

Donc en fait, je me pose la question, s'il ne serait pas intéressant de donner la possibilité de saisir les quantités dans l'unité souhaitée, et de stocker l'unité en plus de la quantité. C'est un peu dans le même état d'esprit que pour les heures de vol : ainsi on ne souffre pas de problème d'arrondi. La quantité saisie est bien la quantité enregistrée.--[[User:Claratte|Christophe]] 12:38, 10 Jun 2005 (CEST)

Ã‡a a l'air très compliqué tout ça d'autant plus que ce n'est pas dans un aéroclub on n'est pas près de faire des pleins de plusieurs tonnes de carburant.
Donc si comme tu le dis tous les débimètres du monde sont en litres, on fixe les litres comme unité de mesure.
Et si jamais Air France désire utiliser OF pour sa flotte, on facturera un patch de pour avoir les mesures en tonnes. --[[User:Scroses|Stéphane]]

Je l'attendais ;-)

Oui mais mon exemple perso veut dire qu'il y a peut-être d'autres systèmes dans d'autres endroits...--[[User:Claratte|Christophe]] 18:31, 10 Jun 2005 (CEST)

C'est sÃ»r que l'on peut trouver tout un tas de systèmes de mesure des volumes "exotiques", mais quand tu fais le plein de ton airbus, tu demandes à ton pompiste 1000 litres ou 700 tonnes de kéro ? (je sais j'ai pas tenu compte de la température :-)

Donc je pense qu'il faudrait dans la partie admin du club spécifier quelle est l'unité de mesure pour l'essence et l'huile. Par contre je serais pour le volume soit stocké dans la bdd en litre qui est l'unité de mesure internationale pour les volumes. Cela passera donc par une moulinette de conversion avant stockage dans la bdd

Voilà quelques unités de mesures des volumes

1 Litre = 33.824 ounces = 1.0570 Quarts = 0.2642 Gallons = 0.2200 Imperial Gallons

--[[User:Scroses|Stéphane]]

Je demande à mon pompiste un volume dans l'unité utilisée par son pays (donc dans 99% des cas des litres mais pour info aux états-unis ils ne connaissent pas les litres).

Autant je pense qu'il est intéressant de se poser la question "à quel niveau bloque-t-on l'unité ?" (plein, avion ou club), autant dans tous les cas, je suis contre une conversion en litre qui amène une inexactitude dans le traitement de l'information. Je ne pense pas que raisonner en terme d'unité internationale soit la bonne tactique, c'est un peu comme dire aux asiatiques de laisser tomber leur langue pour passer à l'informatique, alors que justement l'informatique peut très bien s'adapter aux particularités. Si on dit que la quantité enregistrée est des galons, pourquoi convertir en litres ? A partir du moment ou OF aura l'info que c'est des galons, il pourra toujours proposer une conversion à posteriori.

Donc je propose plusieurs solutions. Soit :
*créer un champ dans la table club définissant l'unité de volume
*créer un champ dans la table avion définissant une unité de volume (pour chaque avion donc)
*créer un champ dans la table contenant les pleins pour indiquer l'unité utilisée pour faire le plein.

La dernière solution à ma préférence. Elle est très simple à mettre en oeuvre. Pour additionner les quantités, il suffit de faire une requête qui distribue les quantités dans des colonnes en fonction de l'unité utilisée, puis d'additionner les colonnes, de convertir le résultat de chaque colonne dans l'unité d'affichage souhaitée, et d'additionner les résultats.--[[User:Claratte|Christophe]] 18:38, 11 Jun 2005 (CEST)

== Bargraph de potentiel ==

Jusqu'à présent je ne comprenais pas pourquoi je trouvais la représentation en bargraph non intuitive (sauf lorsqu'on a compris ;-)

Cela vient, il me semble du fait que la jauge se vide (de la droite vers la gauche) plutot que de se remplir (de la gauche vers la droite)

Ou alors, il faudrait pour le potentiel utilisé mettre la couleur de fond pour bien montrer qu'il n'est plus là justement.

Bref, si l'idée du bargraph me parait excellente, je pense qu'il faudra éventuellement affiner la représentation pour qu'elle soit compréhensible du premier coup et sans explication. Sinon, je suis sÃ»r qu'il y aura des pilotes qui diront : "je croyais que".

Une autre méthode, consisterait en une couleur unique par barre, qui passerait du vert au rouge au fur et à mesure que le potentiel diminue.

Une autre chose, qui permettrait peut-être de mieux comprendre est de me mettre les barres verticales (plutot qu'horizontales) : cela correspondrait plus à une jauge d'essence, donc à un potentiel.

--[[User:Claratte|Christophe]] 16:40, 8 Jun 2005 (CEST)

== Ordinateur autorisé à saisir les vols ==

Joël avait écrit :

> Pour la convivialité dans le club je préférai que la page la plus souvent visible soit la page du planning de réservation. Ceci ne doit pas être le cas lors d'une connexion standard ou c'est celle du login + mdp qui doit apparaître

Tout à fait. Mais attention : il faut considérer que la saisie des heures de vols doit pouvoir fonctionner sans avoir à rajouter un module particulier côté club pour identifier l'ordinateur.
Or aujourd'hui, pour l'armoire à clé, c'est comme cela que nous envisageons les choses : avec un sésameur qui envoie un message à OF pour dire "je suis là, retiens mon adresse IP".
La question est : peut-on créer un système suffisamment fiable pour que l'ordi du club et lui seul soit reconnu comme ordinateur autorisé à saisir les vols ?
Je penche vers un système faiblement sécurisé à l'aide d'un simple login/mdp (comme pour le mode visiteur).
Pour que les gens ne le connaissent pas, il suffit que le gestionnaire du club crée avec le navigateur un bookmark avec enregistrement du login et du mdp.
Une autre solution consisterait à permettre au gestionnaire du club d'aller dans un menu spécial de l'admin pour dire : "retiens cet ordi comme autorisé à saisir les vols". Et de ce fait, OF placerait un cookie particulier côté ordi.

Je suis favorable à l'un (voir au deux) systèmes, car cela évite d'avoir à créer un programme (comme le sésameur). D'autant plus qu'on reste dans le cas d'une utilisation somme toute classique et par conséquent qui doit être ouverte à un maximum de configuration.

J'aimerais qu'on garde la philosophie : "installation logicielle <=> installation matérielle". (le <=> veut dire si et seulement si (vieux souvenirs... pff...).

Par contre pour la gestion des clés, du fait l'obligation d'avoir une interface logicielle pour dialoguer avec l'armoire, la sécurisation est plus élevée.

J'aime bien la 2° solution : menu admin -> cookie particulier. ça permet d'autoriser de façon simple plusieurs ordi : celui en libre service au club, mais aussi celui de la secrétaire, du trésorier chez lui, au moins deux postes qui auraient à accéder aux fonctions "Flights" (la liste est pas exhaustive)--[[User:Jdepardieu|Jdepardieu]] 17:53, 4 December 2005 (CET)

Cette deuxieme solution me plait aussi, mais pour identifier l'ordinateur qui est physiquement relié à l'armoire a clef, plutôt d'utiliser l'adresse ip je proposerais d'utiliser l'adresse mac de la carte reseau. Elle a l'avantage d'identifier de maniere unique la carte reseau, c'est une adresse qui ne peut etre changée. Une adresse ip peut changer à chaque connection, il faudrait donc verifier si l'adresse du pc relié a l'armoire et toujours la même que celle référencé dans la "table des autorisations".--Utopie 21:02, 4 December 2005 (CET)

== Table des tarifs ==

Pour la colonne type de vol, il faudrait pouvoir y mettre les types sérialisés, cela permettrait de créer des tarifs particulier pour des types cumulés (IFR en montagne) bien que je n'en vois pas trop l'utilité. Mais j'ai un problème : la double doit-elle être considérée comme un type de vol au sens défini plus haut. Auquel cas, faut créer ce type en plus des IFR, montagne, etc. Mais ça me gêne, car le gars peut très bien ne pas mettre double comme type de vol. Donc il faudrait trouver un système pour lier un type à certains paramêtres (présence d'un instructeur ici). Si vous avez une idée...

Sinon, pour les tarifs qui changent en fonction du type de vol, il y a une autre voie que la sérialisation dans le champ "type de vol" : faire l'addition des prix pour chaque type. Ainsi y'aurait un tarif de base (l'avion). Si on fait de la double, on rajoute x euros, si on fait de l'IFR, y euros. Mais le problème c'est que cela ne permet pas au club de faire des ristournes sur certains cumuls. Bref, je ne sais pas trop.

== Vérifications comptables ==
*Il serait bon de générer un N° de pièce comptable permettant d'identifier le mouvement (Vol/versement/transfert entre compte adhérents, ...) Cela permettra une validation plus simple également au trésorier, et un élément concret au membre qui vient de faire la saisie.
*D'autre part, si OF peut générer un fichier au format EBP/CIEL ou autre pour transfert vers le logiciel comptable, vous aurez une solution qui intéressera encore plus de clubs.....

A+

--[[User:Hthepaut|Hthepaut]] 18:12, 20 Jul 2005 (CEST)

*Concernant le N° de mouvement il est prévu dans la table [[Accounting_entry_Table]] par contre il n'était pas prévu de le rendre visible.

Pourriez-vous expliciter comment cela peut aider le trésorier ? (afin de concevoir une interface qui l'aide réellement ;-)

Pour le membre, je pensais qu'une date suffisait à tracer facilement une écriture.

*Pour l'export, c'est le but recherché (sinon cela ne sert à rien de faire de la gestion de comptes ;-)

--[[User:Claratte|Christophe]] 10:35, 21 Jul 2005 (CEST)

Le N° de pièce permettra une traçabilité du paiement entre le membre et le trésorier. ce N° peut être reporté sur le chèque lui-même ou tout autre support (enveloppe, ...) qui servira à faire parvenir le mode de paiement jusqu'entre les "mains" du trésorier.

Ce N° peut également servir ultérieurement lorsque nous aborderons les annulations de saisie de vol. Car il y aura des erreurs de saisie (c'est inévitable). Le gestionnaire pourra alors demander à supprimer directement le vol N°xxxx, et resaisir en lieu et place de l'adhérent tête en l'air...Si vous n'avez pas prévu cette fonctionnalité, pensez-y.

--[[User:Hthepaut|Hthepaut]] 16:51, 21 Jul 2005 (CEST)

Pour la traçabilité du paiement, on pense plutôt utiliser le numéro lié au paiement (PAYMENT_NUM qui se trouve dans la table [[Accounting_entry_Table]]). Ainsi si c'est un paiement par chèque, alors on renseigne le numéro de chèque (on peut également y mettre le nom de la banque). Au dos du chèque, j'ai plutôt l'habitude d'y voir figurer le numéro du compte du pilote.

Néanmoins, le fait de faire figurer le numéro de mouvement peut aider au rapprochement. Mais je ne suis pas sÃ»r que cela n'entrainera pas d'autres erreurs de rapprochement dues à la focalisation sur le pointage du mouvement et donc plus de vérification sur le montant ni sur le destinataire.

Concernant les vols, on a prévu la gestion des vols non saisis (vols oubliés). Pour l'annulation ou la modification de mauvaises saisies on s'oriente vers un mode "brouillard" qui permettrait à l'utilisateur (ou au gestionnaire) de modifier ses saisies jusqu'à une validation ultérieure.

L'avantage du mode brouillard par rapport à une saisie sans retour possible est double :

- limiter le nombre de champs à renseigner (puisqu'il y a facilement la possibilité de revenir en arrière) et de validations à effectuer (sur aéro21, c'est un peu lourd : faut valider sur F8 puis sur F4, ou l'inverse, je ne sais plus).

- permettre à l'utilisateur de modifier facilement a posteriori sa saisie ! (par exemple, une fois rentré chez lui, il se dit : zut ! j'ai oublié ceci ou cela...) ou a un gestionnaire de bas niveau (mécanicien, instructeur) de corriger facilement une saisie sans avoir à passer par un gestionnaire de niveau supérieur (secrétaire, trésorier).

Par contre, une fois que c'est validé, il n'y aura plus de modification possible.

== M. Mme Mlle ! ==

Je m'élève vigoureusement contre le projet d'enregistrer dans OF les potentialités matrimoniales des femmes, sans qu'il en soit de même pour les hommes.

Le fait d'indiquer, même sous couvert de pudeur, le statut matrimonial (Mme ou Mlle) d'une femme est une discrimination sexiste inacceptable.

Est-ce qu'il est prévu de faire de même pour les hommes . (Monsieur et Mondamoiseau ?).

J'ai l'air de rigoler en disant ça, mais je pense que le problème est sérieux, et même si ce n'est pas notre rôle de faire évoluer la société et ses pesanteurs, il serait bon que nous adoptions une attitude neutre de ce point de vue.

--[[User:Drpiquouze|drpiquouze]] 20:46, 11 August 2006 (CEST)

Discussion:OF2.0

2006-08-11T18:52:48Z

Drpiquouze : /* Et l'huile ?? */

== Et l'huile ?? ==

De la meme manière que l'on saisit l'avitaillement en essence, il faudrait prévoir la même chose pour l'huile

== Sémantique ==

Je ne sais pas où placer les rêgles de construction des noms pour les tables. De plus, il me semble qu'on en a déjà parlé sur le forum, mais où ?

--[[User:Claratte|Christophe]] 16:41, 8 Jun 2005 (CEST)

== Unités ==

Il va falloir choisir des unités pour le carburant (et l'huile ;-)

--[[User:Claratte|Christophe]] 16:41, 8 Jun 2005 (CEST)

A cause de l'internationalisation, il va faloir prevoir plusieurs unitées de mesures avec des tables de convertions, ce qui nous donne des litres, des imperials gallons des US gallons

L'autre possibilité c'est de se limiter aux litres qui est l'unité internationale des volumes ( en aviation aussi ?) --[[User:Scroses|Stéphane]]

Eh eh ! C'est plus compliqué que cela, il faut aussi prévoir des unités de poids. Je ne sais pas si c'est utilisé en aviation légère mais c'est utilisé dès qu'on se met à couler des quantités raisonnables et que parler en tonnes pour le carburant est courant. En fait, l'essencier coule toujours des litres (débitmètres) et facture en tant que tel, mais dans l'avion l'autonomie est déterminée en fonction du poids. En effet, 10.000 L ne font par le même poids (et donc la même "énergie") qu'il fasse moins -20°C ou +40°C (à cause de la dilatation).

Donc en fait, je me pose la question, s'il ne serait pas intéressant de donner la possibilité de saisir les quantités dans l'unité souhaitée, et de stocker l'unité en plus de la quantité. C'est un peu dans le même état d'esprit que pour les heures de vol : ainsi on ne souffre pas de problème d'arrondi. La quantité saisie est bien la quantitée enregistrée.--[[User:Claratte|Christophe]] 12:38, 10 Jun 2005 (CEST)

Ca a l'air tres compliqué tout ca d'autant plus que c'est pas dans un aeroclub on n'est pas prés de faire des plein de plusieurs tonnes de carburant.
Donc si comme tu le dis tous les débimetres du monde sont en litres, un fixe les litres comme unitée de mesure.
Et si jamais Air France désire utiliser OF pour sa flotte, on facturera un patch de pour avoir les mesures en tonnes --[[User:Scroses|Stéphane]]

Je l'attendais ;-)

Oui mais mon exemple perso veut dire qu'il y a peut-être d'autres systèmes dans d'autres endroits...--[[User:Claratte|Christophe]] 18:31, 10 Jun 2005 (CEST)

C'est sur que l'on peut trouver tout un tas de systeme de mesure des volumes "exotiques", mais quand tu fais le plein de ton airbus, tu demande a ton pompiste 1000 litres ou 700 tonnes de kero ? (je sais j'ai pas tenu compte de la temperature :-)

Donc je pense qu'il faudrais dans la partie admin du club specifier quelle est l'unite de mesure pour l'essence et l'huile. Par contre je serais pour le volume soit stocke dans la bdd en litre qui est l'unité de mesure internationale pour les volumes. Cela passera donc par une moulinette de convertion avant stockage dans la bdd

Voila quelques unites de mesures des volumes

1 Litre = 33.824 ounces = 1.0570 Quarts = 0.2642 Gallons = 0.2200 Imperial Gallons

--[[User:Scroses|Stéphane]]

Je demande à mon pompiste un volume dans l'unité utilisée par son pays (donc dans 99% des cas des litres mais pour info aux états-unis ils ne connaissent pas les litres).

Autant je pense qu'il est intéressant de se poser la question "à quel niveau bloque-t-on l'unité ?" (plein, avion ou club), autant dans tous les cas, je suis contre une conversion en litre qui amène une inexactitude dans le traitement de l'information. Je ne pense pas que raisonner en terme d'unité internationale soit la bonne tactique, c'est un peu comme dire aux asiatiques de laisser tomber leur langue pour passer à l'informatique, alors que justement l'informatique peut très bien s'adapter aux particularités. Si on dit que la quantité enregistrée est des galons, pourquoi convertir en litres ? A partir du moment ou OF aura l'info que c'est des galons, il pourra toujours proposer une conversion à posteriori.

Donc je propose plusieurs solutions. Soit :
*créer un champ dans la table club définissant l'unité de volume
*créer un champ dans la table avion définissant une unité de volume (pour chaque avion donc)
*créer un champ dans la table contenant les pleins pour indiquer l'unité utilisée pour faire le plein.

La dernière solution à ma préférence. Elle est très simple à mettre en oeuvre. Pour additionner les quantités, il suffit de faire une requête qui distribue les quantités dans des colonnes en fonction de l'unité utilisée, puis d'additionner les colonnes, de convertir le résultat de chaque colonne dans l'unité d'affichage souhaitée, et d'additionner les résultats.--[[User:Claratte|Christophe]] 18:38, 11 Jun 2005 (CEST)

== Bargraph de potentiel ==

Jusqu'à présent je ne comprenais pas pourquoi je trouvais la représentation en bargraph non intuitive (sauf lorsqu'on a compris ;-)

Cela vient, il me semble du fait que la jauge se vide (de la droite vers la gauche) plutot que de se remplir (de la gauche vers la droite)

Ou alors, il faudrait pour le potentiel utilisé mettre la couleur de fond pour bien montrer qu'il n'est plus là justement.

Bref, si l'idée du bargraph me parait excellente, je pense qu'il faudra éventuellement affiner la représentation pour qu'elle soit compréhensible du premier coup et sans explication. Sinon, je suis sÃ»r qu'il y aura des pilotes qui diront : "je croyais que".

Une autre méthode, consisterait en une couleur unique par barre, qui passerait du vert au rouge au fur et à mesure que le potentiel diminue.

Une autre chose, qui permettrait peut-être de mieux comprendre est de me mettre les barres verticales (plutot qu'horizontales) : cela correspondrait plus à une jauge d'essence, donc à un potentiel.

--[[User:Claratte|Christophe]] 16:40, 8 Jun 2005 (CEST)

== Ordinateur autorisé à saisir les vols ==

Joël avait écrit :

> Pour la convivialité dans le club je préférai que la page la plus souvent visible soit la page du planning de réservation. Ceci ne doit pas être le cas lors d'une connexion standard ou c'est celle du login + mdp qui doit apparaître

Tout à fait. Mais attention : il faut considérer que la saisie des heures de vols doit pouvoir fonctionner sans avoir à rajouter un module particulier côté club pour identifier l'ordinateur.
Or aujourd'hui, pour l'armoire à clé, c'est comme cela que nous envisageons les choses : avec un sésameur qui envoie un message à OF pour dire "je suis là, retiens mon adresse IP".
La question est : peut-on créer un système suffisamment fiable pour que l'ordi du club et lui seul soit reconnu comme ordinateur autorisé à saisir les vols ?
Je penche vers un système faiblement sécurisé à l'aide d'un simple login/mdp (comme pour le mode visiteur).
Pour que les gens ne le connaissent pas, il suffit que le gestionnaire du club crée avec le navigateur un bookmark avec enregistrement du login et du mdp.
Une autre solution consisterait à permettre au gestionnaire du club d'aller dans un menu spécial de l'admin pour dire : "retiens cet ordi comme autorisé à saisir les vols". Et de ce fait, OF placerait un cookie particulier côté ordi.

Je suis favorable à l'un (voir au deux) systèmes, car cela évite d'avoir à créer un programme (comme le sésameur). D'autant plus qu'on reste dans le cas d'une utilisation somme toute classique et par conséquent qui doit être ouverte à un maximum de configuration.

J'aimerais qu'on garde la philosophie : "installation logicielle <=> installation matérielle". (le <=> veut dire si et seulement si (vieux souvenirs... pff...).

Par contre pour la gestion des clés, du fait l'obligation d'avoir une interface logicielle pour dialoguer avec l'armoire, la sécurisation est plus élevée.

J'aime bien la 2° solution : menu admin -> cookie particulier. ça permet d'autoriser de façon simple plusieurs ordi : celui en libre service au club, mais aussi celui de la secrétaire, du trésorier chez lui, au moins deux postes qui auraient à accéder aux fonctions "Flights" (la liste est pas exhaustive)--[[User:Jdepardieu|Jdepardieu]] 17:53, 4 December 2005 (CET)

Cette deuxieme solution me plait aussi, mais pour identifier l'ordinateur qui est physiquement relié à l'armoire a clef, plutôt d'utiliser l'adresse ip je proposerais d'utiliser l'adresse mac de la carte reseau. Elle a l'avantage d'identifier de maniere unique la carte reseau, c'est une adresse qui ne peut etre changée. Une adresse ip peut changer à chaque connection, il faudrait donc verifier si l'adresse du pc relié a l'armoire et toujours la même que celle référencé dans la "table des autorisations".--Utopie 21:02, 4 December 2005 (CET)

== Table des tarifs ==

Pour la colonne type de vol, il faudrait pouvoir y mettre les types sérialisés, cela permettrait de créer des tarifs particulier pour des types cumulés (IFR en montagne) bien que je n'en vois pas trop l'utilité. Mais j'ai un problème : la double doit-elle être considérée comme un type de vol au sens défini plus haut. Auquel cas, faut créer ce type en plus des IFR, montagne, etc. Mais ça me gêne, car le gars peut très bien ne pas mettre double comme type de vol. Donc il faudrait trouver un système pour lier un type à certains paramêtres (présence d'un instructeur ici). Si vous avez une idée...

Sinon, pour les tarifs qui changent en fonction du type de vol, il y a une autre voie que la sérialisation dans le champ "type de vol" : faire l'addition des prix pour chaque type. Ainsi y'aurait un tarif de base (l'avion). Si on fait de la double, on rajoute x euros, si on fait de l'IFR, y euros. Mais le problème c'est que cela ne permet pas au club de faire des ristournes sur certains cumuls. Bref, je ne sais pas trop.

== Vérifications comptables ==
*Il serait bon de générer un N° de pièce comptable permettant d'identifier le mouvement (Vol/versement/transfert entre compte adhérents, ...) Cela permettra une validation plus simple également au trésorier, et un élément concret au membre qui vient de faire la saisie.
*D'autre part, si OF peut générer un fichier au format EBP/CIEL ou autre pour transfert vers le logiciel comptable, vous aurez une solution qui intéressera encore plus de clubs.....

A+

--[[User:Hthepaut|Hthepaut]] 18:12, 20 Jul 2005 (CEST)

*Concernant le N° de mouvement il est prévu dans la table [[Accounting_entry_Table]] par contre il n'était pas prévu de le rendre visible.

Pourriez-vous expliciter comment cela peut aider le trésorier ? (afin de concevoir une interface qui l'aide réellement ;-)

Pour le membre, je pensais qu'une date suffisait à tracer facilement une écriture.

*Pour l'export, c'est le but recherché (sinon cela ne sert à rien de faire de la gestion de comptes ;-)

--[[User:Claratte|Christophe]] 10:35, 21 Jul 2005 (CEST)

Le N° de pièce permettra une traçabilité du paiement entre le membre et le trésorier. ce N° peut être reporté sur le chèque lui-même ou tout autre support (enveloppe, ...) qui servira à faire parvenir le mode de paiement jusqu'entre les "mains" du trésorier.

Ce N° peut également servir ultérieurement lorsque nous aborderons les annulations de saisie de vol. Car il y aura des erreurs de saisie (c'est inévitable). Le gestionnaire pourra alors demander à supprimer directement le vol N°xxxx, et resaisir en lieu et place de l'adhérent tête en l'air...Si vous n'avez pas prévu cette fonctionnalité, pensez-y.

--[[User:Hthepaut|Hthepaut]] 16:51, 21 Jul 2005 (CEST)

Pour la traçabilité du paiement, on pense plutôt utiliser le numéro lié au paiement (PAYMENT_NUM qui se trouve dans la table [[Accounting_entry_Table]]). Ainsi si c'est un paiement par chèque, alors on renseigne le numéro de chèque (on peut également y mettre le nom de la banque). Au dos du chèque, j'ai plutôt l'habitude d'y voir figurer le numéro du compte du pilote.

Néanmoins, le fait de faire figurer le numéro de mouvement peut aider au rapprochement. Mais je ne suis pas sÃ»r que cela n'entrainera pas d'autres erreurs de rapprochement dues à la focalisation sur le pointage du mouvement et donc plus de vérification sur le montant ni sur le destinataire.

Concernant les vols, on a prévu la gestion des vols non saisis (vols oubliés). Pour l'annulation ou la modification de mauvaises saisies on s'oriente vers un mode "brouillard" qui permettrait à l'utilisateur (ou au gestionnaire) de modifier ses saisies jusqu'à une validation ultérieure.

L'avantage du mode brouillard par rapport à une saisie sans retour possible est double :

- limiter le nombre de champs à renseigner (puisqu'il y a facilement la possibilité de revenir en arrière) et de validations à effectuer (sur aéro21, c'est un peu lourd : faut valider sur F8 puis sur F4, ou l'inverse, je ne sais plus).

- permettre à l'utilisateur de modifier facilement a posteriori sa saisie ! (par exemple, une fois rentré chez lui, il se dit : zut ! j'ai oublié ceci ou cela...) ou a un gestionnaire de bas niveau (mécanicien, instructeur) de corriger facilement une saisie sans avoir à passer par un gestionnaire de niveau supérieur (secrétaire, trésorier).

Par contre, une fois que c'est validé, il n'y aura plus de modification possible.

== M. Mme Mlle ! ==

Je m'élève vigoureusement contre le projet d'enregistrer dans OF les potentialités matrimoniales des femmes, sans qu'il en soit de même pour les hommes.

Le fait d'indiquer, même sous couvert de pudeur, le statut matrimonial (Mme ou Mlle) d'une femme est une discrimination sexiste inacceptable.

Est-ce qu'il est prévu de faire de même pour les hommes . (Monsieur et Mondamoiseau ?).

J'ai l'air de rigoler en disant ça, mais je pense que le problème est sérieux, et même si ce n'est pas notre rôle de faire évoluer la société et ses pesanteurs, il serait bon que nous adoptions une attitude neutre de ce point de vue.

--[[User:Drpiquouze|drpiquouze]] 20:46, 11 August 2006 (CEST)

Discussion:OF2.0

2006-08-11T18:51:03Z

Drpiquouze : /* Vérifications comptable */

== Et l'huile ?? ==

De la meme manière que l'on saisie l'avitaillement en essence, il faudrait prevoir la même chose pour l'huile

== Sémantique ==

Je ne sais pas où placer les rêgles de construction des noms pour les tables. De plus, il me semble qu'on en a déjà parlé sur le forum, mais où ?

--[[User:Claratte|Christophe]] 16:41, 8 Jun 2005 (CEST)

== Unités ==

Il va falloir choisir des unités pour le carburant (et l'huile ;-)

--[[User:Claratte|Christophe]] 16:41, 8 Jun 2005 (CEST)

A cause de l'internationalisation, il va faloir prevoir plusieurs unitées de mesures avec des tables de convertions, ce qui nous donne des litres, des imperials gallons des US gallons

L'autre possibilité c'est de se limiter aux litres qui est l'unité internationale des volumes ( en aviation aussi ?) --[[User:Scroses|Stéphane]]

Eh eh ! C'est plus compliqué que cela, il faut aussi prévoir des unités de poids. Je ne sais pas si c'est utilisé en aviation légère mais c'est utilisé dès qu'on se met à couler des quantités raisonnables et que parler en tonnes pour le carburant est courant. En fait, l'essencier coule toujours des litres (débitmètres) et facture en tant que tel, mais dans l'avion l'autonomie est déterminée en fonction du poids. En effet, 10.000 L ne font par le même poids (et donc la même "énergie") qu'il fasse moins -20°C ou +40°C (à cause de la dilatation).

Donc en fait, je me pose la question, s'il ne serait pas intéressant de donner la possibilité de saisir les quantités dans l'unité souhaitée, et de stocker l'unité en plus de la quantité. C'est un peu dans le même état d'esprit que pour les heures de vol : ainsi on ne souffre pas de problème d'arrondi. La quantité saisie est bien la quantitée enregistrée.--[[User:Claratte|Christophe]] 12:38, 10 Jun 2005 (CEST)

Ca a l'air tres compliqué tout ca d'autant plus que c'est pas dans un aeroclub on n'est pas prés de faire des plein de plusieurs tonnes de carburant.
Donc si comme tu le dis tous les débimetres du monde sont en litres, un fixe les litres comme unitée de mesure.
Et si jamais Air France désire utiliser OF pour sa flotte, on facturera un patch de pour avoir les mesures en tonnes --[[User:Scroses|Stéphane]]

Je l'attendais ;-)

Oui mais mon exemple perso veut dire qu'il y a peut-être d'autres systèmes dans d'autres endroits...--[[User:Claratte|Christophe]] 18:31, 10 Jun 2005 (CEST)

C'est sur que l'on peut trouver tout un tas de systeme de mesure des volumes "exotiques", mais quand tu fais le plein de ton airbus, tu demande a ton pompiste 1000 litres ou 700 tonnes de kero ? (je sais j'ai pas tenu compte de la temperature :-)

Donc je pense qu'il faudrais dans la partie admin du club specifier quelle est l'unite de mesure pour l'essence et l'huile. Par contre je serais pour le volume soit stocke dans la bdd en litre qui est l'unité de mesure internationale pour les volumes. Cela passera donc par une moulinette de convertion avant stockage dans la bdd

Voila quelques unites de mesures des volumes

1 Litre = 33.824 ounces = 1.0570 Quarts = 0.2642 Gallons = 0.2200 Imperial Gallons

--[[User:Scroses|Stéphane]]

Je demande à mon pompiste un volume dans l'unité utilisée par son pays (donc dans 99% des cas des litres mais pour info aux états-unis ils ne connaissent pas les litres).

Autant je pense qu'il est intéressant de se poser la question "à quel niveau bloque-t-on l'unité ?" (plein, avion ou club), autant dans tous les cas, je suis contre une conversion en litre qui amène une inexactitude dans le traitement de l'information. Je ne pense pas que raisonner en terme d'unité internationale soit la bonne tactique, c'est un peu comme dire aux asiatiques de laisser tomber leur langue pour passer à l'informatique, alors que justement l'informatique peut très bien s'adapter aux particularités. Si on dit que la quantité enregistrée est des galons, pourquoi convertir en litres ? A partir du moment ou OF aura l'info que c'est des galons, il pourra toujours proposer une conversion à posteriori.

Donc je propose plusieurs solutions. Soit :
*créer un champ dans la table club définissant l'unité de volume
*créer un champ dans la table avion définissant une unité de volume (pour chaque avion donc)
*créer un champ dans la table contenant les pleins pour indiquer l'unité utilisée pour faire le plein.

La dernière solution à ma préférence. Elle est très simple à mettre en oeuvre. Pour additionner les quantités, il suffit de faire une requête qui distribue les quantités dans des colonnes en fonction de l'unité utilisée, puis d'additionner les colonnes, de convertir le résultat de chaque colonne dans l'unité d'affichage souhaitée, et d'additionner les résultats.--[[User:Claratte|Christophe]] 18:38, 11 Jun 2005 (CEST)

== Bargraph de potentiel ==

Jusqu'à présent je ne comprenais pas pourquoi je trouvais la représentation en bargraph non intuitive (sauf lorsqu'on a compris ;-)

Cela vient, il me semble du fait que la jauge se vide (de la droite vers la gauche) plutot que de se remplir (de la gauche vers la droite)

Ou alors, il faudrait pour le potentiel utilisé mettre la couleur de fond pour bien montrer qu'il n'est plus là justement.

Bref, si l'idée du bargraph me parait excellente, je pense qu'il faudra éventuellement affiner la représentation pour qu'elle soit compréhensible du premier coup et sans explication. Sinon, je suis sÃ»r qu'il y aura des pilotes qui diront : "je croyais que".

Une autre méthode, consisterait en une couleur unique par barre, qui passerait du vert au rouge au fur et à mesure que le potentiel diminue.

Une autre chose, qui permettrait peut-être de mieux comprendre est de me mettre les barres verticales (plutot qu'horizontales) : cela correspondrait plus à une jauge d'essence, donc à un potentiel.

--[[User:Claratte|Christophe]] 16:40, 8 Jun 2005 (CEST)

== Ordinateur autorisé à saisir les vols ==

Joël avait écrit :

> Pour la convivialité dans le club je préférai que la page la plus souvent visible soit la page du planning de réservation. Ceci ne doit pas être le cas lors d'une connexion standard ou c'est celle du login + mdp qui doit apparaître

Tout à fait. Mais attention : il faut considérer que la saisie des heures de vols doit pouvoir fonctionner sans avoir à rajouter un module particulier côté club pour identifier l'ordinateur.
Or aujourd'hui, pour l'armoire à clé, c'est comme cela que nous envisageons les choses : avec un sésameur qui envoie un message à OF pour dire "je suis là, retiens mon adresse IP".
La question est : peut-on créer un système suffisamment fiable pour que l'ordi du club et lui seul soit reconnu comme ordinateur autorisé à saisir les vols ?
Je penche vers un système faiblement sécurisé à l'aide d'un simple login/mdp (comme pour le mode visiteur).
Pour que les gens ne le connaissent pas, il suffit que le gestionnaire du club crée avec le navigateur un bookmark avec enregistrement du login et du mdp.
Une autre solution consisterait à permettre au gestionnaire du club d'aller dans un menu spécial de l'admin pour dire : "retiens cet ordi comme autorisé à saisir les vols". Et de ce fait, OF placerait un cookie particulier côté ordi.

Je suis favorable à l'un (voir au deux) systèmes, car cela évite d'avoir à créer un programme (comme le sésameur). D'autant plus qu'on reste dans le cas d'une utilisation somme toute classique et par conséquent qui doit être ouverte à un maximum de configuration.

J'aimerais qu'on garde la philosophie : "installation logicielle <=> installation matérielle". (le <=> veut dire si et seulement si (vieux souvenirs... pff...).

Par contre pour la gestion des clés, du fait l'obligation d'avoir une interface logicielle pour dialoguer avec l'armoire, la sécurisation est plus élevée.

J'aime bien la 2° solution : menu admin -> cookie particulier. ça permet d'autoriser de façon simple plusieurs ordi : celui en libre service au club, mais aussi celui de la secrétaire, du trésorier chez lui, au moins deux postes qui auraient à accéder aux fonctions "Flights" (la liste est pas exhaustive)--[[User:Jdepardieu|Jdepardieu]] 17:53, 4 December 2005 (CET)

Cette deuxieme solution me plait aussi, mais pour identifier l'ordinateur qui est physiquement relié à l'armoire a clef, plutôt d'utiliser l'adresse ip je proposerais d'utiliser l'adresse mac de la carte reseau. Elle a l'avantage d'identifier de maniere unique la carte reseau, c'est une adresse qui ne peut etre changée. Une adresse ip peut changer à chaque connection, il faudrait donc verifier si l'adresse du pc relié a l'armoire et toujours la même que celle référencé dans la "table des autorisations".--Utopie 21:02, 4 December 2005 (CET)

== Table des tarifs ==

Pour la colonne type de vol, il faudrait pouvoir y mettre les types sérialisés, cela permettrait de créer des tarifs particulier pour des types cumulés (IFR en montagne) bien que je n'en vois pas trop l'utilité. Mais j'ai un problème : la double doit-elle être considérée comme un type de vol au sens défini plus haut. Auquel cas, faut créer ce type en plus des IFR, montagne, etc. Mais ça me gêne, car le gars peut très bien ne pas mettre double comme type de vol. Donc il faudrait trouver un système pour lier un type à certains paramêtres (présence d'un instructeur ici). Si vous avez une idée...

Sinon, pour les tarifs qui changent en fonction du type de vol, il y a une autre voie que la sérialisation dans le champ "type de vol" : faire l'addition des prix pour chaque type. Ainsi y'aurait un tarif de base (l'avion). Si on fait de la double, on rajoute x euros, si on fait de l'IFR, y euros. Mais le problème c'est que cela ne permet pas au club de faire des ristournes sur certains cumuls. Bref, je ne sais pas trop.

== Vérifications comptables ==
*Il serait bon de générer un N° de pièce comptable permettant d'identifier le mouvement (Vol/versement/transfert entre compte adhérents, ...) Cela permettra une validation plus simple également au trésorier, et un élément concret au membre qui vient de faire la saisie.
*D'autre part, si OF peut générer un fichier au format EBP/CIEL ou autre pour transfert vers le logiciel comptable, vous aurez une solution qui intéressera encore plus de clubs.....

A+

--[[User:Hthepaut|Hthepaut]] 18:12, 20 Jul 2005 (CEST)

*Concernant le N° de mouvement il est prévu dans la table [[Accounting_entry_Table]] par contre il n'était pas prévu de le rendre visible.

Pourriez-vous expliciter comment cela peut aider le trésorier ? (afin de concevoir une interface qui l'aide réellement ;-)

Pour le membre, je pensais qu'une date suffisait à tracer facilement une écriture.

*Pour l'export, c'est le but recherché (sinon cela ne sert à rien de faire de la gestion de comptes ;-)

--[[User:Claratte|Christophe]] 10:35, 21 Jul 2005 (CEST)

Le N° de pièce permettra une traçabilité du paiement entre le membre et le trésorier. ce N° peut être reporté sur le chèque lui-même ou tout autre support (enveloppe, ...) qui servira à faire parvenir le mode de paiement jusqu'entre les "mains" du trésorier.

Ce N° peut également servir ultérieurement lorsque nous aborderons les annulations de saisie de vol. Car il y aura des erreurs de saisie (c'est inévitable). Le gestionnaire pourra alors demander à supprimer directement le vol N°xxxx, et resaisir en lieu et place de l'adhérent tête en l'air...Si vous n'avez pas prévu cette fonctionnalité, pensez-y.

--[[User:Hthepaut|Hthepaut]] 16:51, 21 Jul 2005 (CEST)

Pour la traçabilité du paiement, on pense plutôt utiliser le numéro lié au paiement (PAYMENT_NUM qui se trouve dans la table [[Accounting_entry_Table]]). Ainsi si c'est un paiement par chèque, alors on renseigne le numéro de chèque (on peut également y mettre le nom de la banque). Au dos du chèque, j'ai plutôt l'habitude d'y voir figurer le numéro du compte du pilote.

Néanmoins, le fait de faire figurer le numéro de mouvement peut aider au rapprochement. Mais je ne suis pas sÃ»r que cela n'entrainera pas d'autres erreurs de rapprochement dues à la focalisation sur le pointage du mouvement et donc plus de vérification sur le montant ni sur le destinataire.

Concernant les vols, on a prévu la gestion des vols non saisis (vols oubliés). Pour l'annulation ou la modification de mauvaises saisies on s'oriente vers un mode "brouillard" qui permettrait à l'utilisateur (ou au gestionnaire) de modifier ses saisies jusqu'à une validation ultérieure.

L'avantage du mode brouillard par rapport à une saisie sans retour possible est double :

- limiter le nombre de champs à renseigner (puisqu'il y a facilement la possibilité de revenir en arrière) et de validations à effectuer (sur aéro21, c'est un peu lourd : faut valider sur F8 puis sur F4, ou l'inverse, je ne sais plus).

- permettre à l'utilisateur de modifier facilement a posteriori sa saisie ! (par exemple, une fois rentré chez lui, il se dit : zut ! j'ai oublié ceci ou cela...) ou a un gestionnaire de bas niveau (mécanicien, instructeur) de corriger facilement une saisie sans avoir à passer par un gestionnaire de niveau supérieur (secrétaire, trésorier).

Par contre, une fois que c'est validé, il n'y aura plus de modification possible.

== M. Mme Mlle ! ==

Je m'élève vigoureusement contre le projet d'enregistrer dans OF les potentialités matrimoniales des femmes, sans qu'il en soit de même pour les hommes.

Le fait d'indiquer, même sous couvert de pudeur, le statut matrimonial (Mme ou Mlle) d'une femme est une discrimination sexiste inacceptable.

Est-ce qu'il est prévu de faire de même pour les hommes . (Monsieur et Mondamoiseau ?).

J'ai l'air de rigoler en disant ça, mais je pense que le problème est sérieux, et même si ce n'est pas notre rôle de faire évoluer la société et ses pesanteurs, il serait bon que nous adoptions une attitude neutre de ce point de vue.

--[[User:Drpiquouze|drpiquouze]] 20:46, 11 August 2006 (CEST)

Discussion:OF2.0

2006-08-11T18:46:26Z

Drpiquouze : /* M. Mme Mlle ! */

== Et l'huile ?? ==

De la meme manière que l'on saisie l'avitaillement en essence, il faudrait prevoir la même chose pour l'huile

== Sémantique ==

Je ne sais pas où placer les rêgles de construction des noms pour les tables. De plus, il me semble qu'on en a déjà parlé sur le forum, mais où ?

--[[User:Claratte|Christophe]] 16:41, 8 Jun 2005 (CEST)

== Unités ==

Il va falloir choisir des unités pour le carburant (et l'huile ;-)

--[[User:Claratte|Christophe]] 16:41, 8 Jun 2005 (CEST)

A cause de l'internationalisation, il va faloir prevoir plusieurs unitées de mesures avec des tables de convertions, ce qui nous donne des litres, des imperials gallons des US gallons

L'autre possibilité c'est de se limiter aux litres qui est l'unité internationale des volumes ( en aviation aussi ?) --[[User:Scroses|Stéphane]]

Eh eh ! C'est plus compliqué que cela, il faut aussi prévoir des unités de poids. Je ne sais pas si c'est utilisé en aviation légère mais c'est utilisé dès qu'on se met à couler des quantités raisonnables et que parler en tonnes pour le carburant est courant. En fait, l'essencier coule toujours des litres (débitmètres) et facture en tant que tel, mais dans l'avion l'autonomie est déterminée en fonction du poids. En effet, 10.000 L ne font par le même poids (et donc la même "énergie") qu'il fasse moins -20°C ou +40°C (à cause de la dilatation).

Donc en fait, je me pose la question, s'il ne serait pas intéressant de donner la possibilité de saisir les quantités dans l'unité souhaitée, et de stocker l'unité en plus de la quantité. C'est un peu dans le même état d'esprit que pour les heures de vol : ainsi on ne souffre pas de problème d'arrondi. La quantité saisie est bien la quantitée enregistrée.--[[User:Claratte|Christophe]] 12:38, 10 Jun 2005 (CEST)

Ca a l'air tres compliqué tout ca d'autant plus que c'est pas dans un aeroclub on n'est pas prés de faire des plein de plusieurs tonnes de carburant.
Donc si comme tu le dis tous les débimetres du monde sont en litres, un fixe les litres comme unitée de mesure.
Et si jamais Air France désire utiliser OF pour sa flotte, on facturera un patch de pour avoir les mesures en tonnes --[[User:Scroses|Stéphane]]

Je l'attendais ;-)

Oui mais mon exemple perso veut dire qu'il y a peut-être d'autres systèmes dans d'autres endroits...--[[User:Claratte|Christophe]] 18:31, 10 Jun 2005 (CEST)

C'est sur que l'on peut trouver tout un tas de systeme de mesure des volumes "exotiques", mais quand tu fais le plein de ton airbus, tu demande a ton pompiste 1000 litres ou 700 tonnes de kero ? (je sais j'ai pas tenu compte de la temperature :-)

Donc je pense qu'il faudrais dans la partie admin du club specifier quelle est l'unite de mesure pour l'essence et l'huile. Par contre je serais pour le volume soit stocke dans la bdd en litre qui est l'unité de mesure internationale pour les volumes. Cela passera donc par une moulinette de convertion avant stockage dans la bdd

Voila quelques unites de mesures des volumes

1 Litre = 33.824 ounces = 1.0570 Quarts = 0.2642 Gallons = 0.2200 Imperial Gallons

--[[User:Scroses|Stéphane]]

Je demande à mon pompiste un volume dans l'unité utilisée par son pays (donc dans 99% des cas des litres mais pour info aux états-unis ils ne connaissent pas les litres).

Autant je pense qu'il est intéressant de se poser la question "à quel niveau bloque-t-on l'unité ?" (plein, avion ou club), autant dans tous les cas, je suis contre une conversion en litre qui amène une inexactitude dans le traitement de l'information. Je ne pense pas que raisonner en terme d'unité internationale soit la bonne tactique, c'est un peu comme dire aux asiatiques de laisser tomber leur langue pour passer à l'informatique, alors que justement l'informatique peut très bien s'adapter aux particularités. Si on dit que la quantité enregistrée est des galons, pourquoi convertir en litres ? A partir du moment ou OF aura l'info que c'est des galons, il pourra toujours proposer une conversion à posteriori.

Donc je propose plusieurs solutions. Soit :
*créer un champ dans la table club définissant l'unité de volume
*créer un champ dans la table avion définissant une unité de volume (pour chaque avion donc)
*créer un champ dans la table contenant les pleins pour indiquer l'unité utilisée pour faire le plein.

La dernière solution à ma préférence. Elle est très simple à mettre en oeuvre. Pour additionner les quantités, il suffit de faire une requête qui distribue les quantités dans des colonnes en fonction de l'unité utilisée, puis d'additionner les colonnes, de convertir le résultat de chaque colonne dans l'unité d'affichage souhaitée, et d'additionner les résultats.--[[User:Claratte|Christophe]] 18:38, 11 Jun 2005 (CEST)

== Bargraph de potentiel ==

Jusqu'à présent je ne comprenais pas pourquoi je trouvais la représentation en bargraph non intuitive (sauf lorsqu'on a compris ;-)

Cela vient, il me semble du fait que la jauge se vide (de la droite vers la gauche) plutot que de se remplir (de la gauche vers la droite)

Ou alors, il faudrait pour le potentiel utilisé mettre la couleur de fond pour bien montrer qu'il n'est plus là justement.

Bref, si l'idée du bargraph me parait excellente, je pense qu'il faudra éventuellement affiner la représentation pour qu'elle soit compréhensible du premier coup et sans explication. Sinon, je suis sÃ»r qu'il y aura des pilotes qui diront : "je croyais que".

Une autre méthode, consisterait en une couleur unique par barre, qui passerait du vert au rouge au fur et à mesure que le potentiel diminue.

Une autre chose, qui permettrait peut-être de mieux comprendre est de me mettre les barres verticales (plutot qu'horizontales) : cela correspondrait plus à une jauge d'essence, donc à un potentiel.

--[[User:Claratte|Christophe]] 16:40, 8 Jun 2005 (CEST)

== Ordinateur autorisé à saisir les vols ==

Joël avait écrit :

> Pour la convivialité dans le club je préférai que la page la plus souvent visible soit la page du planning de réservation. Ceci ne doit pas être le cas lors d'une connexion standard ou c'est celle du login + mdp qui doit apparaître

Tout à fait. Mais attention : il faut considérer que la saisie des heures de vols doit pouvoir fonctionner sans avoir à rajouter un module particulier côté club pour identifier l'ordinateur.
Or aujourd'hui, pour l'armoire à clé, c'est comme cela que nous envisageons les choses : avec un sésameur qui envoie un message à OF pour dire "je suis là, retiens mon adresse IP".
La question est : peut-on créer un système suffisamment fiable pour que l'ordi du club et lui seul soit reconnu comme ordinateur autorisé à saisir les vols ?
Je penche vers un système faiblement sécurisé à l'aide d'un simple login/mdp (comme pour le mode visiteur).
Pour que les gens ne le connaissent pas, il suffit que le gestionnaire du club crée avec le navigateur un bookmark avec enregistrement du login et du mdp.
Une autre solution consisterait à permettre au gestionnaire du club d'aller dans un menu spécial de l'admin pour dire : "retiens cet ordi comme autorisé à saisir les vols". Et de ce fait, OF placerait un cookie particulier côté ordi.

Je suis favorable à l'un (voir au deux) systèmes, car cela évite d'avoir à créer un programme (comme le sésameur). D'autant plus qu'on reste dans le cas d'une utilisation somme toute classique et par conséquent qui doit être ouverte à un maximum de configuration.

J'aimerais qu'on garde la philosophie : "installation logicielle <=> installation matérielle". (le <=> veut dire si et seulement si (vieux souvenirs... pff...).

Par contre pour la gestion des clés, du fait l'obligation d'avoir une interface logicielle pour dialoguer avec l'armoire, la sécurisation est plus élevée.

J'aime bien la 2° solution : menu admin -> cookie particulier. ça permet d'autoriser de façon simple plusieurs ordi : celui en libre service au club, mais aussi celui de la secrétaire, du trésorier chez lui, au moins deux postes qui auraient à accéder aux fonctions "Flights" (la liste est pas exhaustive)--[[User:Jdepardieu|Jdepardieu]] 17:53, 4 December 2005 (CET)

Cette deuxieme solution me plait aussi, mais pour identifier l'ordinateur qui est physiquement relié à l'armoire a clef, plutôt d'utiliser l'adresse ip je proposerais d'utiliser l'adresse mac de la carte reseau. Elle a l'avantage d'identifier de maniere unique la carte reseau, c'est une adresse qui ne peut etre changée. Une adresse ip peut changer à chaque connection, il faudrait donc verifier si l'adresse du pc relié a l'armoire et toujours la même que celle référencé dans la "table des autorisations".--Utopie 21:02, 4 December 2005 (CET)

== Table des tarifs ==

Pour la colonne type de vol, il faudrait pouvoir y mettre les types sérialisés, cela permettrait de créer des tarifs particulier pour des types cumulés (IFR en montagne) bien que je n'en vois pas trop l'utilité. Mais j'ai un problème : la double doit-elle être considérée comme un type de vol au sens défini plus haut. Auquel cas, faut créer ce type en plus des IFR, montagne, etc. Mais ça me gêne, car le gars peut très bien ne pas mettre double comme type de vol. Donc il faudrait trouver un système pour lier un type à certains paramêtres (présence d'un instructeur ici). Si vous avez une idée...

Sinon, pour les tarifs qui changent en fonction du type de vol, il y a une autre voie que la sérialisation dans le champ "type de vol" : faire l'addition des prix pour chaque type. Ainsi y'aurait un tarif de base (l'avion). Si on fait de la double, on rajoute x euros, si on fait de l'IFR, y euros. Mais le problème c'est que cela ne permet pas au club de faire des ristournes sur certains cumuls. Bref, je ne sais pas trop.

== Vérifications comptable ==
*Il serait bon de générer un N° de pièce comptable permettant d'identifier le mouvement (Vol/versement/transfert entre compte adhérents, ...) Cela permettra une validation plus simple également au trésorier, et un élément concret au membre qui vient de faire la saisie.
*D'autre part, si OF peut générer un fichier au format EBP/CIEL ou autre pour transfert vers le logiciel comptable, vous aurez une solution qui interressera encore plus de club.....

A+

--[[User:Hthepaut|Hthepaut]] 18:12, 20 Jul 2005 (CEST)

*Concernant le N° de mouvement il est prévu dans la table [[Accounting_entry_Table]] par contre il n'était pas prévu de le rendre visible.

Pourriez-vous expliciter comment cela peut aider le trésorier ? (afin de concevoir une interface qui l'aide réellement ;-)

Pour le membre, je pensais qu'une date suffisait à tracer facilement une écriture.

*Pour l'export, c'est le but recherché (sinon cela ne sert à rien de faire de la gestion de comptes ;-)

--[[User:Claratte|Christophe]] 10:35, 21 Jul 2005 (CEST)

Le N° de pièce permettra une traçabilité du paiement entre le membre et le trésorier. ce N° peut être reporté sur le chèque lui_même ou tout autre support (envelloppe, ...) qui servira à faire parvenir le mode de paiement jusqu'entre les "mains" du trésorier.

Ce N° peut également servir ultérieurement lorsque nous aborderons les annulations de saisie de vol. Car il y aura des erreurs de saisie (c'est inévitable). Le gestionnaire pourra alors demander à supprimer directement le vol N°xxxx, et resaisir en lieu et place de l'adhérent tête en l'air...Si vous n'avez pas prévu cette fonctionalité, pensez-y.

--[[User:Hthepaut|Hthepaut]] 16:51, 21 Jul 2005 (CEST)

Pour la tracabilité du paiement, on pense plutot utiliser le numéro lié au paiement (PAYMENT_NUM qui se trouve dans la table [[Accounting_entry_Table]]). Ainsi si c'est un paiement par chèque, alors on renseigne le numéro de chèque (on peut également y mettre le nom de la banque). Au dos du chèque, j'ai plutot l'habitude d'y voir figurer le numéro du compte du pilote.

Néanmoins, le fait de faire figurer le numéro de mouvement peut aider au rapprochement. Mais je ne suis pas sÃ»r que cela n'entrainera pas d'autres erreurs de rapprochement dues à la focalisation sur le pointage du mouvement et donc plus de vérification sur le montant ni sur le destinataire.

Concernant les vols, on a prévu la gestion des vols non saisis (vols oubliés). Pour l'annulation ou la modification de mauvaises saisies on s'oriente vers un mode "brouillard" qui permettrait à l'utilisateur (ou au gestionnaire) de modifier ses saisies jusqu'à une validation ultérieure.

L'avantage du mode brouillard par rapport à une saisie sans retour possible est double :

- limiter le nombre de champs à renseigner (puisqu'il y a facilement la possibilité de revenir en arrière) et de validations à effectuer (sur aéro21, c'est un peu lourd : faut valider sur F8 puis sur F4, ou l'inverse, je ne sais plus).

- permettre à l'utilisateur de modifier facilement a posteriori sa saisie ! (par exemple, une fois rentré chez lui, il se dit : zut ! j'ai oublié ceci ou cela...) ou a un gestionnaire de bas niveau (mécanicien, instructeur) de corriger facilement une saisie sans avoir à passer par un gestionnaire de niveau supérieur (secrétaire, trésorier).

Par contre, une fois que c'est validé, il n'y aura plus de modification possible.

== M. Mme Mlle ! ==

Je m'élève vigoureusement contre le projet d'enregistrer dans OF les potentialités matrimoniales des femmes, sans qu'il en soit de même pour les hommes.

Le fait d'indiquer, même sous couvert de pudeur, le statut matrimonial (Mme ou Mlle) d'une femme est une discrimination sexiste inacceptable.

Est-ce qu'il est prévu de faire de même pour les hommes . (Monsieur et Mondamoiseau ?).

J'ai l'air de rigoler en disant ça, mais je pense que le problème est sérieux, et même si ce n'est pas notre rôle de faire évoluer la société et ses pesanteurs, il serait bon que nous adoptions une attitude neutre de ce point de vue.

--[[User:Drpiquouze|drpiquouze]] 20:46, 11 August 2006 (CEST)

Discussion:OF2.0

2006-08-11T18:45:52Z

Drpiquouze : M. Mme Mlle !

== Et l'huile ?? ==

De la meme manière que l'on saisie l'avitaillement en essence, il faudrait prevoir la même chose pour l'huile

== Sémantique ==

Je ne sais pas où placer les rêgles de construction des noms pour les tables. De plus, il me semble qu'on en a déjà parlé sur le forum, mais où ?

--[[User:Claratte|Christophe]] 16:41, 8 Jun 2005 (CEST)

== Unités ==

Il va falloir choisir des unités pour le carburant (et l'huile ;-)

--[[User:Claratte|Christophe]] 16:41, 8 Jun 2005 (CEST)

A cause de l'internationalisation, il va faloir prevoir plusieurs unitées de mesures avec des tables de convertions, ce qui nous donne des litres, des imperials gallons des US gallons

L'autre possibilité c'est de se limiter aux litres qui est l'unité internationale des volumes ( en aviation aussi ?) --[[User:Scroses|Stéphane]]

Eh eh ! C'est plus compliqué que cela, il faut aussi prévoir des unités de poids. Je ne sais pas si c'est utilisé en aviation légère mais c'est utilisé dès qu'on se met à couler des quantités raisonnables et que parler en tonnes pour le carburant est courant. En fait, l'essencier coule toujours des litres (débitmètres) et facture en tant que tel, mais dans l'avion l'autonomie est déterminée en fonction du poids. En effet, 10.000 L ne font par le même poids (et donc la même "énergie") qu'il fasse moins -20°C ou +40°C (à cause de la dilatation).

Donc en fait, je me pose la question, s'il ne serait pas intéressant de donner la possibilité de saisir les quantités dans l'unité souhaitée, et de stocker l'unité en plus de la quantité. C'est un peu dans le même état d'esprit que pour les heures de vol : ainsi on ne souffre pas de problème d'arrondi. La quantité saisie est bien la quantitée enregistrée.--[[User:Claratte|Christophe]] 12:38, 10 Jun 2005 (CEST)

Ca a l'air tres compliqué tout ca d'autant plus que c'est pas dans un aeroclub on n'est pas prés de faire des plein de plusieurs tonnes de carburant.
Donc si comme tu le dis tous les débimetres du monde sont en litres, un fixe les litres comme unitée de mesure.
Et si jamais Air France désire utiliser OF pour sa flotte, on facturera un patch de pour avoir les mesures en tonnes --[[User:Scroses|Stéphane]]

Je l'attendais ;-)

Oui mais mon exemple perso veut dire qu'il y a peut-être d'autres systèmes dans d'autres endroits...--[[User:Claratte|Christophe]] 18:31, 10 Jun 2005 (CEST)

C'est sur que l'on peut trouver tout un tas de systeme de mesure des volumes "exotiques", mais quand tu fais le plein de ton airbus, tu demande a ton pompiste 1000 litres ou 700 tonnes de kero ? (je sais j'ai pas tenu compte de la temperature :-)

Donc je pense qu'il faudrais dans la partie admin du club specifier quelle est l'unite de mesure pour l'essence et l'huile. Par contre je serais pour le volume soit stocke dans la bdd en litre qui est l'unité de mesure internationale pour les volumes. Cela passera donc par une moulinette de convertion avant stockage dans la bdd

Voila quelques unites de mesures des volumes

1 Litre = 33.824 ounces = 1.0570 Quarts = 0.2642 Gallons = 0.2200 Imperial Gallons

--[[User:Scroses|Stéphane]]

Je demande à mon pompiste un volume dans l'unité utilisée par son pays (donc dans 99% des cas des litres mais pour info aux états-unis ils ne connaissent pas les litres).

Autant je pense qu'il est intéressant de se poser la question "à quel niveau bloque-t-on l'unité ?" (plein, avion ou club), autant dans tous les cas, je suis contre une conversion en litre qui amène une inexactitude dans le traitement de l'information. Je ne pense pas que raisonner en terme d'unité internationale soit la bonne tactique, c'est un peu comme dire aux asiatiques de laisser tomber leur langue pour passer à l'informatique, alors que justement l'informatique peut très bien s'adapter aux particularités. Si on dit que la quantité enregistrée est des galons, pourquoi convertir en litres ? A partir du moment ou OF aura l'info que c'est des galons, il pourra toujours proposer une conversion à posteriori.

Donc je propose plusieurs solutions. Soit :
*créer un champ dans la table club définissant l'unité de volume
*créer un champ dans la table avion définissant une unité de volume (pour chaque avion donc)
*créer un champ dans la table contenant les pleins pour indiquer l'unité utilisée pour faire le plein.

La dernière solution à ma préférence. Elle est très simple à mettre en oeuvre. Pour additionner les quantités, il suffit de faire une requête qui distribue les quantités dans des colonnes en fonction de l'unité utilisée, puis d'additionner les colonnes, de convertir le résultat de chaque colonne dans l'unité d'affichage souhaitée, et d'additionner les résultats.--[[User:Claratte|Christophe]] 18:38, 11 Jun 2005 (CEST)

== Bargraph de potentiel ==

Jusqu'à présent je ne comprenais pas pourquoi je trouvais la représentation en bargraph non intuitive (sauf lorsqu'on a compris ;-)

Cela vient, il me semble du fait que la jauge se vide (de la droite vers la gauche) plutot que de se remplir (de la gauche vers la droite)

Ou alors, il faudrait pour le potentiel utilisé mettre la couleur de fond pour bien montrer qu'il n'est plus là justement.

Bref, si l'idée du bargraph me parait excellente, je pense qu'il faudra éventuellement affiner la représentation pour qu'elle soit compréhensible du premier coup et sans explication. Sinon, je suis sÃ»r qu'il y aura des pilotes qui diront : "je croyais que".

Une autre méthode, consisterait en une couleur unique par barre, qui passerait du vert au rouge au fur et à mesure que le potentiel diminue.

Une autre chose, qui permettrait peut-être de mieux comprendre est de me mettre les barres verticales (plutot qu'horizontales) : cela correspondrait plus à une jauge d'essence, donc à un potentiel.

--[[User:Claratte|Christophe]] 16:40, 8 Jun 2005 (CEST)

== Ordinateur autorisé à saisir les vols ==

Joël avait écrit :

> Pour la convivialité dans le club je préférai que la page la plus souvent visible soit la page du planning de réservation. Ceci ne doit pas être le cas lors d'une connexion standard ou c'est celle du login + mdp qui doit apparaître

Tout à fait. Mais attention : il faut considérer que la saisie des heures de vols doit pouvoir fonctionner sans avoir à rajouter un module particulier côté club pour identifier l'ordinateur.
Or aujourd'hui, pour l'armoire à clé, c'est comme cela que nous envisageons les choses : avec un sésameur qui envoie un message à OF pour dire "je suis là, retiens mon adresse IP".
La question est : peut-on créer un système suffisamment fiable pour que l'ordi du club et lui seul soit reconnu comme ordinateur autorisé à saisir les vols ?
Je penche vers un système faiblement sécurisé à l'aide d'un simple login/mdp (comme pour le mode visiteur).
Pour que les gens ne le connaissent pas, il suffit que le gestionnaire du club crée avec le navigateur un bookmark avec enregistrement du login et du mdp.
Une autre solution consisterait à permettre au gestionnaire du club d'aller dans un menu spécial de l'admin pour dire : "retiens cet ordi comme autorisé à saisir les vols". Et de ce fait, OF placerait un cookie particulier côté ordi.

Je suis favorable à l'un (voir au deux) systèmes, car cela évite d'avoir à créer un programme (comme le sésameur). D'autant plus qu'on reste dans le cas d'une utilisation somme toute classique et par conséquent qui doit être ouverte à un maximum de configuration.

J'aimerais qu'on garde la philosophie : "installation logicielle <=> installation matérielle". (le <=> veut dire si et seulement si (vieux souvenirs... pff...).

Par contre pour la gestion des clés, du fait l'obligation d'avoir une interface logicielle pour dialoguer avec l'armoire, la sécurisation est plus élevée.

J'aime bien la 2° solution : menu admin -> cookie particulier. ça permet d'autoriser de façon simple plusieurs ordi : celui en libre service au club, mais aussi celui de la secrétaire, du trésorier chez lui, au moins deux postes qui auraient à accéder aux fonctions "Flights" (la liste est pas exhaustive)--[[User:Jdepardieu|Jdepardieu]] 17:53, 4 December 2005 (CET)

Cette deuxieme solution me plait aussi, mais pour identifier l'ordinateur qui est physiquement relié à l'armoire a clef, plutôt d'utiliser l'adresse ip je proposerais d'utiliser l'adresse mac de la carte reseau. Elle a l'avantage d'identifier de maniere unique la carte reseau, c'est une adresse qui ne peut etre changée. Une adresse ip peut changer à chaque connection, il faudrait donc verifier si l'adresse du pc relié a l'armoire et toujours la même que celle référencé dans la "table des autorisations".--Utopie 21:02, 4 December 2005 (CET)

== Table des tarifs ==

Pour la colonne type de vol, il faudrait pouvoir y mettre les types sérialisés, cela permettrait de créer des tarifs particulier pour des types cumulés (IFR en montagne) bien que je n'en vois pas trop l'utilité. Mais j'ai un problème : la double doit-elle être considérée comme un type de vol au sens défini plus haut. Auquel cas, faut créer ce type en plus des IFR, montagne, etc. Mais ça me gêne, car le gars peut très bien ne pas mettre double comme type de vol. Donc il faudrait trouver un système pour lier un type à certains paramêtres (présence d'un instructeur ici). Si vous avez une idée...

Sinon, pour les tarifs qui changent en fonction du type de vol, il y a une autre voie que la sérialisation dans le champ "type de vol" : faire l'addition des prix pour chaque type. Ainsi y'aurait un tarif de base (l'avion). Si on fait de la double, on rajoute x euros, si on fait de l'IFR, y euros. Mais le problème c'est que cela ne permet pas au club de faire des ristournes sur certains cumuls. Bref, je ne sais pas trop.

== Vérifications comptable ==
*Il serait bon de générer un N° de pièce comptable permettant d'identifier le mouvement (Vol/versement/transfert entre compte adhérents, ...) Cela permettra une validation plus simple également au trésorier, et un élément concret au membre qui vient de faire la saisie.
*D'autre part, si OF peut générer un fichier au format EBP/CIEL ou autre pour transfert vers le logiciel comptable, vous aurez une solution qui interressera encore plus de club.....

A+

--[[User:Hthepaut|Hthepaut]] 18:12, 20 Jul 2005 (CEST)

*Concernant le N° de mouvement il est prévu dans la table [[Accounting_entry_Table]] par contre il n'était pas prévu de le rendre visible.

Pourriez-vous expliciter comment cela peut aider le trésorier ? (afin de concevoir une interface qui l'aide réellement ;-)

Pour le membre, je pensais qu'une date suffisait à tracer facilement une écriture.

*Pour l'export, c'est le but recherché (sinon cela ne sert à rien de faire de la gestion de comptes ;-)

--[[User:Claratte|Christophe]] 10:35, 21 Jul 2005 (CEST)

Le N° de pièce permettra une traçabilité du paiement entre le membre et le trésorier. ce N° peut être reporté sur le chèque lui_même ou tout autre support (envelloppe, ...) qui servira à faire parvenir le mode de paiement jusqu'entre les "mains" du trésorier.

Ce N° peut également servir ultérieurement lorsque nous aborderons les annulations de saisie de vol. Car il y aura des erreurs de saisie (c'est inévitable). Le gestionnaire pourra alors demander à supprimer directement le vol N°xxxx, et resaisir en lieu et place de l'adhérent tête en l'air...Si vous n'avez pas prévu cette fonctionalité, pensez-y.

--[[User:Hthepaut|Hthepaut]] 16:51, 21 Jul 2005 (CEST)

Pour la tracabilité du paiement, on pense plutot utiliser le numéro lié au paiement (PAYMENT_NUM qui se trouve dans la table [[Accounting_entry_Table]]). Ainsi si c'est un paiement par chèque, alors on renseigne le numéro de chèque (on peut également y mettre le nom de la banque). Au dos du chèque, j'ai plutot l'habitude d'y voir figurer le numéro du compte du pilote.

Néanmoins, le fait de faire figurer le numéro de mouvement peut aider au rapprochement. Mais je ne suis pas sÃ»r que cela n'entrainera pas d'autres erreurs de rapprochement dues à la focalisation sur le pointage du mouvement et donc plus de vérification sur le montant ni sur le destinataire.

Concernant les vols, on a prévu la gestion des vols non saisis (vols oubliés). Pour l'annulation ou la modification de mauvaises saisies on s'oriente vers un mode "brouillard" qui permettrait à l'utilisateur (ou au gestionnaire) de modifier ses saisies jusqu'à une validation ultérieure.

L'avantage du mode brouillard par rapport à une saisie sans retour possible est double :

- limiter le nombre de champs à renseigner (puisqu'il y a facilement la possibilité de revenir en arrière) et de validations à effectuer (sur aéro21, c'est un peu lourd : faut valider sur F8 puis sur F4, ou l'inverse, je ne sais plus).

- permettre à l'utilisateur de modifier facilement a posteriori sa saisie ! (par exemple, une fois rentré chez lui, il se dit : zut ! j'ai oublié ceci ou cela...) ou a un gestionnaire de bas niveau (mécanicien, instructeur) de corriger facilement une saisie sans avoir à passer par un gestionnaire de niveau supérieur (secrétaire, trésorier).

Par contre, une fois que c'est validé, il n'y aura plus de modification possible.

== M. Mme Mlle ! ==

Je m'élève vigoureusement contre le projet d'enregistrer dans OF les potentialités matrimoniales des femmes, sans qu'il en soit de même pour les hommes.

Le fait d'indiquer, même sous couvert de pudeur, le statut matrimonial (Mme ou Mlle) d'une femme est une discrimination sexiste inacceptable.

Est-ce qu'il est prévu de faire de même pour les hommes . (Monsieur et Mondamoiseau ?).

J'ai l'air de rigoler en disant ça, mais je pense que le problème est sérieux, et même si ce n'est pas notre rôle de faire évoluer la société et ses pesanteurs, il serait bon que nous adoptions une attitude neutre de ce point de vue.

Kiosque PC

2006-04-17T14:13:15Z

Drpiquouze : /* Solution Mac */

Documentation_de_la_solution_web_de_gestion_OpenFlyers_version_3:About

2006-04-17T14:00:46Z

Drpiquouze : /* Votes */

=Structuration d'OpenFlyers=
Comme indiqué sur le [http://openflyers.org site internet d'OpenFlyers], OpenFlyers correspond à deux choses :
*l'association OpenFlyers
*le logiciel OpenFlyers (qui est créé par l'équipe de développement qui n'est pas interne à l'association)

L'association met à disposition de l'équipe de développement des moyens pour assurer son fonctionnement.
==Outils de développement==
===Wiki===
Ce wiki est utilisé par l'équipe de développement. C'est d'ailleurs son principal outil de travail.

L'édition de la plupart des pages wiki est libre. Il suffit simplement de s'être identifié avant de pouvoir poster. Pour cela '''il faut demander un accès (en précisant idenfiant et mot de passe souhaité) à devteam at openflyers.org'''

Néanmoins, cette liberté totale ne peut "s'épanouir" qu'avec quelques règles permettant à tout un chacun de suivre le plus facilement possible les évolutions des pages du wiki.

Voici donc quelques propositions de règles à respecter :
*N'hésitez-pas à éditer les pages pour corriger les fautes d'orthographe.
*Si vous souhaitez améliorer la mise en page, faites attention de bien vérifier au préalable que toute modification sur les titres ne va pas causer de liens morts.
*'''Si vous souhaitez rajouter une remarque sur une spec déjà rédigée, utilisez de préférence l'onglet "discussion" rattaché à la page.'''
*Lorsque vous soulevez plusieurs points, utilisez :
**soit des * pour créer des puces comme ici (<-là, juste à gauche<-)
**soit des titres différents à l'aide des == si vous considérez que cela méritera des réponses séparées pour chaque thème soulevé.
*N'oubliez-pas de signer à la fin de votre paragraphe en utilisant l'icône prévue à cet effet (avant dernière icône en partant de la droite au-dessus du formulaire d'édition).

'''Pour suivre les modifications du wiki, c'est ici : [[Special:Recentchanges|modifs]]'''

===Listes de diffusion===
*devteam@openflyers.org (pour l'ensemble de l'équipe de développement)
*beta@openflyers.org (pour les béta-testeurs)
*coding@openflyers.org (pour les programmeurs)
*of-commit@openflyers.org (pour le suivi des mises à jour du SVN)
Si vous souhaitez intégrer l'équipe de développement et être abonné à une des listes, il faut en faire la demande auprès du responsable de l'équipe : devteam@openflyers.org
===SVN (subversion)===

==Organisation du développement==
Nous essayons de structurer le développement afin d'être plus efficace et de ne pas perdre des choses en route. Le schéma présenté ci-après correspond plus à un idéal qu'une réalité ;-)
===Spécifications===
Il existe trois niveaux de spécifications :
*Les idées générales (cahier de résa, gestion des comptes, mécanique, etc.).

Les idées générales sont présentées synthétiquement sur la [http://openflyers.org/articles.php?lng=fr&pg=7 roue OpenFlyers]. Elles regroupent les axes de développement validés depuis la création d'OF. Les priorités de spécifications sur tel ou tel axe sont définies par l'ensemble de l'équipe. ''A l'heure actuelle, le cahier est fait, la gestion des adhérents est également terminée et nous spécifions sur la saisie des vols et la gestion des comptes pilotes.''
*La composition générale de chaque axe est décrite au travers de notions (types d'avion, profils, etc.).

La détermination des notions est, en général, laissée plutôt à l'appréciation de l'équipe de programmation. Car c'est elle qui va par la suite implémenter ces notions et qui peut mesurer la difficulté de tel ou tel aspect. De plus, les utilisateurs finaux ne sont pas forcément les mieux placés pour appréhender les différentes utilisations possibles. Ils cherchent en général une solution qui correspond uniquement à leur besoin.
*Les fonctionnalités.
Elles sont déterminées par l'ensemble de l'équipe de développement.

Le wiki constitue le support pour décrire les fonctionnalités et les notions.

A côté de ces spécifications "fonctionnelles", il existe des spécifications de programmation. Elles sont du ressort de l'équipe de programmation. L'axe suivi est : respect des standards et modularité.

===Implémentation des spécifications===
L'implémentation est effectuée par l'équipe de programmation dans les languages PHP, JavaScript, XHTML, XML, XSLT et avec comme support de base de données MySQL.

Le choix des fonctionnalités à implémenter est décidé de deux manières :
*S'il s'agit du coeur d'une idée, elle est implémentée dans le cadre de l'idée.
*S'il s'agit d'une fonctionnalité annexe, cette dernière est votée lors de réunions de l'association avec l'équipe de programmation.

Certaines fonctionnalités qui ne nécessitent qu'un très faible investissement en temps peuvent être laissées à l'appréciation de tel ou tel programmeur à partir du moment où elles s'insèrent dans le cadre voulu et qu'elles ne dénaturent pas l'application.

Afin de faciliter l'implémentation de fonctionnalités annexes, la version 2 d'OF utilisera un système de listage en xml regroupant les options activables par un club.

===Votes===
Afin de répondre mieux aux attentes des clubs et des utilisateurs, nous envisageons de mettre en place un système de vote. La recherche d'un tel outil fait parti des tâches en suspens (s'il y a un volontaire...). Succinctement, voici des éléments qui pourraient composer le cahier des charges d'un tel outil :
*authentification des votants et attribution du droit à voter (but : éviter qu'une même personne ne vote deux fois).
*Pondération des votes (but: donner plus de poids aux développeurs, programmeurs, clubs hébergés par l'association).
*système de gestion des spécifications futures avec :
**possibilité de vote
**ajout par tout un chacun de nouvelles specs
**classement thématique des specs

Kiosque PC

2006-04-17T03:54:46Z

Drpiquouze : /* Solution Mac */

Kiosque PC

2006-04-16T18:54:39Z

Drpiquouze : /* Solution Mac */

Kiosque PC

2006-04-16T18:51:53Z

Drpiquouze : /* Solutions Mac */

Kiosque PC

2006-04-16T18:27:20Z

Drpiquouze : /* Solution Mac */

Kiosque PC

2006-04-16T18:04:53Z

Drpiquouze : /* Solution Mac */

Kiosque PC

2006-04-16T18:02:56Z

Drpiquouze : /* Solution Mac */

Kiosque PC

2006-04-16T18:01:15Z

Drpiquouze : /* Solution Mac */

Kiosque PC

2006-04-16T17:57:34Z

Drpiquouze : /* Solution Mac */

=Introduction=
Le but de cette page est de référencer et de proposer des solutions de configuration pour les ordinateurs en accès public, dans les aéro-clubs par exemple.
=Solution Mac=
Je viens juste de terminer la configuration d'un iMac G3 (ordinateur tout en un) auquel j'ai enlevé le lecteur de DVD, pour éviter les redémarrages sur un disque système, et sur lequel j'ai installé iCab, qui possède un mode kiosque très intéressant (Outils, Mode public), protégé par un mot de passe, et dans lequel ni le Dock de Mac Os X, ni la barre de menu n'apparaissent.
J'avais testé auparavant Opéra, dont le mode kiosque a un affichage complètement perturbé. Malheureusement, iCab n'existe pas sous Windows.

Pour arriver directement sur la page de réservation, j'ai créé un script en applescript, qui démarre automatiquement iCab en ouverture de session, en mode kiosque, et avec l'identifiant et le mot de passe d'un utilisateur sans aucun droit, ce qui permet à la page de réservation de rester affichée et de se réactualiser régulièrement.

:tell application "iCab"
::Activate
::enter kiosk mode with password "password"

-- le mot de passe qui permettra de sortir du mode kiosque avec le raccourci [Commande-k]

::OpenURL "http://monsite.org/?login=monidentifiant&password=monmotdepasse" toWindow -1

-- ouvre la page en question dans iCab et au premier plan, en introduisant identifiant et MdP de l'utilisateur sans droits

:end tell

J'ai supprimé toutes les barres d'affichage : Adresse, Barre d'état, Signets, Liens standards.

Il est néanmoins nécessaire dans le mode kiosque de garder la barre de navigation, pour relancer le navigateur lors des pertes de connexion.

Comme il est possible de n'autoriser la connexion qu'à un ou plusieurs sites nommément désignés par un système de filtres, il est très facile de bloquer le navigateur sur OF.

Bien entendu, ce mode kiosque doit être lancé depuis une session d'un utilisateur lancée sans mot de passe (permet les ouvertures et extinctions automatiques la nuit), utilisateur qui n'a aucun droit de gestion sur l'ordinateur et qui travaille sur un Finder restreint.

--[[User:Drpiquouze|drpiquouze]] 19:49, 16 April 2006 (CEST)

Kiosque PC

2006-04-16T17:49:58Z

Drpiquouze : /* Solution Mac */

=Introduction=
Le but de cette page est de référencer et de proposer des solutions de configuration pour les ordinateurs en accès public, dans les aéro-clubs par exemple.
=Solution Mac=
Je viens juste de terminer la configuration d'un iMac G3 (ordinateur tout en un) auquel j'ai enlevé le lecteur de DVD, pour éviter les redémarrages sur un disque système, et sur lequel j'ai installé iCab, qui possède un mode kiosque très intéressant (Outils, Mode public), protégé par un mot de passe, et dans lequel ni le Dock de Mac Os X, ni la barre de menu n'apparaissent.
J'avais testé auparavant Opéra, dont le mode kiosque a un affichage complètement perturbé. Malheureusement, iCab n'existe pas sous Windows.

Pour arriver directement sur la page de réservation, j'ai créé un script en applescript, qui démarre automatiquement iCab en ouverture de session, en mode kiosque, et avec l'identifiant et le mot de passe d'un utilisateur sans aucun droit, ce qui permet à la page de réservation de rester affichée et de se réactualiser régulièrement.

<nowiki>tell application "iCab"
Activate
enter kiosk mode with password "password"

-- le mot de passe qui permettra de sortir du mode kiosque avec le raccourci [Commande-k]

OpenURL "http://monsite.org/?login=monidentifiant&password=monmotdepasse" toWindow -1

-- ouvre la page en question dans iCab et au premier plan, en introduisant identifiant et MdP de l'utilisateur sans droits

end tell</nowiki>

J'ai supprimé toutes les barres d'affichage : Adresse, Barre d'état, Signets, Liens standards.

Il est néanmoins nécessaire dans le mode kiosque de garder la barre de navigation, pour relancer le navigateur lors des pertes de connexion.

Comme il est possible de n'autoriser la connexion qu'à un ou plusieurs sites nommément désignés par un système de filtres, il est très facile de bloquer le navigateur sur OF.

Bien entendu, ce mode kiosque doit être lancé depuis une session d'un utilisateur lancée sans mot de passe (permet les ouvertures et extinctions automatiques la nuit), utilisateur qui n'a aucun droit de gestion sur l'ordinateur et qui travaille sur un Finder restreint.

--[[User:Drpiquouze|drpiquouze]] 19:49, 16 April 2006 (CEST)

Kiosque PC

2006-04-16T17:49:13Z

Drpiquouze : /* Solution Mac */

=Introduction=
Le but de cette page est de référencer et de proposer des solutions de configuration pour les ordinateurs en accès public, dans les aéro-clubs par exemple.
=Solution Mac=
Je viens juste de terminer la configuration d'un iMac G3 (ordinateur tout en un) auquel j'ai enlevé le lecteur de DVD, pour éviter les redémarrages sur un disque système, et sur lequel j'ai installé iCab, qui possède un mode kiosque très intéressant (Outils, Mode public), protégé par un mot de passe, et dans lequel ni le Dock de Mac Os X, ni la barre de menu n'apparaissent.
J'avais testé auparavant Opéra, dont le mode kiosque a un affichage complètement perturbé. Malheureusement, iCab n'existe pas sous Windows.

Pour arriver directement sur la page de réservation, j'ai créé un script en applescript, qui démarre automatiquement iCab en ouverture de session, en mode kiosque, et avec l'identifiant et le mot de passe d'un utilisateur sans aucun droit, ce qui permet à la page de réservation de rester affichée et de se réactualiser régulièrement.

tell application "iCab"
Activate
enter kiosk mode with password "password"

-- le mot de passe qui permettra de sortir du mode kiosque avec le raccourci [Commande-k]

OpenURL "http://monsite.org/?login=monidentifiant&password=monmotdepasse" toWindow -1

-- ouvre la page en question dans iCab et au premier plan, en introduisant identifiant et MdP de l'utilisateur sans droits

end tell

J'ai supprimé toutes les barres d'affichage : Adresse, Barre d'état, Signets, Liens standards.

Il est néanmoins nécessaire dans le mode kiosque de garder la barre de navigation, pour relancer le navigateur lors des pertes de connexion.

Comme il est possible de n'autoriser la connexion qu'à un ou plusieurs sites nommément désignés par un système de filtres, il est très facile de bloquer le navigateur sur OF.

Bien entendu, ce mode kiosque doit être lancé depuis une session d'un utilisateur lancée sans mot de passe (permet les ouvertures et extinctions automatiques la nuit), utilisateur qui n'a aucun droit de gestion sur l'ordinateur et qui travaille sur un Finder restreint.

--[[User:Drpiquouze|drpiquouze]] 19:49, 16 April 2006 (CEST)

Utilisateur:Drpiquouze

2006-04-15T18:56:44Z

Drpiquouze :

Bonjour,

Je suis Denis Rousseaux, médecin anesthésiste (d'où le pseudo ;-) ).
En tant que webmestre du site de mon aéroclub, l''''aéroclub du sud E. Adam de Villiers''', à La Réunion, ''L'aéroclub français de l'hémisphère sud le plus proche de l'antarctique !'', je me suis intéressé à Openflyers récemment. Comme je suis un maniaque de l'orthographe, je me propose de corriger tout ce qui passera à ma portée.

Discussion_Documentation_de_la_solution_web_de_gestion_OpenFlyers_version_3:About

2006-04-11T18:35:04Z

Drpiquouze :

système d'édition des spécifications faisant l'objet d'un vote permettant à tout un chacun d'en rajouter de nouveaux.

J'imagine que l'auteur parle des spécifications (mais ce n'est pas très clair) auquel cas il faudrait parler de Â« nouvelles Â» spécifications !

--[[User:Drpiquouze|drpiquouze]] 20:34, 11 April 2006 (CEST)

Discussion_Documentation_de_la_solution_web_de_gestion_OpenFlyers_version_3:About

2006-04-11T18:34:41Z

Drpiquouze :

système d'édition des spécifications faisant l'objet d'un vote permettant à tout un chacun d'en rajouter de nouveaux.

J'imagine que l'auteur parle des spécifications (mais ce n'est pas très clair) uquel cas il faudrait parler de Â« nouvelles Â» spécifications !

--[[User:Drpiquouze|drpiquouze]] 20:34, 11 April 2006 (CEST)

Documentation_de_la_solution_web_de_gestion_OpenFlyers_version_3:About

2006-04-11T18:31:28Z

Drpiquouze : /* Votes */

=Structuration d'OpenFlyers=
Comme indiqué sur le [http://openflyers.org site internet d'OpenFlyers], OpenFlyers correspond à deux choses :
*l'association OpenFlyers
*le logiciel OpenFlyers (qui est créé par l'équipe de développement qui n'est pas interne à l'association)

L'association met à disposition de l'équipe de développement des moyens pour assurer son fonctionnement.
==Outils de développement==
===Wiki===
Ce wiki est utilisé par l'équipe de développement. C'est d'ailleurs son principal outil de travail.

L'édition de la plupart des pages wiki est libre. Il suffit simplement de s'être identifié avant de pouvoir poster. Pour cela '''il faut demander un accès (en précisant idenfiant et mot de passe souhaité) à devteam at openflyers.org'''

Néanmoins, cette liberté totale ne peut "s'épanouir" qu'avec quelques règles permettant à tout un chacun de suivre le plus facilement possible les évolutions des pages du wiki.

Voici donc quelques propositions de règles à respecter :
*N'hésitez-pas à éditer les pages pour corriger les fautes d'orthographe.
*Si vous souhaitez améliorer la mise en page, faites attention de bien vérifier au préalable que toute modification sur les titres ne va pas causer de liens morts.
*'''Si vous souhaitez rajouter une remarque sur une spec déjà rédigée, utilisez de préférence l'onglet "discussion" rattaché à la page.'''
*Lorsque vous soulevez plusieurs points, utilisez :
**soit des * pour créer des puces comme ici (<-là, juste à gauche<-)
**soit des titres différents à l'aide des == si vous considérez que cela méritera des réponses séparées pour chaque thème soulevé.
*N'oubliez-pas de signer à la fin de votre paragraphe en utilisant l'icône prévue à cet effet (avant dernière icône en partant de la droite au-dessus du formulaire d'édition).

'''Pour suivre les modifications du wiki, c'est ici : [[Special:Recentchanges|modifs]]'''

===Listes de diffusion===
*devteam@openflyers.org (pour l'ensemble de l'équipe de développement)
*beta@openflyers.org (pour les béta-testeurs)
*coding@openflyers.org (pour les programmeurs)
*of-commit@openflyers.org (pour le suivi des mises à jour du SVN)
Si vous souhaitez intégrer l'équipe de développement et être abonné à une des listes, il faut en faire la demande auprès du responsable de l'équipe : devteam@openflyers.org
===SVN (subversion)===

==Organisation du développement==
Nous essayons de structurer le développement afin d'être plus efficace et de ne pas perdre des choses en route. Le schéma présenté ci-après correspond plus à un idéal qu'une réalité ;-)
===Spécifications===
Il existe trois niveaux de spécifications :
*Les idées générales (cahier de résa, gestion des comptes, mécanique, etc.).

Les idées générales sont présentées synthétiquement sur la [http://openflyers.org/articles.php?lng=fr&pg=7 roue OpenFlyers]. Elles regroupent les axes de développement validés depuis la création d'OF. Les priorités de spécifications sur tel ou tel axe sont définies par l'ensemble de l'équipe. ''A l'heure actuelle, le cahier est fait, la gestion des adhérents est également terminée et nous spécifions sur la saisie des vols et la gestion des comptes pilotes.''
*La composition générale de chaque axe est décrite au travers de notions (types d'avion, profils, etc.).

La détermination des notions est, en général, laissée plutôt à l'appréciation de l'équipe de programmation. Car c'est elle qui va par la suite implémenter ces notions et qui peut mesurer la difficulté de tel ou tel aspect. De plus, les utilisateurs finaux ne sont pas forcément les mieux placés pour appréhender les différentes utilisations possibles. Ils cherchent en général une solution qui correspond uniquement à leur besoin.
*Les fonctionnalités.
Elles sont déterminées par l'ensemble de l'équipe de développement.

Le wiki constitue le support pour décrire les fonctionnalités et les notions.

A côté de ces spécifications "fonctionnelles", il existe des spécifications de programmation. Elles sont du ressort de l'équipe de programmation. L'axe suivi est : respect des standards et modularité.

===Implémentation des spécifications===
L'implémentation est effectuée par l'équipe de programmation dans les languages PHP, JavaScript, XHTML, XML, XSLT et avec comme support de base de données MySQL.

Le choix des fonctionnalités à implémenter est décidé de deux manières :
*S'il s'agit du coeur d'une idée, elle est implémentée dans le cadre de l'idée.
*S'il s'agit d'une fonctionnalité annexe, cette dernière est votée lors de réunions de l'association avec l'équipe de programmation.

Certaines fonctionnalités qui ne nécessitent qu'un très faible investissement en temps peuvent être laissées à l'appréciation de tel ou tel programmeur à partir du moment où elles s'insèrent dans le cadre voulu et qu'elles ne dénaturent pas l'application.

Afin de faciliter l'implémentation de fonctionnalités annexes, la version 2 d'OF utilisera un système de listage en xml regroupant les options activables par un club.

===Votes===
Afin de répondre mieux aux attentes des clubs et des utilisateurs, nous envisageons de mettre en place un système de vote. La recherche d'un tel outil fait parti des tâches en suspend (s'il y a un volontaire...). Succinctement, voici des éléments qui pourraient composer le cahier des charges d'un tel outil :
*authentification des votants et attribution du droit à voter (but : éviter qu'un même personne vote deux fois).
*Pondération des votes (but: donner plus de poids aux développeurs, programmeurs, clubs hébergés par l'association).
*système d'édition des spécifications faisant l'objet d'un vote permettant à tout un chacun d'en rajouter de nouveaux.

Documentation_de_la_solution_web_de_gestion_OpenFlyers_version_3:About

2006-04-11T18:30:04Z

Drpiquouze : /* Implémentation des spécifications */

=Structuration d'OpenFlyers=
Comme indiqué sur le [http://openflyers.org site internet d'OpenFlyers], OpenFlyers correspond à deux choses :
*l'association OpenFlyers
*le logiciel OpenFlyers (qui est créé par l'équipe de développement qui n'est pas interne à l'association)

L'association met à disposition de l'équipe de développement des moyens pour assurer son fonctionnement.
==Outils de développement==
===Wiki===
Ce wiki est utilisé par l'équipe de développement. C'est d'ailleurs son principal outil de travail.

L'édition de la plupart des pages wiki est libre. Il suffit simplement de s'être identifié avant de pouvoir poster. Pour cela '''il faut demander un accès (en précisant idenfiant et mot de passe souhaité) à devteam at openflyers.org'''

Néanmoins, cette liberté totale ne peut "s'épanouir" qu'avec quelques règles permettant à tout un chacun de suivre le plus facilement possible les évolutions des pages du wiki.

Voici donc quelques propositions de règles à respecter :
*N'hésitez-pas à éditer les pages pour corriger les fautes d'orthographe.
*Si vous souhaitez améliorer la mise en page, faites attention de bien vérifier au préalable que toute modification sur les titres ne va pas causer de liens morts.
*'''Si vous souhaitez rajouter une remarque sur une spec déjà rédigée, utilisez de préférence l'onglet "discussion" rattaché à la page.'''
*Lorsque vous soulevez plusieurs points, utilisez :
**soit des * pour créer des puces comme ici (<-là, juste à gauche<-)
**soit des titres différents à l'aide des == si vous considérez que cela méritera des réponses séparées pour chaque thème soulevé.
*N'oubliez-pas de signer à la fin de votre paragraphe en utilisant l'icône prévue à cet effet (avant dernière icône en partant de la droite au-dessus du formulaire d'édition).

'''Pour suivre les modifications du wiki, c'est ici : [[Special:Recentchanges|modifs]]'''

===Listes de diffusion===
*devteam@openflyers.org (pour l'ensemble de l'équipe de développement)
*beta@openflyers.org (pour les béta-testeurs)
*coding@openflyers.org (pour les programmeurs)
*of-commit@openflyers.org (pour le suivi des mises à jour du SVN)
Si vous souhaitez intégrer l'équipe de développement et être abonné à une des listes, il faut en faire la demande auprès du responsable de l'équipe : devteam@openflyers.org
===SVN (subversion)===

==Organisation du développement==
Nous essayons de structurer le développement afin d'être plus efficace et de ne pas perdre des choses en route. Le schéma présenté ci-après correspond plus à un idéal qu'une réalité ;-)
===Spécifications===
Il existe trois niveaux de spécifications :
*Les idées générales (cahier de résa, gestion des comptes, mécanique, etc.).

Les idées générales sont présentées synthétiquement sur la [http://openflyers.org/articles.php?lng=fr&pg=7 roue OpenFlyers]. Elles regroupent les axes de développement validés depuis la création d'OF. Les priorités de spécifications sur tel ou tel axe sont définies par l'ensemble de l'équipe. ''A l'heure actuelle, le cahier est fait, la gestion des adhérents est également terminée et nous spécifions sur la saisie des vols et la gestion des comptes pilotes.''
*La composition générale de chaque axe est décrite au travers de notions (types d'avion, profils, etc.).

La détermination des notions est, en général, laissée plutôt à l'appréciation de l'équipe de programmation. Car c'est elle qui va par la suite implémenter ces notions et qui peut mesurer la difficulté de tel ou tel aspect. De plus, les utilisateurs finaux ne sont pas forcément les mieux placés pour appréhender les différentes utilisations possibles. Ils cherchent en général une solution qui correspond uniquement à leur besoin.
*Les fonctionnalités.
Elles sont déterminées par l'ensemble de l'équipe de développement.

Le wiki constitue le support pour décrire les fonctionnalités et les notions.

A côté de ces spécifications "fonctionnelles", il existe des spécifications de programmation. Elles sont du ressort de l'équipe de programmation. L'axe suivi est : respect des standards et modularité.

===Implémentation des spécifications===
L'implémentation est effectuée par l'équipe de programmation dans les languages PHP, JavaScript, XHTML, XML, XSLT et avec comme support de base de données MySQL.

Le choix des fonctionnalités à implémenter est décidé de deux manières :
*S'il s'agit du coeur d'une idée, elle est implémentée dans le cadre de l'idée.
*S'il s'agit d'une fonctionnalité annexe, cette dernière est votée lors de réunions de l'association avec l'équipe de programmation.

Certaines fonctionnalités qui ne nécessitent qu'un très faible investissement en temps peuvent être laissées à l'appréciation de tel ou tel programmeur à partir du moment où elles s'insèrent dans le cadre voulu et qu'elles ne dénaturent pas l'application.

Afin de faciliter l'implémentation de fonctionnalités annexes, la version 2 d'OF utilisera un système de listage en xml regroupant les options activables par un club.

===Votes===
Afin de répondre mieux aux attentes des clubs et des utilisateurs, nous envisageons de mettre en place un système de vote. La recherche d'un tel outil fait parti des tâches en suspend (s'il y a un volontaire...). Succintement, voici des éléments qui pourraient composer le cahier des charges d'un tel outil :
*authentification des votants et attribution du droit à voter (but : éviter qu'un même personne vote deux fois)
*Pondération des votes (but: donner plus de poids aux développeurs, programmeurs, clubs hébergés par l'association)
*système d'édition des spécifications faisant l'objet d'un vote permettant à tout un chacun d'en rajouter de nouveaux

Documentation_de_la_solution_web_de_gestion_OpenFlyers_version_3:About

2006-04-11T18:28:31Z

Drpiquouze : /* Spécifications */

=Structuration d'OpenFlyers=
Comme indiqué sur le [http://openflyers.org site internet d'OpenFlyers], OpenFlyers correspond à deux choses :
*l'association OpenFlyers
*le logiciel OpenFlyers (qui est créé par l'équipe de développement qui n'est pas interne à l'association)

L'association met à disposition de l'équipe de développement des moyens pour assurer son fonctionnement.
==Outils de développement==
===Wiki===
Ce wiki est utilisé par l'équipe de développement. C'est d'ailleurs son principal outil de travail.

L'édition de la plupart des pages wiki est libre. Il suffit simplement de s'être identifié avant de pouvoir poster. Pour cela '''il faut demander un accès (en précisant idenfiant et mot de passe souhaité) à devteam at openflyers.org'''

Néanmoins, cette liberté totale ne peut "s'épanouir" qu'avec quelques règles permettant à tout un chacun de suivre le plus facilement possible les évolutions des pages du wiki.

Voici donc quelques propositions de règles à respecter :
*N'hésitez-pas à éditer les pages pour corriger les fautes d'orthographe.
*Si vous souhaitez améliorer la mise en page, faites attention de bien vérifier au préalable que toute modification sur les titres ne va pas causer de liens morts.
*'''Si vous souhaitez rajouter une remarque sur une spec déjà rédigée, utilisez de préférence l'onglet "discussion" rattaché à la page.'''
*Lorsque vous soulevez plusieurs points, utilisez :
**soit des * pour créer des puces comme ici (<-là, juste à gauche<-)
**soit des titres différents à l'aide des == si vous considérez que cela méritera des réponses séparées pour chaque thème soulevé.
*N'oubliez-pas de signer à la fin de votre paragraphe en utilisant l'icône prévue à cet effet (avant dernière icône en partant de la droite au-dessus du formulaire d'édition).

'''Pour suivre les modifications du wiki, c'est ici : [[Special:Recentchanges|modifs]]'''

===Listes de diffusion===
*devteam@openflyers.org (pour l'ensemble de l'équipe de développement)
*beta@openflyers.org (pour les béta-testeurs)
*coding@openflyers.org (pour les programmeurs)
*of-commit@openflyers.org (pour le suivi des mises à jour du SVN)
Si vous souhaitez intégrer l'équipe de développement et être abonné à une des listes, il faut en faire la demande auprès du responsable de l'équipe : devteam@openflyers.org
===SVN (subversion)===

==Organisation du développement==
Nous essayons de structurer le développement afin d'être plus efficace et de ne pas perdre des choses en route. Le schéma présenté ci-après correspond plus à un idéal qu'une réalité ;-)
===Spécifications===
Il existe trois niveaux de spécifications :
*Les idées générales (cahier de résa, gestion des comptes, mécanique, etc.).

Les idées générales sont présentées synthétiquement sur la [http://openflyers.org/articles.php?lng=fr&pg=7 roue OpenFlyers]. Elles regroupent les axes de développement validés depuis la création d'OF. Les priorités de spécifications sur tel ou tel axe sont définies par l'ensemble de l'équipe. ''A l'heure actuelle, le cahier est fait, la gestion des adhérents est également terminée et nous spécifions sur la saisie des vols et la gestion des comptes pilotes.''
*La composition générale de chaque axe est décrite au travers de notions (types d'avion, profils, etc.).

La détermination des notions est, en général, laissée plutôt à l'appréciation de l'équipe de programmation. Car c'est elle qui va par la suite implémenter ces notions et qui peut mesurer la difficulté de tel ou tel aspect. De plus, les utilisateurs finaux ne sont pas forcément les mieux placés pour appréhender les différentes utilisations possibles. Ils cherchent en général une solution qui correspond uniquement à leur besoin.
*Les fonctionnalités.
Elles sont déterminées par l'ensemble de l'équipe de développement.

Le wiki constitue le support pour décrire les fonctionnalités et les notions.

A côté de ces spécifications "fonctionnelles", il existe des spécifications de programmation. Elles sont du ressort de l'équipe de programmation. L'axe suivi est : respect des standards et modularité.

===Implémentation des spécifications===
L'implémentation est effectuée par l'équipe de programmation dans les languages PHP, JavaScript, XHTML, XML, XSLT et avec comme support de base de données MySQL.

Le choix des fonctionnalités à implémenter est décidé de deux manières :
*S'il s'agit du coeur d'une idée, elle est implémentée dans le cadre de l'idée
*S'il s'agit d'une fonctionnalité annexe, cette dernière est votée lors de réunions de l'association avec l'équipe de programmation.

Certaines fonctionnalités qui ne nécessitent qu'un très faible investissement en temps peuvent être laissées à l'appréciation de tel ou tel programmeur à partir du moment où elle s'insère dans le cadre voulu et qu'elles ne dénaturent par l'application.

Afin de faciliter l'implémentation de fonctionnalités annexes, la version 2 d'OF utilisera un système de listage en xml regroupant les options activables par un club.

===Votes===
Afin de répondre mieux aux attentes des clubs et des utilisateurs, nous envisageons de mettre en place un système de vote. La recherche d'un tel outil fait parti des tâches en suspend (s'il y a un volontaire...). Succintement, voici des éléments qui pourraient composer le cahier des charges d'un tel outil :
*authentification des votants et attribution du droit à voter (but : éviter qu'un même personne vote deux fois)
*Pondération des votes (but: donner plus de poids aux développeurs, programmeurs, clubs hébergés par l'association)
*système d'édition des spécifications faisant l'objet d'un vote permettant à tout un chacun d'en rajouter de nouveaux

Documentation_de_la_solution_web_de_gestion_OpenFlyers_version_3:About

2006-04-11T18:25:37Z

Drpiquouze : /* Wiki */

=Structuration d'OpenFlyers=
Comme indiqué sur le [http://openflyers.org site internet d'OpenFlyers], OpenFlyers correspond à deux choses :
*l'association OpenFlyers
*le logiciel OpenFlyers (qui est créé par l'équipe de développement qui n'est pas interne à l'association)

L'association met à disposition de l'équipe de développement des moyens pour assurer son fonctionnement.
==Outils de développement==
===Wiki===
Ce wiki est utilisé par l'équipe de développement. C'est d'ailleurs son principal outil de travail.

L'édition de la plupart des pages wiki est libre. Il suffit simplement de s'être identifié avant de pouvoir poster. Pour cela '''il faut demander un accès (en précisant idenfiant et mot de passe souhaité) à devteam at openflyers.org'''

Néanmoins, cette liberté totale ne peut "s'épanouir" qu'avec quelques règles permettant à tout un chacun de suivre le plus facilement possible les évolutions des pages du wiki.

Voici donc quelques propositions de règles à respecter :
*N'hésitez-pas à éditer les pages pour corriger les fautes d'orthographe.
*Si vous souhaitez améliorer la mise en page, faites attention de bien vérifier au préalable que toute modification sur les titres ne va pas causer de liens morts.
*'''Si vous souhaitez rajouter une remarque sur une spec déjà rédigée, utilisez de préférence l'onglet "discussion" rattaché à la page.'''
*Lorsque vous soulevez plusieurs points, utilisez :
**soit des * pour créer des puces comme ici (<-là, juste à gauche<-)
**soit des titres différents à l'aide des == si vous considérez que cela méritera des réponses séparées pour chaque thème soulevé.
*N'oubliez-pas de signer à la fin de votre paragraphe en utilisant l'icône prévue à cet effet (avant dernière icône en partant de la droite au-dessus du formulaire d'édition).

'''Pour suivre les modifications du wiki, c'est ici : [[Special:Recentchanges|modifs]]'''

===Listes de diffusion===
*devteam@openflyers.org (pour l'ensemble de l'équipe de développement)
*beta@openflyers.org (pour les béta-testeurs)
*coding@openflyers.org (pour les programmeurs)
*of-commit@openflyers.org (pour le suivi des mises à jour du SVN)
Si vous souhaitez intégrer l'équipe de développement et être abonné à une des listes, il faut en faire la demande auprès du responsable de l'équipe : devteam@openflyers.org
===SVN (subversion)===

==Organisation du développement==
Nous essayons de structurer le développement afin d'être plus efficace et de ne pas perdre des choses en route. Le schéma présenté ci-après correspond plus à un idéal qu'une réalité ;-)
===Spécifications===
Il existe trois niveaux de spécifications :
*Les idées générales (cahier de résa, gestion des comptes, mécanique, etc.).

Les idées générales sont présentées synthétiquement sur la [http://openflyers.org/articles.php?lng=fr&pg=7 roue OpenFlyers]. Elles regroupent les axes de développement validés depuis la création d'OF. Les priorités de spécifications sur tel ou tel axe est défini par l'ensemble de l'équipe. ''A l'heure actuelle, le cahier est fait, la gestion des adhérents est également terminée et nous spécifions sur la saisie des vols et la gestion des comptes pilotes.''
*La composition générale de chaque axe est décrite au travers de notions (types d'avion, profils, etc.).

La détermination des notions est, en général, laissée plutôt à l'appréciation de l'équipe de programmation. Car c'est elle qui va par la suite implémenter ces notions et qui peut mesurer la difficulté de tel ou tel aspect. De plus, les utilisateurs finaux ne sont pas forcément les mieux placés pour appréhender les différentes utilisations possibles. Ils cherchent en général une solution qui correspond uniquement à leur besoin.
*Les fonctionnalités.
Elles sont déterminées par l'ensemble de l'équipe de développement.

Le wiki constitue le support pour décrire les fonctionnalités et les notions.

A côté de ces spécifications "fonctionnelles", il existe des spécifications de programmation. Elles sont du ressort de l'équipe de programmation. L'axe suivi est : respect des standards et modularité.
===Implémentation des spécifications===
L'implémentation est effectuée par l'équipe de programmation dans les languages PHP, JavaScript, XHTML, XML, XSLT et avec comme support de base de données MySQL.

Le choix des fonctionnalités à implémenter est décidé de deux manières :
*S'il s'agit du coeur d'une idée, elle est implémentée dans le cadre de l'idée
*S'il s'agit d'une fonctionnalité annexe, cette dernière est votée lors de réunions de l'association avec l'équipe de programmation.

Certaines fonctionnalités qui ne nécessitent qu'un très faible investissement en temps peuvent être laissées à l'appréciation de tel ou tel programmeur à partir du moment où elle s'insère dans le cadre voulu et qu'elles ne dénaturent par l'application.

Afin de faciliter l'implémentation de fonctionnalités annexes, la version 2 d'OF utilisera un système de listage en xml regroupant les options activables par un club.

===Votes===
Afin de répondre mieux aux attentes des clubs et des utilisateurs, nous envisageons de mettre en place un système de vote. La recherche d'un tel outil fait parti des tâches en suspend (s'il y a un volontaire...). Succintement, voici des éléments qui pourraient composer le cahier des charges d'un tel outil :
*authentification des votants et attribution du droit à voter (but : éviter qu'un même personne vote deux fois)
*Pondération des votes (but: donner plus de poids aux développeurs, programmeurs, clubs hébergés par l'association)
*système d'édition des spécifications faisant l'objet d'un vote permettant à tout un chacun d'en rajouter de nouveaux

Fichier:Date jour.jpg

2006-04-08T10:25:56Z

Drpiquouze : Nouvelle disposition de date et heure, distinguant date et heure du jour de date de résa.

Nouvelle disposition de date et heure, distinguant date et heure du jour de date de résa.

Fichier:Date jour.png

2006-04-08T10:23:19Z

Drpiquouze : Nouvelle disposition de la date et de l'heure, distinguant la date et l'heure du jour, de la date de l'affichage des résas.

Nouvelle disposition de la date et de l'heure, distinguant la date et l'heure du jour, de la date de l'affichage des résas.

Rapporter un bug

2006-04-03T17:38:20Z

Drpiquouze : /* Rapporter un bug dans Mantis (pour les testeurs/rapporteurs) */

= Introduction =

Nous utilisons comme outil de "traceur de bugs" (ou Bug Tracking System) [http://bts.openflyers.org/ Mantis].

Pour pouvoir éditer des informations, il faut d'abord vous identifier.

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.

=Rapporter un bug dans Mantis (pour les testeurs/rapporteurs)=
Avant de rapporter un bug, prenez le temps d'effectuer les actions suivantes :
*Vérifier que le bug n'est pas déjà rapporté.
*Renseigner les items dès le début pour éviter l'envoi dans une rubrique non adaptée.
*Choisir la bonne catégorie :

{| {{prettytable}}
!Intitulé!!Rubrique
|-
|Admin||si cela touche la partie configuration/administration
|-
|Cahier des resa||si cela touche la partie "cahier de réservations"
|-
|Gestions des vols|| si cela touche la partie "saisie des vols"
|-
|Gestions des comptes||si cela touche la partie financière
|-
|Documentation|| si cela concerne des précisions sur la documentation
|-
|Update||si cela touche l'utilitaire de changement de version
|-
|Translation||si cela touche les traductions (phrase dans une mauvaise langue ou manquante dans une langue)
|}
*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 répertorié sous une mauvaise version). Le numéro de la version d'OF que vous utilisez se trouve en haut à gauche de la page d'accueil d'OF.
**1.2.x
**2.0alpha
**2.0

*Résumé :
Rédiger un intitulé explicite comportant si possible le n° de référence du scénario correspondant (cf. [[script]])

*Dans la description
Si le bug est sur une version en ligne, indiquez sur quelle base vous avez testé.
Si c'est une version en local, indiquez l'état dans laquelle est votre Base de données. Faire éventuellement une sauvegarde pour la figer dans un stade où le bug est reproductible.

Le descriptif doit être complet pour que les développeurs sachent identifier l'endroit du problème.
*La nature "réelle" (non affichage, warning, etc.) du problème et sa manifestation.
*Communiquer TOUS les éléments minimaux pour commencer à réfléchir au pourquoi du problème, c'est à dire :
**OS utilisé (Windows 98, Windows XP, Linux, UNIX, Jaguar, etc.)
**Navigateur utilisé (Safari, Internet Explorer, Netscape Navigator, Firefox, etc.)
**La version du navigateur.

*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 communiquer également les éléments suivants :
**phpinfo() peut être utile pour pouvoir détecter un éventuel problème de configuration de votre serveur.
**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).
'''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 payants. Notre application fonctionne correctement sur un serveur Linux "standard" (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.
*Joindre 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.
*En cours de traitement, utiliser les notes pour ajouter des informations, éviter les échéanges par email parallèle.
Si le bug est sur une version en ligne, indiquer sur quelle base vous avez testé.
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 où le bug est reproductible.

*Lorsque le bug est résolu vous recevrez un email d'information. Vous devez '''fermer vos bugs'''. Si vous constatez que la solution ne correspond pas à votre description (totale ou parielle), relancez le sujet en le changeant d'état. Par contre si vous détectez une nouvelle anomalie rédigez un nouveau bug.
*La fermeture du Bug doit être effectuée par celui qui l'a émis.
*En l'absence d'action de votre part dans un temps raisonnable le développeur ou un administrateur le fermera.

=Description des états et de l'avancement de la résolution=
==Etats==
{| {{prettytable}}
!Intitulé de l'état!!Description!!Qui devrait mettre cet état
|-
|nouveau||nouveau bug, c'est l'état initial||le rédacteur du bug
|-
|commentaire||le bug nécessite plus d'informations, le rédacteur du bug devrait y préter attention||un gestionnaire ou un développeur
|-
|accepté||le bug a été lu mais n'est ni confirmé ni assigné||un gestionnaire ou le développeur dont dépend le bug
|-
|confirmé||le bug est confirmé et reproductible||un gestionnaire ou un développeur
|-
|assigné||le bug est assigné à un développeur||un gestionnaire ou un développeur qui le prend en charge
|-
|résolu||le bug devrait être résolu, en attente de la confirmation de sa résolution par le rédacteur du bug||le développeur qui a corrigé le bug
|-
|fermé||le bug est fermé||le rédacteur initial du bug ou un gestionnaire ayant confirmé le bug
|}
==Résolutions==
{| {{prettytable}}
!Intitulé de la résolution!!Description
|-
|ouvert||bug ouvert en attente
|-
|résolu||bug résolu d'après le développeur responsable
|-
|réouvert||bug considéré comme toujours existant après correction
|-
|impossible à reproduire||le bug rapporté n'arrive pas à être reproduit
|-
|impossible à corriger||il n'y a pas de possibilité de corriger le bug
|-
|doublon||le bug a déjà fait l'objet d'un rapport dans Mantis
|-
|pas un bug||Ce n'est pas considéré comme un bug
|-
|suspendu||Le bug est mis de côté
|-
|ne sera pas résolu||Le bug est reconnu mais ne sera pas résolu
|}

=Traitement des bugs dans Mantis (pour les développeurs et gestionnaires)=

*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)

*La fermeture du Bug doit être effectuée par celui qui l'a reporté.

*En l'absence d'action de sa part dans un temps raisonnable un gestionnaire le fermera.

'''Suivez vos bugs'''

=Respect des standards du web=
Nous avons à coeur de respecter les standards du web dont notamment le standard xhtml 1.0 strict.

Pour vérifier la validité d'une page, il existe plusieurs outils.

Voici comment utiliser celui fourni par le [http://www.w3.org/ W3C] :
*Afficher votre page à l'aide d'un navigateur (firefox ou internet explorer)
*sauver la page seule sur votre disque dur
*Allez sur la page du [http://validator.w3.org/ validator] du W3C
*Uploader le fichier sauvé sur le disque dur
*constatez le résultat

Discussion:Main Page

2006-04-03T17:23:34Z

Drpiquouze : /* Dans tous les cas */

''Cette page de discussion peut être l'équivalent du "bar du coin" ou on parle des choses en général.''

==Multilinguisme & xml/xsl==
Plusieurs possibilités s'offrent à nous sur la façon de "moderniser" l'implémentation existante dans la version 1.2 d'OF du multilinguisme.

===But===
Actuellement le multilinguisme est géré par des fichiers langues sur le modèle :
$lang['ITEM'] = 'traduction dans une langue';

Cette méthode a plusieurs inconvénients :
*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.
*cela ne permet pas de trouver les "items morts", c'est à dire les items qui devraient être supprimés.
*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.
Pour résumer ces points :
la méthode actuelle empêche la création d'une interface de gestion facilitant la vie des traducteurs.
Un dernier inconvénient :
*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à.
===Tout d'abord, il y a deux méthodes de stockage des traductions :===
*par base de données (dans ce cas on se tournerait vers la classe Translation2)
*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.

Mon avis :
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).
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)
--[[Utilisateur:KAeL|KAeL]] 3 Nov 2005 à 14:29 (CET)

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)

===Ensuite, vient la méthode de conversion de la feuille xsl :===
Dans les deux cas, on part d'une feuille xsl qui va contenir des balises <text> définissant le texte à remplacer dans la bonne langue par exemple :

<nowiki><center>
<text>aircraft list</text>
<xsl:value-of select="registration"/>
</center></nowiki>

On a donc deux choix :

*soit on effectue la transformation du <text>aircraft list</text> en premier puis on obtient une deuxième feuille XSL (en fait la même que celle de Joël)
*soit on effectue la transformation du xml via la feuille de style "générique", on obtient alors une sortie presque-html avec les <text> puis on les remplace par la langue finale.

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.

Intérêt de la seconde méthode : elle me paraît plus simple...

Ã‡a me paraît assez lourd comme approche --[[Utilisateur:KAeL|KAeL]] 3 Nov 2005 à 14:30 (CET)

===Dernier point : mappage xml/base de données===
Dans translation2, les textes sont référencés selon 2 éléments (cf. [[Translation_Table]]) : un id qui "nomme" 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 ?)

Je vous propose la suivante, on fait un "mappage" base de données/xml ainsi :

<text page="admin">aircraft list</text>

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.

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 "valider", "annuler", etc.)

Inconvénient : la présence très fréquente de l'attribut page qui n'apporte pas grand chose.

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.

Avantage : c'est plus léger pour la page xsl

Inconvénient : faut ré-écrire pour chaque page des mots identiques

J'attends vos avis ;-)
--[[Utilisateur:Claratte|Christophe]] 30 Sep 2005 à 01:47 (CEST)

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)

== Dans tous les cas ==

Je pense que dans tous les cas, on devrait commencer par se faire une classe OfTranslator avec qq méthodes génériques :
setLang('fr')
getLang() -> renvoie 'fr'
getAvailableLangs() -> renvoie array('fr', 'en', ...)
tr('hi') -> salut (tr comme translate)

Après derrière, on peut coder nos fonctions à nous ou utiliser une classe PEAR comme Translation2.

La question est : comment on stocke les données ?
* en xml (quand on choisit la langue, on stocke les traductions en mémoire)
* ds un fichier .ini (même remarque)
* en base de données (lent, pas adapté)
* en utilisant gettext (des infos ici : [http://www.gnu.org/software/gettext/manual/html_mono/gettext.html#SEC1 GNU gettext]) (supporté par Translation2)

--[[Utilisateur:KAeL|KAeL]] 3 Nov 2005 à 14:40 (CET)

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]

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.

De plus il existe des logiciels pour éditer les fichiers de langues, c'est plus digeste que d'éditer les fichiers textes à la main.

Une explication de l'utilisation de gettext sur le [http://developpeur.journaldunet.com/tutoriel/php/030120php_localisation1b.shtml journal du net]

Je vote pour gettext !!
--[[Utilisateur:Scroses|Scroses]] 3 Nov 2005 à 20:05 (CET)

(Pense à rajouter ta signature (avant dernière icône dans le formulaire d'édition), sinon on a du mal à suivre qui dit quoi)

Merci pour le lien sur le journal du net, parce que l'introduction de gettext m'a laissé perplexe...

Concernant sqlite, y'a pas plus de raison de l'utiliser comme base de données pour les traductions que pour le reste...

Sinon pour gettext, je ne suis pas contre a priori mais je lui vois trois inconvénients :
*il faut qu'il soit present sur le serveur.
*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.
*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)
--[[Utilisateur:Claratte|Christophe]] 3 Nov 2005 à 23:53 (CET)

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.
Pour les serveurs wamp ou easyphp, il faut aller décommenter php_gettext.dll dans php.ini.

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.

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.

ps j'ai quelques pour signer...

--[[Utilisateur:Scroses|Scroses]]

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.

J'ai même vu des application php de traduction.

--Utopie 4 Nov 2005 à 10:07 (CET)

Discussion:Main Page

2006-04-03T17:16:04Z

Drpiquouze : /* Multilinguisme & xml/xsl */

''Cette page de discussion peut être l'équivalent du "bar du coin" ou on parle des choses en général.''

==Multilinguisme & xml/xsl==
Plusieurs possibilités s'offrent à nous sur la façon de "moderniser" l'implémentation existante dans la version 1.2 d'OF du multilinguisme.

===But===
Actuellement le multilinguisme est géré par des fichiers langues sur le modèle :
$lang['ITEM'] = 'traduction dans une langue';

Cette méthode a plusieurs inconvénients :
*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.
*cela ne permet pas de trouver les "items morts", c'est à dire les items qui devraient être supprimés.
*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.
Pour résumer ces points :
la méthode actuelle empêche la création d'une interface de gestion facilitant la vie des traducteurs.
Un dernier inconvénient :
*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à.
===Tout d'abord, il y a deux méthodes de stockage des traductions :===
*par base de données (dans ce cas on se tournerait vers la classe Translation2)
*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.

Mon avis :
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).
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)
--[[Utilisateur:KAeL|KAeL]] 3 Nov 2005 à 14:29 (CET)

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)

===Ensuite, vient la méthode de conversion de la feuille xsl :===
Dans les deux cas, on part d'une feuille xsl qui va contenir des balises <text> définissant le texte à remplacer dans la bonne langue par exemple :

<nowiki><center>
<text>aircraft list</text>
<xsl:value-of select="registration"/>
</center></nowiki>

On a donc deux choix :

*soit on effectue la transformation du <text>aircraft list</text> en premier puis on obtient une deuxième feuille XSL (en fait la même que celle de Joël)
*soit on effectue la transformation du xml via la feuille de style "générique", on obtient alors une sortie presque-html avec les <text> puis on les remplace par la langue finale.

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.

Intérêt de la seconde méthode : elle me paraît plus simple...

Ã‡a me paraît assez lourd comme approche --[[Utilisateur:KAeL|KAeL]] 3 Nov 2005 à 14:30 (CET)

===Dernier point : mappage xml/base de données===
Dans translation2, les textes sont référencés selon 2 éléments (cf. [[Translation_Table]]) : un id qui "nomme" 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 ?)

Je vous propose la suivante, on fait un "mappage" base de données/xml ainsi :

<text page="admin">aircraft list</text>

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.

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 "valider", "annuler", etc.)

Inconvénient : la présence très fréquente de l'attribut page qui n'apporte pas grand chose.

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.

Avantage : c'est plus léger pour la page xsl

Inconvénient : faut ré-écrire pour chaque page des mots identiques

J'attends vos avis ;-)
--[[Utilisateur:Claratte|Christophe]] 30 Sep 2005 à 01:47 (CEST)

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)

== Dans tous les cas ==

Je pense que dans tous les cas, on devrait commencer par se faire une classe OfTranslator avec qq méthodes génériques :
setLang('fr')
getLang() -> renvoie 'fr'
getAvailableLangs() -> renvoie array('fr', 'en', ...)
tr('hi') -> salut (tr comme translate)

Après derrière, on peut coder nos fonctions à nous où utiliser une classe PEAR comme Translation2.

La question est : comment on stocke les données ?
* en xml (qd on choisit la langue, on stocke les traductions en mémoire)
* ds un fichier .ini (même remarque)
* en base de données (lent, pas adapté)
* en utilisant gettext (des infos ici : [http://www.gnu.org/software/gettext/manual/html_mono/gettext.html#SEC1 GNU gettext]) (supporté par Translation2)

--[[Utilisateur:KAeL|KAeL]] 3 Nov 2005 à 14:40 (CET)

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]

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.

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

Une explication de l'utilisation de gettext sur le [http://developpeur.journaldunet.com/tutoriel/php/030120php_localisation1b.shtml journal du net]

Je vote pour gettext !!
--[[Utilisateur:Scroses|Scroses]] 3 Nov 2005 à 20:05 (CET)

(Pense a rajouter ta signature (avant derniere icone dans le formulaire d'edition), sinon on a du mal a suivre qui dit quoi)

Merci pour le lien sur le journal du net, parce que l'introduction de gettext m'a laisse perplexe...

Concernant sqlite, y'a pas plus de raison de l'utiliser comme base de donnes pour les traductions que pour le reste...

Sinon pour gettext, je ne suis pas contre a priori mais je lui vois trois inconvenients :
*il faut qu'il soit present sur le serveur
*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
*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)
--[[Utilisateur:Claratte|Christophe]] 3 Nov 2005 à 23:53 (CET)

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.
Pour les serveurs wamp ou easyphp, il faut aller decomenter php_gettext.dll dans php.ini

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

pour l'histoire de la compilation des fichiers de langue, pour moi non plus c'est pas tres clair...Je creuse la question

ps j'ai quelques pour signer...

--[[Utilisateur:Scroses|Scroses]]

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.

J'ai meme vu des application php de traductions

--Utopie 4 Nov 2005 à 10:07 (CET)

Fichier:Acces public.png

2006-03-29T20:45:20Z

Drpiquouze : Fenêtre de login à partir de l'accès public

Fenêtre de login à partir de l'accès public

Draft

2006-03-26T14:47:50Z

Drpiquouze : /* encore plus petit */

=Voici un exemple de grand titre=
==un sous-titre==
===encore plus petit===
Là, c'est du blabla bla
*une puce
*pour lister

Blabla bis
#une liste numérotée
#c'est pratique pour numéroter
#:et si on a besoin d'un petit paragraphe sans perdre la numérotation
#alors voilà

une petite mise en encadré

{| {{prettytable}}
!Titre 1!!Titre 2!!Titre 3
|-
|1ère ligne||dsfsf||dsfsdsdf
|-
|2e ligne||dazasfsf||dsqtyutjsjs
|}

La graphie '''2e''' est préférable à la graphie '''2ème'''

une autre mise en encadré ?

N'est-il pas ?

Utilisateur:Drpiquouze

2006-03-21T20:10:01Z

Drpiquouze :

Bonjour,

Je suis Denis Rousseaux, médecin anesthésiste (d'où le pseudo ;-) ).
En tant que webmestre du site de mon aéroclub, l''''aéroclub du sud E. Adam de Villiers''', à La Réunion,

L'aéroclub français le plus proche de l'antarctique !

je me suis intéressé à Openflyers récemment. Comme je suis un maniaque de l'orthographe, je me propose de corriger tout ce qui passera à ma portée.

Rapporter un bug

2006-03-21T11:27:43Z

Drpiquouze : /* Rapporter un bug dans Mantis (pour les testeurs/rapporteurs) */

= Introduction =

Nous utilisons comme outil de "traceur de bugs" (ou Bug Tracking System) [http://bts.openflyers.org/ Mantis].

Pour pouvoir éditer des informations, il faut d'abord vous identifier.

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.

=Rapporter un bug dans Mantis (pour les testeurs/rapporteurs)=
Avant de rapporter un bug, prenez le temps d'effectuer les actions suivantes :
*Vérifier que le bug n'est pas déjà rapporté
*Renseigner les items des le débuts pour éviter l'envoi dans une rubrique non adaptée
*Choisissez la bonne catégorie :

{| {{prettytable}}
!Intitulé!!Rubrique
|-
|Admin||si cela touche la partie configuration/administration
|-
|Cahier des resa||si cela touche la partie "cahier de réservations"
|-
|Gestions des vols|| si cela touche la partie "saisie des vols"
|-
|Gestions des comptes||si cela touche la partie financière
|-
|Documentation|| si cela concerne des précisions sur la documentation
|-
|Update||si cela touche l'utilitaire de changement de version
|-
|Translation||si cela touche les traductions (phrase dans une mauvaise langue ou manquante dans une langue)
|}
*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 répertorié sous une mauvaise version). Le numéro de la version d'OF que vous utilisez se trouve en haut à gauche de la page d'accueil d'OF.
**1.2.x
**2.0alpha
**2.0

*Résumé :
Rédiger un intitulé explicite comportant si possible le n° de référence du scénario correspondant (cf. [[script]])

*Dans la description
Si le bug est sur une version en ligne, indiquez sur quelle base vous avez testé.
Si c'est une version en local, indiquez 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.

Le descriptif doit être complet pour que les développeurs sachent identifier l'endroit du problème.
*La nature "réelle" (non affichage, warning, etc.) du problème et sa manifestation.
*Communiquer TOUS les éléments minimaux pour commencer à réfléchir au pourquoi du problème, c'est à dire :
**OS utilisé (Windows 98, Windows XP, Linux, UNIX, Jaguar, etc.)
**Navigateur utilisé (Safari, Internet Explorer, Netscape Navigator, Firefox, etc.)
**La version du navigateur.

*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 communiquer également les éléments suivants :
**phpinfo() peut être utile pour pouvoir détecter un éventuel problème de configuration de votre serveur.
**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).
'''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 payants. Notre application fonctionne correctement sur un serveur Linux "standard" (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.
*Joindre 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.
*En cours de traitement, utiliser les notes pour ajouter des informations, éviter les échéanges par email parallèle.
Si le bug est sur une version en ligne, indiquer sur quelle base vous avez testé.
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 où le bug est reproductible.

Le descriptif doit être complet pour que les développeurs sachent identifier l'endroit du problème.

Indiquer : votre système d'exploitation et le navigateur utilisé.

Joindre une copie d'écran est parfois plus explicite que de longs discours mais ne pas en abuser, on ne cherche pas à documenter un bug pour le contourner mais à fournir des explications au développeur pour traitement.
*En cours de traitement, utiliser les notes pour ajouter des informations.
*Lorsque le bug est résolu vous recevrez un email d'information. Vous devez '''fermer vos bugs'''. Si vous constatez que la solution ne correspond pas à votre description (totale ou parielle), relancez le sujet en le changeant d'état. Par contre si vous détectez une nouvelle anomalie rédigez un nouveau bug.
*La fermeture du Bug doit être effectuée par celui qui l'a émis.
*En l'absence d'action de votre part dans un temps raisonnable le développeur ou un administrateur le fermera.

=Description des états et de l'avancement de la résolution=
==Etats==
{| {{prettytable}}
!Intitulé de l'état!!Description!!Qui devrait mettre cet état
|-
|nouveau||nouveau bug, c'est l'état initial||le rédacteur du bug
|-
|commentaire||le bug nécessite plus d'informations, le rédacteur du bug devrait y préter attention||un gestionnaire ou un développeur
|-
|accepté||le bug a été lu mais n'est ni confirmé ni assigné||un gestionnaire ou le développeur dont dépend le bug
|-
|confirmé||le bug est confirmé et reproductible||un gestionnaire ou un développeur
|-
|assigné||le bug est assigné à un développeur||un gestionnaire ou un développeur qui le prend en charge
|-
|résolu||le bug devrait être résolu, en attente de la confirmation de sa résolution par le rédacteur du bug||le développeur qui a corrigé le bug
|-
|fermé||le bug est fermé||le rédacteur initial du bug ou un gestionnaire ayant confirmé le bug
|}
==Résolutions==
{| {{prettytable}}
!Intitulé de la résolution!!Description
|-
|ouvert||bug ouvert en attente
|-
|résolu||bug résolu d'après le développeur responsable
|-
|réouvert||bug considéré comme toujours existant après correction
|-
|impossible à reproduire||le bug rapporté n'arrive pas à être reproduit
|-
|impossible à corriger||il n'y a pas de possibilité de corriger le bug
|-
|doublon||le bug a déjà fait l'objet d'un rapport dans Mantis
|-
|pas un bug||Ce n'est pas considéré comme un bug
|-
|suspendu||Le bug est mis de côté
|-
|ne sera pas résolu||Le bug est reconnu mais ne sera pas résolu
|}

=Traitement des bugs dans Mantis (pour les développeurs et gestionnaires)=

*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)

*La fermeture du Bug doit être effectuée par celui qui l'a reporté.

*En l'absence d'action de sa part dans un temps raisonnable un gestionnaire le fermera.

'''Suivez vos bugs'''

=Respect des standards du web=
Nous avons à coeur de respecter les standards du web dont notamment le standard xhtml 1.0 strict.

Pour vérifier la validité d'une page, il existe plusieurs outils.

Voici comment utiliser celui fourni par le [http://www.w3.org/ W3C] :
*Afficher votre page à l'aide d'un navigateur (firefox ou internet explorer)
*sauver la page seule sur votre disque dur
*Allez sur la page du [http://validator.w3.org/ validator] du W3C
*Uploader le fichier sauvé sur le disque dur
*constatez le résultat

Rapporter un bug

2006-03-21T11:06:22Z

Drpiquouze : /* Rapporter un bug dans Mantis (pour les testeurs/rapporteurs) */

= Introduction =

Nous utilisons comme outil de "traceur de bugs" (ou Bug Tracking System) [http://bts.openflyers.org/ Mantis].

Pour pouvoir éditer des informations, il faut d'abord vous identifier.

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.

=Rapporter un bug dans Mantis (pour les testeurs/rapporteurs)=
Avant de rapporter un bug, prenez le temps d'effectuer les actions suivantes :
*Vérifier que le bug n'est pas déjà rapporté
*Renseigner les items des le débuts pour éviter l'envoi dans une rubrique non adaptée
*Choisissez la bonne catégorie :

{| {{prettytable}}
!Intitulé!!Rubrique
|-
|Admin||si cela touche la partie configuration/administration
|-
|Cahier des resa||si cela touche la partie "cahier de réservations"
|-
|Gestions des vols|| si cela touche la partie "saisie des vols"
|-
|Gestions des comptes||si cela touche la partie financière
|-
|Documentation|| si cela concerne des précisions sur la documentation
|-
|Update||si cela touche l'utilitaire de changement de version
|-
|Translation||si cela touche les traductions (phrase dans une mauvaise langue ou manquante dans une langue)
|}
*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 la version d'OF que vous utilisez se trouve en haut à gauche de la page d'accueil d'OF.
**1.2.x
**2.0alpha
**2.0

*Résumé :
Rédiger un intitulé explicite comportant si possible le n° de référence du scénario correspondant (cf. [[script]])

*Dans la description
Si le bug est sur une version en ligne, indiquez sur quelle base vous avez testé.
Si c'est une version en local, indiquez 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.

Le descriptif doit être complet pour que les développeurs sachent identifier l'endroit du problème.
*La nature "réelle" (non affichage, warning, etc.) du problème et sa manifestation.
*Communiquer TOUS les éléments minimaux pour commencer à réfléchir au pourquoi du problème, c'est à dire :
**OS utilisé (Windows 98, Windows XP, Linux, UNIX, Jaguar, etc.)
**Navigateur utilisé (Safari, Internet Explorer, Netscape Navigator, Firefox, etc.)
**La version du navigateur.

*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 communiquer également les éléments suivants :
**phpinfo() peut être utile pour pouvoir détecter un éventuel problème de configuration de votre serveur.
**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).
'''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 payants. Notre application fonctionne correctement sur un serveur Linux "standard" (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.
*Joindre 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.
*En cours de traitement, utiliser les notes pour ajouter des informations, éviter les échéanges par email parallèle.
Si le bug est sur une version en ligne, indiquer sur quelle base vous avez testé.
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 où le bug est reproductible.

Le descriptif doit être complet pour que les développeurs sachent identifier l'endroit du problème.

Indiquer : votre système d'exploitation et le navigateur utilisé.

Joindre une copie d'écran est parfois plus explicite que de longs discours mais ne pas en abuser, on ne cherche pas à documenter un bug pour le contourner mais à fournir des explications au développeur pour traitement.
*En cours de traitement, utiliser les notes pour ajouter des informations.
*Lorsque le bug est résolu vous recevrez un email d'information. Vous devez '''fermer vos bugs'''. Si vous constatez que la solution ne correspond pas à votre description (totale ou parielle), relancez le sujet en le changeant d'état. Par contre si vous détectez une nouvelle anomalie rédigez un nouveau bug.
*La fermeture du Bug doit être effectuée par celui qui l'a émis.
*En l'absence d'action de votre part dans un temps raisonnable le développeur ou un administrateur le fermera.

=Description des états et de l'avancement de la résolution=
==Etats==
{| {{prettytable}}
!Intitulé de l'état!!Description!!Qui devrait mettre cet état
|-
|nouveau||nouveau bug, c'est l'état initial||le rédacteur du bug
|-
|commentaire||le bug nécessite plus d'informations, le rédacteur du bug devrait y préter attention||un gestionnaire ou un développeur
|-
|accepté||le bug a été lu mais n'est ni confirmé ni assigné||un gestionnaire ou le développeur dont dépend le bug
|-
|confirmé||le bug est confirmé et reproductible||un gestionnaire ou un développeur
|-
|assigné||le bug est assigné à un développeur||un gestionnaire ou un développeur qui le prend en charge
|-
|résolu||le bug devrait être résolu, en attente de la confirmation de sa résolution par le rédacteur du bug||le développeur qui a corrigé le bug
|-
|fermé||le bug est fermé||le rédacteur initial du bug ou un gestionnaire ayant confirmé le bug
|}
==Résolutions==
{| {{prettytable}}
!Intitulé de la résolution!!Description
|-
|ouvert||bug ouvert en attente
|-
|résolu||bug résolu d'après le développeur responsable
|-
|réouvert||bug considéré comme toujours existant après correction
|-
|impossible à reproduire||le bug rapporté n'arrive pas à être reproduit
|-
|impossible à corriger||il n'y a pas de possibilité de corriger le bug
|-
|doublon||le bug a déjà fait l'objet d'un rapport dans Mantis
|-
|pas un bug||Ce n'est pas considéré comme un bug
|-
|suspendu||Le bug est mis de côté
|-
|ne sera pas résolu||Le bug est reconnu mais ne sera pas résolu
|}

=Traitement des bugs dans Mantis (pour les développeurs et gestionnaires)=

*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)

*La fermeture du Bug doit être effectuée par celui qui l'a reporté.

*En l'absence d'action de sa part dans un temps raisonnable un gestionnaire le fermera.

'''Suivez vos bugs'''

=Respect des standards du web=
Nous avons à coeur de respecter les standards du web dont notamment le standard xhtml 1.0 strict.

Pour vérifier la validité d'une page, il existe plusieurs outils.

Voici comment utiliser celui fourni par le [http://www.w3.org/ W3C] :
*Afficher votre page à l'aide d'un navigateur (firefox ou internet explorer)
*sauver la page seule sur votre disque dur
*Allez sur la page du [http://validator.w3.org/ validator] du W3C
*Uploader le fichier sauvé sur le disque dur
*constatez le résultat

Draft

2006-03-20T18:52:15Z

Drpiquouze : /* encore plus petit */

=Voici un exemple de grand titre=
==un sous-titre==
===encore plus petit===
Là, c'est du blabla bla
*une puce
*pour lister

une petite mise en encadré

{| {{prettytable}}
!Titre 1!!Titre 2!!Titre 3
|-
|1ère ligne||dsfsf||dsfsdsdf
|-
|2ème ligne||dazasfsf||dsqtyutjsjs
|}

une autre mise en encadré ?

N'est-il pas ?

Draft

2006-03-20T18:51:20Z

Drpiquouze : /* encore plus petit */

Draft

2006-03-20T18:50:47Z

Drpiquouze : /* encore plus petit */