OF2.0 various spec
From Openflyers
Introduction
Le but de cette page est de lister les specs qui ne font pas partie du coeur de la version 2.0 mais qui pourraient soit ajouter une fonctionnalité à cette version (ou aux versions 2.x) soit améliorer des choses existantes (sur la version 1.2 principalement)
Les specs sont triées par théme.
Eléments requis sur le serveur
PEAR
PHP
PHP 5.0 ou peut-être 5.1
MySQL
MySQL 3.x
Règles de programmation
HTML
- XHTML 1.0 strict.
- Utilisation du couple XML/XLST pour générer les pages.
CSS
CSS 2.0
Divers
- GetText ?
Installation
- Permettre l'installation sur une base de données déjà existante
- Permettre de préfixer les noms des tables de la base de données
Logs
Archivage des données (avec consultation possible) cf. sujet de stage
Alertes
e-mails
Ajout d'un contact aux e-mails
Si l'élève pose ou modifie une résa, ce serait une aide appréciable d'indiquer son tel et/ou son mail dans le message à l'instructeur. Il arrive parfois que l'instructeur ne puisse pas joindre son élève (que parfois il ne connaît pas s'il est nouveau) pour lui dire que la résa ne peut pas convenir, par exemple, pour des raisons de disponibilité.
Prévenir des places mises à disposition
Quand un pilote sélectionne des places dispo lors de sa réservation, il serait pratique que les membres qui le souhaitent puissent recevoir un mail d'avertissement. Cette réception pourrait être configurable dans la fiche perso par le biais d'une case à cocher.
--Utopie 17 Nov 2005 à 11:22 (CET)
SMS
Principe de fonctionnement
Pour proposer cette fonction aux clubs, il faut définir comment se réalise la facturation de ce service. Le plus simple pour nous c'est juste de fournir les scripts d'envoi de sms à la manière des scripts de gestions des mailing lists. Ce ne serait pas une bonne idée d'acheter un lot de sms et de les revendre aux clubs, il faudrait mettre en place un système de gestion de quotas par club, trop contraignant.
On fournit les scripts, les clubs achètent les mails directement chez le prestataire.
Côté technique
Le principe est d'envoyer une url avec en variable les info nécessaires :
- login atribué par l'opérateur
- n° de téléphone
- message
Selon les opérateurs il y a tout un tas d'options que l'on peut faire passer (envoi différé, accusé de réception...)
Pour un opérateur c'est tout un flux xml à faire passer (allmysms.com)
Je pense que ce sont des infos facilement intégrables dans une table.
Les coûts
Chez les trois opérateurs dont j'ai exploré l'offre (voir ci-après), il n'y a pas de frais d'inscription ni d'abonnement, seul l'achat des sms est à la charge du client, l'envoi est compris dans le prix.
Pour l'instant le prix moyen est de 18 euro ttc pour 100 sms
les prestataires
Ce sont des opérateurs figurant dans les liens sponsorisés de Google, je ne suis pas encore entré en contact avec eux.
--Utopie 20 Nov 2005 à 16:35 (CET)
Club
Gestion des vols
Vols particuliers
Gestion des utilisateurs
Affichages par défaut
- création d'un champ DEFAULT_VIEW_TYPE dans la table CLUBS qui contiendrait les bits par défaut d'un VIEW_TYPE pour la création de nouveaux membres.
- Après identification, si l'utilisateur a plusieurs profils, proposer par défaut le plus bas profil (sécurité).
--Sadoche 18:39, 2 March 2006 (CET)
- Dans la page LISTE DES MEMBRES, il faudrait une colonne précisant la date de validité de la cotisation. Cela permettrait de supprimer les cartes de membres (longues et fastidieuses à imprimer, puis à expédier), en disant simplement aux membres qu'ils peuvent avoir confirmation de leur statut de membre (cotisation bien enregistrée par le club) en allant sur OpenFlyers. --Sadoche 13:30, 4 March 2006 (CET)
- Ajouter une case à cocher dans la définition des profils (à la fin) avec pour définition quand la case est cochée : Ce profil est exclusif de tous les autres. et comme explication : Un utilisateur auquel on attribue ce profil ne peut en avoir aucun autre (typiquement, un profil élève-pilote ou un profil sans-droits). Chaque fois que ce profil est coché chez un individu donné, un javascript vérifie qu'aucun autre profil n'est attribué à ce pilote, et dans le cas contraire avertit de la nécessité de décocher tous les autres profils, avant de pouvoir valider l'opération. Ça évite de se retrouver par erreur avec un pilote qui est à la fois sans-droits (pour solde négatif par ex.) et reste pilote (non décoché par erreur) et peut donc néanmoins effectuer des réservations.
Gestion des comptes pilotes
Utilisation du prélèvement automatique
- Principe général
Possibilité offerte aux pilotes qui le souhaitent de faire prélever par l'aéroclub directement sur leur compte bancaire le solde négatif de leur compte pilote.
- Prérequis
- Demande d'un numéro d'émetteur auprès de la banque de l'aéroclub et de la Banque de France.
- Mise en place avec la banque de l'a/c de la procédure d'envoi du fichier de prélèvements :
- soit courriel avec fichier joint + fax de confirmation
- soit envoi direct par le portail internet de la banque + fax de confirmation.
- Récupération du format de données du fichier à envoyer auprès de la banque. Celui-ci doit être standardisé exemple à mettre ici.
- Création d'une table qui contiendra les coordonnées bancaires du pilote en relation avec la table des pilotes.
- Numéro de compte
- Code établissement
- Code guichet
- Domiciliation
- La clé RIB, à mon avis n'est pas sauvegardée, mais fait l'objet d'un calcul, permettant ainsi le contrôle au moment de la saisie des données.
- Cette table pourrait contenir également en option :
- Le montant maximum que le pilote accepte d'être prélevé. Le solde étant reporté sur le ou les mois suivants.
- Le montant minimum que le pilote accepte d'être prélevé (cas d'une thésaurisation acceptée par le pilote et l'aéroclub, afin de lisser les prélèvements sur l'année).
- La formule du prélèvement automatique implique une gestion calendaire, c'est à dire que les pilotes paient au mois. Par contre, si la gestion se fait au fil de l'eau ("je vole donc je paie aussitôt après le vol"), la gestion des prélèvements devient trop lourde à gérer parce que il faut envoyer des prélèvements trop fréquemment.
- Fonctionnement :
- GESTION des PILOTES : le pilote intéressé remplit une autorisation de prélèvement (2 parties). La première est archivée à l'a/c et la 2e est envoyée à l'établissement teneur du compte du pilote. La fiche pilote est mise à jour.
- SAISIE des VOLS : lors de la saisie des vols si le pilote est au prélèvement automatique, il ne lui est pas proposé de payer ce vol.
- GESTION DES COMPTES
- La création du fichier de prélèvement ne se fait qu'une fois par mois (en début de mois) et sur commande du gestionnaire. Pourrait être automatisée. La mise à jour des comptes pilotes s'effectuant à la date de prélèvement.
- Il y a réémission manuelle du fichier de prélèvement lors d'un rejet, contenant uniquement le ou les prélèvements rejetés après accord avec le ou les pilotes.
--philepil 22 Nov 2005 à 15:40 (CET) modifié --philepil 24 Nov 2005 à 10:36 (CET)
Gestion de la cuve de carburant
Puisque lors de l'ouverture du vol on renseigne les volumes avitaillés, il devrait être possible sans trop de code supplémentaire, de rajouter une ou des tables dans la configuration du club, qui permettraient de gérer les cuves carburants. Les éléments à préciser seraient :
- Dans une première table qui listerait les cuves :
- le volume potentiel de chaque cuve
- le volume d'alerte, qui donne lieu à un e-mail vers la personne responsable de la cuve
- le type de carburant
- le nom ou numéro de la cuve
- Dans une seconde table, la liste des "pleins" (=remplissage de la cuve) et des "dé-pleins" (=avitaillement des avions).
Il serait alors possible de soustraire le volume avitaillé au volume de la cuve pour savoir combien il en reste.
Dans une autre zone de l'admin, rajouter un menu pour saisir le volume que l'on met lors du remplissage de la cuve.
Ceci étant à multiplier par le nombre de cuves que l'on gére. Je n'ai aucune idée du nombre de cuves dans un aéroclub, mais je pense que mettre 2 cuves couvre pas mal de besoin, une cuve de 100LL et une de jet a1.
Le plus simple est de faire une table qui liste les cuves ;-) L'utilisation de la cuve pourrait être dérivée pour lister les pleins sur certaines pompes où le club fait des paiements particuliers (cartes, etc.). Cependant je reste sceptique sur la qualité de l'information fournie par les pilotes--Christophe 18 Nov 2005 à 13:47 (CET)
S'il y a des interventions régulières de maintenance à réaliser sur la cuve on peut les programmer de la même façon que l'expiration des licences.
Pour l'alerte, un message lors du login des pilotes (comme les alertes de cotisation / expiration des licences) et un mail vers "l'administrateur des cuves".
--Utopie 17 Nov 2005 à 11:22 (CET)
Le dernier point reste assez lourd à mettre en oeuvre ;-)--Christophe 18 Nov 2005 à 13:47 (CET)
Le plus gros problème à mon avis, c'est que peu de clubs sont les utilisateurs uniques de leur cuve. En général, il n'y a qu'une pompe par aérodrome, donc tous les clubs de la plateforme, les privés basés et les avions de passage débitent aussi sur la cuve. Il faudrait alors que tous les utilisateurs remplissent un formulaire sur une borne disposée à coté de la pompe ! peu réaliste. --Jdepardieu 16:26, 4 December 2005 (CET)
Armoire à clé
cf. KeyManagement
Cahier de réservation
Surréservation & réservation par type
Existe dans la 1.2. Implémentation officielle dans la 2.0 grâce à l'ajout de la notion de type d'avion. A rajouter :
- Nouveau champs dans la table aircraft permettant de définir si un avion est réel ou virtuel (pour le surbooking). Cela permettrait une coloration différente pour chaque ligne d'avion dans le cahier.
Formulaire de résa
Champs commentaire
rajout dans la table parameter d'une ligne concernant l'utilisation du champ commentaire de la table booking et suppression du flag s'y rapportant dans le champ FLAGS de la table CLUBS (bit comment_book_box). Ainsi, dans parameter, il pourrait y avoir la présence d'une ligne CODE='COMMENT' avec :
- ENABLED = 1 ou 0
- INT_VALUE = 1 ou 0 si 1 alors cela voudrait dire "renseignement de ce champ obligatoire".
- CHAR_VALUE = si non vide, alors l'intitulé "commentaire" dans le formulaire de réservation serait remplacé par le contenu de ce champ. Cela permettrait notamment de personnaliser la signification de ce champ notamment si son remplissage est obligatoire.
Résas
Immobilisations
Possibilité de rajouter des formes d'immobilisations spécifiques (manifestations diverses comme "voyages" ou "Jour le plus long") sans que ce soit considéré comme une résa (donc plutôt assimilable à l'immo méca).
Possibilité de bloquer les réservations pour un avion, sans supprimer les réservations déjà posées, afin de limiter les vols jusqu'à une prochaine visite programmée, par exemple. L'immobilisation se loge automatiquement dans les trous des réservations, qui restent actives.
Comptes pilotes
Saisie des paiements
Créer deux paramètres permettant de définir un montant minimum et un montant maximum de paiement.
IMPORTANT : Ne pas oublier la carte de crédit dans les modes de règlement !--Sadoche 18:02, 15 April 2006 (CEST)
Cotisation aéroclub
Il faut prévoir une zone pour effectuer le paiement des cotisations, avec la possibilité de saisir à quelle date on commence.
Côté admin, il faudra aussi prévoir une zone dans les paramètres du club pour spécifier :
- Le montant de la cotisation
- La date à partir de laquelle le club délivre les licences.
Côté de l'utilisateur ayant le droit de délivrer les licences :
- une zone de saisie pour la date de la délivrance de la licence
- gestion du mode de paiement
- une combo de sélection pour le choix de l'utilisateur
- un système de mise à jour automatique du paiement de la cotisation.
--Utopie 21:09, 18 December 2005 (CET)
Le paiement des cotisations n'a pas besoin d'être prévu en dur dans OF : il suffit de créer un objet divers (comme pour les casquettes) de type cotisation.--Christophe 13:13, 21 December 2005 (CET)
Alerte pour utilisateur spécial
Les clubs dont les membres n'ont pas ou peu d'accès, OF peut être utilisé par un utilisateur spécial qui aurait une remontée des diverses infos des utilisateurs :
- cotisations expirées
- licences expirées
- délai entre 2 vol espacés de x mois (paramétrable en admin) pour pouvoir avertir ou interdire une réservation
Cela peut paraître "big brother" mais comme dit plus haut, c'est à destination des clubs dont les membres ne sont pas équipés d'un accès internet ou sont réfractaires à l'utilisation des ordinateurs (ça existe encore...), cela sert donc à l'utilisateur spécial d'avoir des infos concernant "l'état" des membres.
--Utopie 21:28, 18 December 2005 (CET)
Statistiques
Outils à creuser
- Classe JpGraph
A implémenter
- Nombre d'heures vols par mois/années
- % d'utilisation d'un avion par type de vol par mois/années
- export pour les administrations de tutelle et les fédérations (ex: DGAC)
Gestion des terrains
Créer une interface permettant d'importer une base de données de terrains en provenance de diverses sources comme celle d'Eurocontrol.
Exemple d'une telle interface : NavAide
Sureté
- Créer un tableau affichant les IPs et Logins bloqués qui permettrait de débloquer à l'unité, ou carrément de purger les tables.
A trier (OF 2.x)
- Possibilité de paramétrer pour le club, la page d'accueil souhaitée : fenêtre de login normale (telle qu'actuellement) ou fenêtre "publique", avec le cahier avions/instructeurs ou selon sélectionné dans les préférences individuelles, qui reste affichée pour un utilisateur "sans droits", et qui fait office d'écran de veille.
- Prévoir la possibilité de mettre un message paramétrable dès la page d'accueil (fenêtre de login) (comme sur la page principale, mais visible dès la fenêtre de login et différent de celui de la page principale).
- Système de messagerie interne permettant la diffusion d'informations/contacts via l'appli. Cette solution permet de rentrer en contact avec quelqu'un qui ne veut pas "publier" ses données (l'appli se chargeant de faire le relai de manière transparente).
- Possibilité pour un membre de "se cacher" des autres (ie : de ne pas être dans la liste des membres ni d'apparaitre en clair dans le cahier de résa). Cette possibilité serait subordonnée à l'activation de l'option idoine au niveau club (ainsi si un club ne veut pas que les membres se cachent il pourra ne pas activer l'option). Il faut également rajouter un droit au niveau des profils permettant de voir les membres cachés.
- limitation du nombre de résas par personne
- Affichage d'une barre indiquant l'heure actuelle (avec éventuellement planning déroulant)
- notion de capacité des réservoirs pour les types d'avion permettant de contrôler la quantité d'essence avitaillée.
- Prévoir un champ pour renseigner la couleur d'un avion.
Ça servira quand on génèrera automatiquement le plan de vol à partir de la résa ou de l'ouverture du vol ! :-)
- Séparer nettement l'heure (locale), peut-être à mettre juste sous le bandeau d'annonces, avec la mention :
« Aujourd'hui : date , heure » puis, nettement séparé, collé au tableau de réservation la date du jour de réservation, qui peut bien sûr être le même jour, mais aussi un jour très différent (là, pas besoin d'indiquer l'heure, mais éventuellement indiquer
« Réservations du : date du jour de résa »).
Pour continuer avec ce qui a été proposé plus haut, évidemment, la barre verticale de l'heure actuelle ne s'affiche que sur la tableau de résa du jour même.
- Récupérer lors de l'exportation sous excel les dates de validité des qualifications des pilotes
Réutilisation de la bdd
Mon idée est d'utiliser la base de donnée d'OpenFlyers en tant que source de publipostage. Nous avons déjà tout ce qu'il faut, il suffit à l'utilisateur de télécharger le connecteur. myodbc et de réaliser la connection dans le logiciel de traitement de texte. La seule contrainte c'est que l'utilisateur connaisse l'adresse et le mot de passe de la bdd. Sur un hébergement perso pas de problème, sur notre hébergement dédié je ne sais pas si l'utilisateur a accès à celui-ci.
ps : je mets la version française et anglaise, je ne suis pas sûr de la traduction.
My idea is to use the openflyers's database as source of mass mailing. We've got all what we need, the user just need to download the myodbc connector and connect it to his word processor. The only constraint is that the user need to know the login and password of the database, if he host himself, it's not a problem, but with our hosting i dont know if he know it
--Utopie 19:13, 20 January 2006 (CET)
Permettre l'accès aux bases de données d'Openflyers.org n'est pas envisageable.
Pour accéder aux informations stockées dans certaines tables, une interface XMLRPC a été développée (et peut être complétée sur demande).
Specs in english
Introduction
This place is to be use to write down various specifications in english.
The goal is to be understandable by our international users.
Improvements and Suggestions
Hi, I have these suggestions for the new version 2.0:
1. Possibility for the admin to set a time after that users cannot modify/delete their own bookings, but htese must be performed by a staff member. This because many times we see bookings at 8AM of the next day, then members delete the booking in the evening, so the next morning we open the club and we discover that it was not necessary to open so early because the flight was cancelled.
2. Possibility to change the e-mails format. I'd like to set an html page, where the admin can change tables, fonts and variables of the dynamic text. I suggest an easy page, editable through Dreamweaver, so most of webmasters can do it.
3. Graphic improvings, I know that simple graphic sometimes is useful, but also the appearance has importance!
For example, look at this bank website: website. It could be a good example for colours combination, and in particular for menus.
4. Before entering a booking, could be good thing to show a page with all datas inserted and with terms and conditions specified by the club for booking modifications/cancellations. At the bottom, the button "confirm", as when you book a flight of an airline.
5.Create a form where members can transmit payments details to the club, bankaccounts transfer orsomething compatible with paypal...--Stefano 17:21, 16 December 2005 (CET)
6. Create a field, like the acrual "comments", but reserved for the staff users only, that other users cannot view it.--Stefano 12:39, 20 December 2005 (CET)
7. Create search for all flights booked by a member between two dates--Stefano 12:39, 20 December 2005 (CET)
8. When a booking is modified or deleted not by the member, but by the staff, should appear a field where the staff user indicates the reason of the action. This should be included in the email sent to the user as well.--Stefano 20:35, 1 January 2006 (CET)
9. Possibility for the user to view his money balance and receipts (in pdf?), like an online billing application.--Stefano 20:35, 1 January 2006 (CET)
Some additions from Xavier:
10. Possibility for someone from administration to Validate a Booking; this should be visual and notified. This should give the chance to the admin to check organizational parameters that must be met to accept the booking (e.g. in my club, you must have flown the plane within the last 3 months, and I think OF2.0 will do this, but it is always easier to "sell" if you can say that they will be able to validate) [Xavier 20 Jan 2006]
11. I think a kiosk mode would be very useful for the club offices. It should be designed so that a touch screen can be used -i think people is more used to touch screens than mouses- [Xavier 20 Jan 2006]
