Evolution #80
ferméRévision globale du code
Ajouté par Grégory MARIGOT - TEICEE il y a plus de 13 ans. Mis à jour il y a environ 13 ans.
100%
Description
- renommage de champs sur la BDD pour mieux coller à la logique objet
- adaptation du schéma et des noms des classes/méthodes/attributs correspondant
- usage plus poussés des composants du framework symfony
- nettoyage des classes ou méthodes inutiles et uniformisation du code
Mis à jour par Grégory MARIGOT - TEICEE il y a plus de 13 ans
- % réalisé changé de 0 à 20
Modifications de la base de données :¶
Dans la base de données, certaines tables comportent des noms de colonnes correspondant à la version originale d'EPNadmin mais moins à la logique du framework Symfony. De ce fait, la génération automatique des objets de base avec Propel donne des classes et méthodes avec des noms peu pratiques (et moins standards).
Les tables concernants les équipements et les salles ont ainsi été revues.
La transformation des structures dans la BDD peuvent se faire avec les opérations suivantes :
DROP TABLE equipment_activities; ALTER TABLE equipment DROP FOREIGN KEY equipment_ibfk_1, DROP FOREIGN KEY equipment_FK_1; ALTER TABLE equipment_peripheral DROP FOREIGN KEY equipment_peripheral_FK_1, DROP FOREIGN KEY equipment_peripheral_ibfk_1; ALTER TABLE equipment_software DROP FOREIGN KEY equipment_software_FK_1, DROP FOREIGN KEY equipment_software_ibfk_1; ALTER TABLE equipment_link DROP FOREIGN KEY equipment_link_FK_2, DROP FOREIGN KEY equipment_link_ibfk_2; ALTER TABLE equipment_link DROP FOREIGN KEY equipment_link_FK_3, DROP FOREIGN KEY equipment_link_ibfk_3; ALTER TABLE equipment_link DROP FOREIGN KEY equipment_link_FK_1, DROP FOREIGN KEY equipment_link_ibfk_1; ALTER TABLE session_computer DROP FOREIGN KEY session_computer_FK_2, DROP FOREIGN KEY session_computer_ibfk_2; ALTER TABLE session DROP FOREIGN KEY session_FK_1, DROP FOREIGN KEY session_ibfk_1; ALTER TABLE rooms DROP FOREIGN KEY rooms_FK_1, DROP FOREIGN KEY rooms_ibfk_1; ALTER TABLE uses DROP FOREIGN KEY uses_FK_2, DROP FOREIGN KEY uses_ibfk_2; RENAME TABLE equipment TO equipment_computer; ALTER TABLE equipment_computer CHANGE eq_id id INT(11) NOT NULL AUTO_INCREMENT ALTER TABLE equipment_computer CHANGE eq_name name VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT ''; ALTER TABLE equipment_computer CHANGE eq_ro_id room_id INT(11) NOT NULL ALTER TABLE equipment_computer CHANGE eq_is_reservable is_reservable CHAR(1) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT 'n'; ALTER TABLE equipment_computer CHANGE eq_is_loanable is_loanable CHAR(1) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT 'n'; ALTER TABLE equipment_computer CHANGE eq_features features TEXT CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE equipment_computer CHANGE eq_description description VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE equipment_computer CHANGE eq_barcode barcode VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE equipment_computer CHANGE eq_serial_number serial_number VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE equipment_computer CHANGE eq_address address VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE equipment_computer CHANGE eq_purchase purchase TEXT CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE equipment_computer CHANGE eq_comment comment TEXT CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE equipment_computer CHANGE eq_image image VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE equipment_computer CHANGE eq_image2 image2 VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE equipment_peripheral CHANGE ep_id `id` INT(11) NOT NULL AUTO_INCREMENT; ALTER TABLE equipment_peripheral CHANGE ep_type `type` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL; ALTER TABLE equipment_peripheral CHANGE ep_description `description` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE equipment_peripheral CHANGE ep_features `features` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE equipment_peripheral CHANGE ep_st_id `structure_id` INT(11) NOT NULL DEFAULT '0'; ALTER TABLE equipment_peripheral CHANGE ep_is_reservable `is_reservable` CHAR(1) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL; ALTER TABLE equipment_peripheral CHANGE ep_is_loanable `is_loanable` CHAR(1) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL; ALTER TABLE equipment_peripheral CHANGE ep_barcode `barcode` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE equipment_peripheral CHANGE ep_serial_number `serial_number` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE equipment_peripheral CHANGE ep_purchase `purchase` TEXT CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE equipment_peripheral CHANGE ep_comment `comment` TEXT CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE equipment_peripheral CHANGE ep_image `image` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE equipment_software CHANGE es_id `id` INT(11) NOT NULL AUTO_INCREMENT; ALTER TABLE equipment_software CHANGE es_type `type` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL; ALTER TABLE equipment_software CHANGE es_title `title` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL; ALTER TABLE equipment_software CHANGE es_st_id `structure_id` INT(11) NOT NULL; ALTER TABLE equipment_software CHANGE es_barcode `barcode` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE equipment_software CHANGE es_licence `licence` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE equipment_software CHANGE es_purchase `purchase` TEXT CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE equipment_software CHANGE es_comment `comment` TEXT CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE equipment_software CHANGE es_is_reservable `is_reservable` CHAR(1) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE equipment_software CHANGE es_is_loanable `is_loanable` CHAR(1) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE equipment_software CHANGE es_image `image` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE equipment_link CHANGE el_eq_id `equipment_computer_id` INT(11) NOT NULL DEFAULT 0; ALTER TABLE equipment_link CHANGE el_es_id `equipment_software_id` INT(11) NOT NULL DEFAULT 0; ALTER TABLE equipment_link CHANGE el_ep_id `equipment_peripheral_id` INT(11) NOT NULL DEFAULT 0; ALTER TABLE rooms CHANGE ro_id `id` INT(11) NOT NULL AUTO_INCREMENT; ALTER TABLE rooms CHANGE ro_id_site `structure_id` INT(11) NOT NULL; ALTER TABLE rooms CHANGE ro_name `name` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT ''; ALTER TABLE rooms CHANGE ro_description `description` TEXT CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT ''; ALTER TABLE rooms CHANGE ro_is_collective `is_collective` CHAR(1) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT 'y'; ALTER TABLE rooms CHANGE ro_is_individual `is_individual` CHAR(1) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT 'y'; ALTER TABLE rooms CHANGE ro_nbr_of_computer `computers_nb` SMALLINT(11) NOT NULL DEFAULT 0; ALTER TABLE rooms CHANGE ro_services_id `services_list` VARCHAR(20) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT ''; RENAME TABLE rooms TO room; ALTER TABLE equipment_computer ADD CONSTRAINT equipment_computer_FK_1 FOREIGN KEY (room_id) REFERENCES room (id) ON DELETE CASCADE; ALTER TABLE equipment_software ADD CONSTRAINT equipment_software_FK_1 FOREIGN KEY (structure_id) REFERENCES structure (id) ON DELETE CASCADE; ALTER TABLE equipment_peripheral ADD CONSTRAINT equipment_peripheral_FK_1 FOREIGN KEY (structure_id) REFERENCES structure (id) ON DELETE CASCADE; ALTER TABLE session_computer ADD CONSTRAINT session_computer_FK_2 FOREIGN KEY (computer_id) REFERENCES equipment_computer (id) ON DELETE CASCADE; ALTER TABLE uses ADD CONSTRAINT uses_link_FK_2 FOREIGN KEY (us_id_equipment) REFERENCES equipment_computer (id) ON DELETE CASCADE; ALTER TABLE room ADD CONSTRAINT room_FK_1 FOREIGN KEY (structure_id) REFERENCES structure (id) ON DELETE CASCADE; ALTER TABLE session ADD CONSTRAINT session_FK_1 FOREIGN KEY (room_id) REFERENCES room (id) ON DELETE CASCADE;
Note : L'ajout de clés étrangères sur la table equipment_link n'est pas possible, cette table unique comportant des triplets alors que seuls 2 colonnes sont utilisées (c'est une table commune qui évite d'avoir 3 tables de liens en duo). La colonne non utilisée dans les liens valant 0, elle ne peut satisfaire la contrainte.
ALTER TABLE equipment_link ADD CONSTRAINT equipment_link_FK_1 FOREIGN KEY (equipment_computer_id) REFERENCES equipment_computer (id) ON DELETE CASCADE; ALTER TABLE equipment_link ADD CONSTRAINT equipment_link_FK_2 FOREIGN KEY (equipment_software_id) REFERENCES equipment_software (id) ON DELETE CASCADE; ALTER TABLE equipment_link ADD CONSTRAINT equipment_link_FK_3 FOREIGN KEY (equipment_peripheral_id) REFERENCES equipment_peripheral (id) ON DELETE CASCADE;
Edit : La table 'equipment_link' sera finalement remplacée (cf #79 et r330)
Mis à jour par Grégory MARIGOT - TEICEE il y a plus de 13 ans
- Statut changé de Nouveau à In Progress
- % réalisé changé de 20 à 50
Modifications publiées sur le svn (r324 et r325) :
Le schéma a été adapté avec les modifications apportées précédement dans la BDD.
Ainsi les classes générées en tiennent compte, ce qui change certains noms de classes, méthodes et attributs. Le code a donc été adapté en fonction, au moins pour les classes principales.
- les droits (app_module et app_module_rights)
- les GEPN et EPN (structure_groups et structure)
- les salles (room)
- validation des modèles (réécriture de méthodes, épuration du code inutile)
- amélioration des formulaires (usage de nouveaux widgets, paramétrage complet pour éviter les adaptation au niveau des templates)
- utilisation des filtres dans lib/filter (plutot que d'en ajouter dans /lib)
- mise en place de listes en place de tableau en dur dans le code
- revu complète des modules (actions et templates) pour prendre en compte ces changements (uniformisation et simplification du code)
Certaines autres parties ont eu quelques modifications pour s'y adapter (comme le layout général), sans pour autant être fonctionnelles pour le moment. Le même sort reste à venir pour les autres classes/modules.
Un travail de finalisation sera effectué après mise à jour de l'ensemble, il traitera notamment :- des traductions de libellés
- de la validation des fonctionnalités attendues
- du controle fin des permissions sur les actions et formulaires
Mis à jour par Grégory MARIGOT - TEICEE il y a plus de 13 ans
Modifications publiées sur le svn (r326 et r327) :
Quelques compléments rajoutés pour l'adaptation du code.
Mise en place du filtrage sur la liste des salles par GEPN ou EPN.
Suite de l'uniformisation du code sur les objets et modules déjà traités.
Ajout d'un fichier Javascript "functions.js" inclus par défaut pour accueillir des fonctions utilitaires générales (remplace "others.js" qui était spécifique à EPNadmin original et donc inutile)
Mis à jour par Grégory MARIGOT - TEICEE il y a plus de 13 ans
- % réalisé changé de 50 à 70
Modifications publiées sur le svn (r329) :
Le module 'user' (liste/création/édition de contacts) avec ses objets associés a été entièrement revu, suivant les mêmes objectifs que pour les modules précédement traités.
A noter que les méthodes de recherche par "groupe" (selon les affections directeur/animateur et/ou profil type des comptes) méritent encore d'être revues, mais c'est surtout l'utilisation de ces groupes qui serait à repenser... A voir avec une évolution sur la gestion des droits.
La page affichant la liste des contacts a nécessité une attention particulière. Un système de pagination lui avait été ajouté (#35) vu qu'il était devenu bien trop lourd de tout afficher en mode admin. Cette modification, bien que fonctionnelle, compliquait le code et était peu réutilisable.
La mise en place d'une pagination a donc été repensée en différents composants externes, permettant de clarifier le code et de l'intégrer facilement. Le système fonctionne en accord avec la présence de filtres divers et permet toujours le tri par colonne en s'interfaçant sur le plugin jquery_tablesorter.
Ces dispositifs pourront facilement être intégrés à toute autre liste pouvant nécessiter une pagination.
Mis à jour par Grégory MARIGOT - TEICEE il y a plus de 13 ans
Modifications publiées sur le svn (r332) :
Révision de la gestion des codes INSEE pour répertorier les communes.¶
Quelques changements dans la BDD :- la table 'insee_town_county' est renommée en 'insee_town' pour plus de simplicité
- la colonne des pays (county) étant jugée facultative, elle dispose d'une valeur par défaut (chaine vide)
- la colonne des codes postaux passe en CHAR au lieu d'être en INT, ceci permettant de les enregistrer dans la table avec un 0 initial qui fait partie du format attendu d'un code postal.
- les codes postaux qui ne contenaient que 4 chiffres (pour les département 01 à 09) sont migrés pour leur ajouter le 0 initial
Détail des commandes SQL effectuées :
RENAME TABLE insee_town_county TO insee_town;
ALTER TABLE insee_town CHANGE county county VARCHAR(40) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '';
ALTER TABLE insee_town CHANGE postcode postcode CHAR(5) NOT NULL;
UPDATE insee_town SET postcode=CONCAT('0', postcode) WHERE postcode LIKE '____';
Les classes des objets correspondant ont été revues en conséquence de ces changements (renommage, y compris sur le 'I' majuscule des objets InseeTown pour respecter le standard, les objets précédents étant nommées inseeTownCounty). L'ensemble des méthodes ont été révisées selon les mêmes principes que précédemment (suppression de méthodes inutiles/peu pertinentes, ajout/réécriture d'autres...)
Un nouveau module 'insee_town' a été créé pour permettre l'administration de la liste. Il remplace le module 'insee_town_county' qui utilisait l' admin generator de Symfony. Ce système n'étant pas utilisé ailleurs et les besoins étant similaires aux autres modules, le même modèle d'actions/templates a été repris ici.
Le module 'address' a été supprimé : il ne servait qu'à répondre aux requêtes Ajax pour l'auto-complétion des champs de saisies des villes. Cette fonction se retrouve désormais intégrée dans le nouveau module 'insee_town'.
Au passage le système d'auto-complétion a lui aussi été revu :- les recherches ne sont lancées qu'à partir de 2 caractères saisis (1 seul auparavant)
- les correspondances sont recherchées avant tout avec le motif en préfixe (sur les noms de communes ou sur les codes postaux si le motif est numérique)
- si le nombre de résultats est inférieur à la limite max de résultats proposés, alors la recherche est complétée par les correspondances qui contiennent le motif (mais en conservant l'ordre à l'affichage)
- ainsi sur les codes postaux en particulier, une recherche en saisissant 14 ne renverra que des villes du calvados, et non tout code postal contenant 14
- pour les département 01 à 09, le changement en BDD avec l'intégration du 0 initial permet d'effectuer les recherches en saisissant le code postal (ou juste son début) avec le 0.
Note : la révision r333 apporte divers ajustement du code, dont les modifications dans les autres modules pour utiliser correctement ces nouveaux objets 'insee_town'.
Mis à jour par Grégory MARIGOT - TEICEE il y a environ 13 ans
Modifications publiées sur le svn (r336) :
Nouveau module à part pour les actions "My Info"¶
Il était nécessaire de distinguer les actions faites sur sa propre fiche d'usager, de celles qui peuvent être faites sur les fiches de n'importe quel usager (par les animateurs par ex). Un nouveau module est donc créé (user_myself) pour prendre en charge uniquement les actions liées à la fiche de l'utilisateur.
Ainsi le module "user" n'est utilisé que par les personnes autorisées à voir/éditer/supprimer... des usagers. Ceci permet une meilleure application des permissions en distinguant les droits accordés sur toutes fiches et ceux sur sa fiche.
Pour le moment, le nouveau module "myself" permet :
- de visualiser sa fiche (avec un rendu pouvant différer de celui du module "user", en particulier si certaines infos ne sont pas pertinentes ici)
- de modifier son mot de passe (comme auparavant)
- d'éditer sa propre fiche (encore une fois avec un formulaire adapté, seuls certains champs étant modifiables directement par l'utilisateur, les autres étant de la responsabilité des animateurs)
Pour une évolution future, ce module permettra aussi plus facilement de permettre aux usagers de s'enregistrer eux-même (avec un formulaire encore une fois adapté). Bien sur les comptes ainsi créés auraient un état spécial (préenregistrement) et nécessiterait la validation d'un animateur pour être fonctionnel. Mais celà permettrait de déléguer une partie de la tache des animateurs. (cf #82)
Mis à jour par Grégory MARIGOT - TEICEE il y a environ 13 ans
- % réalisé changé de 70 à 80
Modifications publiées sur le svn (r335) :
Généralisation des méthodes "retrieveBy" avec MyPropelBehaviorFilters¶
Les "Behaviors" de Propel permettent de définir un ensemble de méthodes qui seront automatiquement incluses lors de la génération des classes de base du modèle objet par Propel.
Celui-ci permet de dotter les classes peer de méthodes génériques pour effectuer des interrogations et obtenir les listes d'objets, en tenant compte du contexte de l'utilisateur (application de la politique de droits) mais aussi en affinant la recherche par des filtres personnalisables.
- criteriaFromContext() retourne un objet Criteria à partir du contexte de l'utilisateur (la liste des EPN et GEPN auxquels il appartient). La méthode peut récupérer le Criteria initial depuis l'objet Context fournit, il ne lui reste plus qu'à ajouter les jointures nécessaires (afin que la table 'structure' soit dans la requête).
- criteriaFromFilters() retourne un objet Criteria pour lequel divers filtres sont appliqués (d'après un hachage $filters fournit en paramètre). La méthode peut récupérer le Criteria initial depuis la méthode précédente afin que le contexte utilisateur soit toujours appliqué. Il lui reste à traiter chaque élément du hachage $filters pour ajouter les clauses SQL correspondantes.
Un attribut nommé default_orders est également à redéfinir dans chaque classe peer. Il s'agit de la liste des champs à utiliser pour le tri par défaut des résultats. C'est en fait un hachage plutot qu'une liste : le nom de colonne est en clé, la valeur servant à indiquer le sens ('ASC' ou 'DESC').
Enfin, trois méthodes statiques sont automatiquement disponibles grâce au behaviors. Elles sont génériques et ne nécessitent aucune retouche, faisant appel aux méthodes 'criteriaFrom' exposées précédement :- retrieveByContext() retourne la liste des objets, sans filtres spécifiques, seul le contexte utilisateur est appliqué pour satisfaire la politique de droits.
- retrieveByFilters() retourne la liste des objets avec application de filtres divers passés en paramètres (via le hachage $filters['nom_du_filtre'] = 'valeur_du_filtre' transmis), et toujours du contexte utilisateur.
- getPager() fonctionne de la même manière que retrieveByFilters, mais retourne un objet sfPropelPager au lieu d'une simple liste d'objets, permettant la pagination des résultats. Le numéro de page ainsi que le nombre d'éléments par page sont données en paramètres au sein du hachage $filters.
A chaque fois l'ordre par défaut est appliqué. Pour les deux dernières méthodes, un ordre spécifique peut être transmis, qui précédera alors le tri par défaut.
Ces méthodes génériques répondent à la majorité des besoins d'interrogations sur les classes peer. Leur usage est relativement simple, il devient alors plus aisé d'appliquer la politique de droits, de permettre des filtres variés sur les listes et d'y ajouter un système complet de pagination.
Le code peut ainsi être nettoyé de multiples méthodes de recherches personnalisées moins puissantes et obsolètes.
- sfGuardUserProfile : liste des usagers
- InseeTown : liste des villes (code insee)
- StructureGroup : liste des GEPN
- Structure : liste des EPN
- Room : liste des salles
- EquipmentComputer : liste des postes
- EquipmentPeripheral : liste des périphériques
- EquipmentSoftware : liste des logiciels
- Session : liste des sessions
Note : l'usage du behavior a aussi été évoqué au sujet de l'application de la politique de droits (cf #78 note-6)
Mis à jour par Grégory MARIGOT - TEICEE il y a environ 13 ans
Modifications publiées sur le svn (r341 et r343) :
Généralisation de la gestion des fichiers liés avec MyPropelBehaviorUploads¶
Certains objets disposent de fichiers qui leurs sont attachés, dont seul le nom est stockés dans la base de données, le fichier étant rangé dans l'arborescence du filesystem. Il s'agit typiquement d'images mais pas uniquement (d'où le nom initial MyPropelBehaviorImages, renommé sur la r343), que les formulaires d'édition proposent de télécharger (upload).
Ce Behavior permet d'enrichir les classes de base générées par Propel de plusieurs méthodes très utiles pour une bonne exploitation de ces fichiers :- getUploadPath($filename="") retourne le chemin filesystem complet vers le dossier contenant les fichiers (ou le chemin du fichier si son nom est transmis)
- getUploadWebPath($filename="") retourne le chemin web absolu vers le dossier (ou vers le fichier si son nom est transmis)
- getUploadName($field) retourne le nom du fichier d'après le nom du champs BdD (wrapper vers la méthode get associée)
- getUploadFile($field) retourne le chemin web du fichier d'après le nom du champs BdD (enchaine getUploadWebPath et getUploadName, mais en retournant false si le champs est vide)
Afin de fonctionner pour chaque type d'objet, seule une méthode est à redéfinir dans les classes : getUploadFolder() qui construit le chemin du sous-dossier adéquat (le dossier de base étant celui des uploads). Si le chemin définitif contient des références à l'objet ou à ses parents (ie numéro de sa structure) alors un chemin temporaire doit être retourné (car sur un formulaire de création, les références ne sont pas forcément connue avant l'enregistrement dans la BdD)
De plus, le Behavior ajoute la présence de deux listes qui restent à spécifier :- $upload_files : les noms des champs concernés (colonne BdD), contenant des noms de fichiers de type image
- $upload_images : les noms des champs concernés (colonne BdD), contenant tout autre type de fichiers
- getUploadFileList() retourne la liste $upload_files
- getUploadImageList() retourne la liste $upload_images
- getUploadList() retourne la concaténation des listes $upload_files et $upload_images
- setUploadFileList($field, $infos) ajoute un élément à la liste $upload_files
- setUploadImageList($field, $infos) ajoute un élément à la liste $upload_images
- getUploadImageGallery() retourne le chemin web de tous les fichiers de type image existants -> utile pour générer l'affichage de toutes les images uploadées.
- moveAllUploads($srcfolder, $newfolder=NULL) déplace tous les fichiers pouvant se trouver dans le dossier source indiqué vers le dossier de destination (par défaut celui obtenu par getUploadPath()) -> utile pour ranger les fichiers uploadés dès le formulaire de création du dossier temporaire vers le dossier final.
- deleteAllUploads($folder=NULL) supprime tous les fichiers uploadés associés à l'objet -> utile pour nettoyer le dossier en postDelete de l'objet.
Modifications effectuées dans la base de données¶
Ces changements ont été l'occasion de renommer certaines colonnes pour mieux harmoniser l'ensemble :
ALTER TABLE structure_group CHANGE logo_filename image_logo VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE structure CHANGE map_filename image_map VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE structure CHANGE logo_filename image_logo VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE structure CHANGE outside_photo_filename photo_out VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE structure CHANGE inside_photo1_filename photo_in1 VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE structure CHANGE inside_photo2_filename photo_in2 VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE structure CHANGE inside_photo3_filename photo_in3 VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE room CHANGE photo_in_1 photo_in1 VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE room CHANGE photo_in_2 photo_in2 VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL; ALTER TABLE room CHANGE photo_in_3 photo_in3 VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL;
De plus, certains des noms de fichiers enregistrés sont également à changer :
UPDATE room SET photo_in1=REPLACE(photo_in1,'in_','in'), photo_in2=REPLACE(photo_in2,'in_','in'), photo_in3=REPLACE(photo_in3,'in_','in'); UPDATE structure SET image_map=REPLACE(image_map,'_filename',''), image_logo=REPLACE(image_logo,'_filename',''), photo_out=REPLACE(photo_out,'outside_photo_filename','photo_out'), photo_in1=REPLACE(photo_in1,'inside_photo1_filename','photo_in1'), photo_in2=REPLACE(photo_in2,'inside_photo2_filename','photo_in2'), photo_in3=REPLACE(photo_in3,'inside_photo3_filename','photo_in3');
Afin de conserver la cohérence des données existentes, les fichiers stockés sont aussi à renommer :
rename '_filename' '' web/uploads/epn/*/*
rename 'inside_photo' 'photo_in' web/uploads/epn/*/*
rename 'outside_photo' 'photo_out' web/uploads/epn/*/*
find web/uploads/epn/*/* -type d -regex '.*/[0-9]+' -execdir mv {} ./room_`basename {}` \;
rename 'in_' 'in' web/uploads/epn/*/*/*
Edit du 22/03 - Gestion des vignettes¶
Modifications publiées sur le svn (r400 à r403) :
Les méthodes du Behaviors intègrent maintenant le support de vignettes (cf #94 pour plus de détails)
Une nouvelle tâche Symfony permet la migration des images existantes (cf #93)
Mis à jour par Grégory MARIGOT - TEICEE il y a environ 13 ans
Mis à jour par Grégory MARIGOT - TEICEE il y a environ 13 ans
- % réalisé changé de 80 à 90
Modifications publiées sur le svn (r385) :
Mise en place d'une relation 1:1 entre les tables users et profiles¶
La table sf_guard_user ne gère que les données minimales d'un compte usager (login, mot de passe...). Elle est accompagnée d'une table sf_guard_user_profile pour lui ajouter tout autre information de profil. Cette dernière dispose d'un champs user_id qui est le lien vers le compte correspondant (clé étrangère vers l'id de sf_guard_user).
Suppression de la clé primaire auto-incrementale des profils¶
La table des profils disposait également d'un champs id, faisant office de clé primaire en autoincrement. Cette colonne s'avère inutile, créant un ID supplémentaire sans intérêt. De plus sa présence laisse supposer une relation 1:n entre users et profiles.
Pour simplifier et rendre les choses plus claires, le champs ID des profils est purement supprimé. Le champs USER_ID (la clé étrangère) est tout à fait capable d'être également la clé primaire. Ce changement affirme une relation 1:1 entre users et profiles.
Modification des références des usagers¶
Le champs reference du profil est généré après l'insert, en utilisant le numéro du département de l'EPN de rattachement puis un numéro unique récupéré de l'ID incrémental. Ce dernier disparaissant, c'est la colonne USER_ID qui sera utilisée de la même manière.
Par contre pour tous les comptes déjà créés, les références basées sur l'ancien ID ne sont plus cohérente. Il est donc nécessaire de les migrer toutes avec l'utilisation du champs USER_ID.
Opérations effectuées sur la BdD¶
Suppression du champs ID remplacé par USER_ID :
ALTER TABLE sf_guard_user_profile DROP id; ALTER TABLE sf_guard_user_profile ADD PRIMARY KEY (user_id); ALTER TABLE sf_guard_user_profile DROP INDEX sf_guard_user_profile_FI_1; ALTER TABLE sf_guard_user_profile DROP FOREIGN KEY sf_guard_user_profile_FK_1; ALTER TABLE sf_guard_user_profile ADD FOREIGN KEY (user_id) REFERENCES sf_guard_user(id) ON DELETE CASCADE; ALTER TABLE sf_guard_user_profile ADD FOREIGN KEY (structure_id) REFERENCES structure(id) ON DELETE CASCADE;
Regénération des références des usagers :
UPDATE sf_guard_user_profile, structure, structure_group SET sf_guard_user_profile.reference = FLOOR(structure_group.code_insee / 1000)*1000000 + user_id WHERE structure_id=structure.id AND structure_group_id=structure_group.id
Mis à jour par Grégory MARIGOT - TEICEE il y a environ 13 ans
Modifications publiées sur le svn (r404) :
Révision du module de facturation¶
La table user_invoice bénéficie du behavior Propel "filters", la classe de l'objet et la classe peer ont été revu en conséquence (méthodes standart de recherche par filtres et contextes).
Le module user_invoice mis en place dispose des actions classiques : index, new/create, edit/update, delete.
Les permissions sur ce module sont accordées spécifiquement via un nouveau module applicatif défini dans la gestion des droits.
Le module général permet de gérer l'ensemble des factures auxquelles ont a accès, son usage est normalement restreint aux animateurs. Un lien pour s'y rendre est ajouté dans le menu principal de l'application. Il est possible d'exporter en CSV l'ensemble des factures.
De plus les factures de chaque usager sont consultables à partir des fiches usagers. Un lien vers le formulaire de création y est également disponible, avec pré-remplissage du nom de l'usager.
Enfin la partie "My info" permettant à tout utilisateur de voir les informations liées à son compte EPN propose également la liste des factures de l'usager.
Gestion des crédits des usagers¶
La table users_credits est abandonnée, les classes relatives sont supprimées du projet.
Le but est ici de rétablir la fonctionnalité de base d'édition de factures dans ProxyEPN.
Par la suite des adaptations et évolutions sur le format des factures seront certainement nécessaire.
De plus la gestion de crédits temps par l'application reste à définir.
Modifications dans la base de données¶
ALTER TABLE user_invoice CHANGE invoice_id reference INT(11) NOT NULL; ALTER TABLE user_invoice CHANGE credit_individual credit_individual INT(11) NOT NULL DEFAULT '0'; ALTER TABLE user_invoice CHANGE credit_collective credit_collective INT(11) NOT NULL DEFAULT '0'; ALTER TABLE user_invoice CHANGE rate_id subject_id INT(11) NOT NULL; ALTER TABLE user_invoice ADD FOREIGN KEY (structure_id) REFERENCES structure(id) ON DELETE CASCADE; DROP TABLE users_credits;
Sujet des factures¶
Modifications publiées sur le svn (r412) :
Le champs 'rate_id' associé à la liste 'rate.ini' était utilisé pour indiqué l'objet général de la facture (abonnement, forfait accès libre, etc...). Cela n'a donc rien à avoir avec le sens de la colonne, certainement prévue pour spécifier un taux de tva par exemple.
Pour cette raison le champs a été renommé en 'subject_id'.
De plus la liste du fichier 'rate.ini' est supprimée, remplacée par une liste éditable en base de données 'invoice_subject'.
Mis à jour par Grégory MARIGOT - TEICEE il y a environ 13 ans
- Statut changé de In Progress à Résolu
- % réalisé changé de 90 à 100
Renommage de champs dans la base de données¶
Propriétés propres aux sessions¶
Modifications publiées sur le svn (r418, r422) :
Afin d'avoir des noms de colonnes (BdD), de propriétés/méthodes (objets) ainsi que leurs libellés (i18n) plus cohérents, quelques champs supplémentaires ont été renommé :- table 'session' : title remplace name
- table 'session_training' : domain_id remplace training_name
- table 'session_training' : organization_id remplace company_id
- training_payer remplace main_payer
- training_organization remplace training_company
- training_domain remplace training_name
- training_status remplace user_status
Opérations de migration de la BdD :
ALTER TABLE session CHANGE name title VARCHAR(50) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL; ALTER TABLE session_training CHANGE training_name domain_id VARCHAR(100) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL; ALTER TABLE session_training CHANGE company_id organization_id INT(11) NOT NULL; UPDATE list_type SET name='training_payer' WHERE name='main_payer'; UPDATE list_type SET name='training_organization' WHERE name='training_company'; UPDATE list_type SET name='training_domain' WHERE name='training_name'; UPDATE list_type SET name='training_status' WHERE name='user_status';
Propriétés propres aux équipements¶
Modifications publiées sur le svn (r431) :
Afin de pouvoir les distinguer, les champs 'type' des logiciels & périphériques sont renommés :- table 'equipment_peripheral' : peri_type remplace type
- table 'equipment_software' : soft_type remplace type
Opérations de migration de la BdD :
ALTER TABLE equipment_peripheral CHANGE `type` peri_type VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL; ALTER TABLE equipment_software CHANGE `type` soft_type VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL;
Mis à jour par Grégory MARIGOT - TEICEE il y a environ 13 ans
- Statut changé de Résolu à Fermé