LABINVENT (InventIrap)

h1. Labinvent 2 (cakephp3) - Développement

Cette page décrit le processus de développement du logiciel, ainsi que les outils utilisés.

[ [[Labinvent_nouvelle_version|Retour au sommmaire]] ]

{{toc}}

---

h2. LIENS UTILES

* *DEMANDES (TODO LIST) : https://projects.irap.omp.eu/projects/inventirap/issues?query_id=222*

* *ROADMAP (VERSIONS) : https://projects.irap.omp.eu/projects/inventirap/roadmap?utf8=%E2%9C%93&tracker_ids%5B%5D=1&tracker_ids%5B%5D=2&tracker_ids%5B%5D=4&tracker_ids%5B%5D=5&tracker_ids%5B%5D=6&tracker_ids%5B%5D=7&tracker_ids%5B%5D=8&tracker_ids%5B%5D=9&with_subprojects=0&with_subprojects=1#version_2.5.x*

* Version numbering : http://semver.org

* HOWTO Format Redmine Wiki : http://www.redmine.org/projects/redmine/wiki/FrRedmineWikiFormatting

* [[Installation|Page wiki pour l'installation]]

* Migrations plugin: http://book.cakephp.org/3.0/fr/migrations.html

* Version majeure en cours (2.1): https://projects.irap.omp.eu/versions/101

* Liste complète des évolutions: https://gitlab.irap.omp.eu/epallier/labinvent/commits/master

* Browse files (gitlab): https://gitlab.irap.omp.eu/epallier/labinvent/tree/master

* Inventirap 1.3 (prod): https://inventirap.irap.omp.eu

* Inventirap 1.3 (test): https://inventirap-test.irap.omp.eu/

* *CakePhp*:

 * ROADMAP: https://github.com/cakephp/cakephp/wiki

 * *CONVENTIONS*: https://book.cakephp.org/3.0/fr/intro/conventions.html

 * Forum cakephp: http://discourse.cakephp.org

 * Quickstart tutorial: http://book.cakephp.org/3.0/en/quickstart.html

 * Bookmarker tutorial: https://github.com/cakephp/bookmarker-tutorial

 * Cakephp CRUD: https://github.com/FriendsOfCake/crud

---

h2. TODOLIST

*_NB: Cette liste est conservée ici à titre indicatif. Elle est exportée à partir de la liste des demandes : https://projects.irap.omp.eu/projects/inventirap/issues?query_id=222_*

* *FEATURE - GENERAL*

GENERAL - Test de l'application sur IE (Internet Explorer) et Chrome

GENERAL - Faire une mini doc destinée aux utilisateurs

GENERAL - LOG de toutes les actions effectuées sur les materiels, suivis, emprunts...

GENERAL - Parametrage application

GENERAL - Evolutions et bugfixes suite à retour du LAAS de vendredi 6/3/15

GENERAL - Stats d'utilisation

GENERAL - db-update: S'assurer qu'on peut exécuter N fois une requete sans problème

GENERAL - page accueil User: y décrire la procédure à suivre

GENERAL - bug sur désactivation emails: la validation génére alors une erreur "action impossible" (et d'autres opérations sans doute aussi)

GENERAL - implémenter le workflow d'envoi d'emails

GENERAL - Implémenter le workflow d'admission d'un matériel

GENERAL - Apropos : update, ajoute Alex, Thibault, Alexis...

GENERAL - Erreurs orthographe

GENERAL - Utilisateur privilégié : add champ description (pour écrire par exemple qu'il est responsable "adjoint"...)

GENERAL - Corrections/Evolutions demandées par l'IAS

GENERAL - install AVEC LDAP - Tester et trouver une solution pour qu'on puisse facilement ajouter une personne du LDAP en tant que superadmin (ou au moins expliquer sur le wiki quelle manip faire pour s'en sortir)

GENERAL - EMAIL 2 - on doit pouvoir configurer cette fonctionnalité (et l'activer ou la désactiver)

GENERAL - EMAIL 3 - (Demande electroniciens) Ca serait bien que le proprio de la fiche reçoive un email quand l???étiquette est imprimée, ou encore quand la fiche est validée (dans le but qu???il vérifie et complète cette fiche)

GENERAL - EMAIL 4 - Relance, Rappel d???intervention par email (cf https://projects.irap.omp.eu/projects/inventirap/wiki/Developpement#Rappel-dintervention-par-mail)

GENERAL - Passage à Php7

GENERAL - Eviter le bug du passage au LDAP qui supprime l'accès au site !!! (expliquer la procédure à suivre sur le wiki)

GENERAL - Groupes - Rendre configurable le label "groupe métier" et "groupe thématique" (les usages peuvent être différents selon les labos, ex: "groupe projet", "groupe technique", ...)

GENERAL - TESTS - Ajouter des tests pour tester différentes autorisations (« tel profil a le droit de faire telle action et voit telle(s) choses »)

GENERAL - Listes - Surligner ligne quand "Mouse over" (Javascript)

* *FEATURE - MATERIELS*

MATERIEL - Date de sortie

MATERIEL - nouvelles catégories informatique : tablette et hybride

MATERIEL - Modifier un matériel VALIDATED

MATERIEL - vue 'find' à paginer ?

MATERIEL - changement de proprio en gros

MATERIEL - Find/ Erreur recherche lors de l'utilisation des dates

MATERIEL - materiel/find : ameliorer la recherche dans le champ général "Recherche"

MATERIEL - ajout champ pour materiel de projet 

MATERIEL - doctype: ajouter "devis"

MATERIEL - date commande ne doit pas être obligatoire

MATERIEL - bug sur modif date livraison => devrait updater date fin garantie

MATERIEL - bug validation : on ne devrait pas pouvoir valider alors que fournisseur est vide

MATERIEL - Materiel/Valider: la liste des champs obligatoires avant validation doit s'adapter à ce qui RESTE encore vraiment nécessaire (Nom propriétaire, Fournisseur, Numéro de commande, Organisme, prix et date de reception)

MATERIEL - Matos/Création: date de réception ne doit pas être inférieure à date de commande !!!

MATERIEL - Matos/Edition et Validation bug: mails envoyés en DOUBLE !!!

MATERIEL - Responsable et Admin/Accueil: "Voir mes matériels" => à DESCENDRE tout en bas + "Voir les matériels A VALIDER" => à REMONTER tout EN HAUT

MATERIEL - Ajouter un champ "Durée de garantie" sur la fiche matériel, et mettre le nom du pc et date fin garantie en rouge quand il n'est plus sous garantie (sauf si la durée de garantie n'est pas précisée)

MATERIEL - Doc admission et doc sortie (improved)

MATERIEL - ajouter impression de la fiche

MATERIEL - Recherche : bouton "Rechercher" amélioré

MATERIEL - Pour la partie administrative, la validation doit permettre l'édition de la fiche officielle d'inventaire transmise à la tutelle. Permettre l'édition de cette fiche

MATERIEL - Gestionnaire de référence (obligatoire)

MATERIEL - Check Date achat <= Date Livraison !!!

MATERIEL - Ajouter un statut « désinventorié » ou «amorti ? » (à réfléchir)

MATERIEL - Ajouter colonne statut « hors service » dans la vue "liste des matériels" 

MATERIEL - N° série : à remettre dans la section informations (pour que tout le monde le voie)

MATERIEL - Empêcher duplication d'une fiche matériel si même numéro de série

MATERIEL - Le champ "Local de stockage" a-t-il disparu ??? => à remettre

MATERIEL - Site : passer ce champ à optionnel (ou cacher)

MATERIEL - find - Redirection apres action (changeStatus & delete)

* *FEATURE - ETIQUETTES*

ETIQ - Installation des dernières etiqueteuses

ETIQ - Installation des dernières etiqueteuses (déjà achetées, et dans le bureau de Etienne)

ETIQ - Matos/Etiquette: on ne doit pas pouvoir imprimer l'étiquette d'un matériel qui est CREATED (seulement s'il est VALIDATED)

ETIQ - installer etiqueteuses sur les postes clients

ETIQ - installer etiqueteuse sur Mac

ETIQ - installer etiqueteuse sur Win7 et Win10 et expliquer la procédure sur wiki-install (donner aussi url vers logiciel dymo DLS)

* *FEATURE/ AUTHENTIFICATION ET AUTORISATIONS (ACL)*

ACL - liste deroulante pour changer rapidement de profil (superadmin only)

ACL - rendre les autorisations configurables via une table de config dans la BD et un formulaire web permettant de le modifier

ACL - Vérifier qu'on ne peut vraiment plus se connecter par ldap SANS mot de passe !!!

ACL - bug sur ajout utilisateur privilégié en mode LDAP

ACL - Matos/Validation: Responsable ne doit pas pouvoir valider un matériel administratif (>800E)

ACL - matos/création: mail à l'administration devrait être fait seulement si la case "inventaire>800???" est coché

ACL - TEST: admin doit pouvoir voir les matériels archivés, et les désarchiver au besoin

ACL - Accueil/Responsable: voir les matériels à valider : uniquement si < 800E

ACL - Optimisation Emails: l'initiateur d'une action ne doit pas recevoir d'email à la suite de sa propre action !!!

ACL - Matos/Création: on ne devrait pas pouvoir créer un matériel "inventoriable" sans donner son prix

ACL - Ca serait bien que le proprio puisse modifier sa fiche, une fois créée, mais aussi même après qu'elle ait été validée. Attention, la modification post-validation ne peut porter que sur les renseignements techniques complémentaires

ACL - (IRAP) Valider le doc ACLs (tester que c???est bien ce qui est mis en place réellement sur le site inventirap du labo IRAP) 

* *FEATURE - SUIVIS*

SUIVI - Ajouter plusieurs documents : photo, docs

SUIVI - modifs + champs dans table suivi

SUIVI - Suivis par fournisseur: ajouter la colonne "fournisseur" dans Suivi pour pouvoir trier la vue par fournisseur

SUIVI - relance : trouver un moyen de relancer automatiquement les suivis périodiques (ou bien avec une date programmée)

* *FEATURE - EMPRUNTS*

EMPRUNT - rappel - Si emprunt, mail rappel a l'emprunteur avant echeance

EMPRUNT - dates: afficher les dates d'emprunt et de retour (date emprunt doit être obligatoire)

---

h2. TODOLIST (OLD)

*_NB: Cette liste est OBSOLÈTE (ici à titre indicatif, pour se souvenir des retours de réunion)_*

*Demandes des utilisateurs (transmises par D. Rambaud le 19/12/16) :*

* Ca serait bien que le proprio de la fiche reçoive un email quand l'étiquette est imprimée, ou encore quand la fiche est validée => dans le but qu'il vérifie et complète cette fiche

* Ca serait bien aussi que le proprio puisse modifier sa fiche, une fois créée, mais aussi même après qu'elle ait été validée. Attention, la modification post-validation ne peut porter que sur les renseignements techniques complémentaires.

*Suite à réunion du 27/10/16 avec le LATMOS, constat des modifs nécessaires:*

* L'étiqueteuse semble ne plus fonctionner alors qu'elle fonctionnait avant...

* Ajouter un champ "Titre du mail" dans la liste des emails envoyés, pour qu'on puisse configurer le titre du mail envoyé (ex: [LABINVENT])

* Check Date achat <= Date Livraison !!!

* Ajouter un statut : ajouter un statut « désinventorié «  ou «amorti ? » (à réfléchir)

* Ajouter colonne statut « hors service » dans la vue "liste des matériels"

* N° série : à remettre dans la section informations (pour que tout le monde le voie)

* Empêcher duplication d'une fiche matériel si même numéro de série

* Importation depuis Excel

* Le champ "Local de stockage" a-t-il disparu ??? => à remettre

* Site : champ optionnel

* Champs optionnels: de manière générale, il faudrait pouvoir configurer quelques champs comme optionnels (certains champs doivent bien sûr absolument rester obligatoires)

* (temporairement, on peut se contenter de CACHER certains champs, comme par exemple le champ "Site")

* Suivis par fournisseur: ajouter la colonne "fournisseur" dans Suivi pour pouvoir trier la vue par fournisseur

* Suivis relance : trouver un moyen de relancer automatiquement les suivis périodiques (ou bien avec une date programmée)

* Emprunt dates: afficher les dates d'emprunt et de retour (date emprunt doit être obligatoire)

* Matériel gestionnaire: obliger la personne qui crée une fiche matériel à choisir un gestionnaire (via une liste) (et avertir automatiquement ce gestionnaire par mail)

* supprimer profil AdminPlus, inutile

*Suite à l'installation à l'IRAP du 21/01/2016*:

- Si elle existe, supprimer table "fichiers"

- Sauvegarder les utilisateurs

- Transformer table "utilisateurs" en "users"

- Ajout table "configuration"

- Ajout clé étrangère emprunts (site_id)/suivis (type_suivi_id)

- Transformation des données correspondantes

- Suppression ancien champ emprunt (e_lieu_stockage), suivis (type_intervention)

*Suite à l'installation à l'IAS du 09/03/2015*

- Ajout table "organismes", "type_suivis", "sites"

- Ajout clé correspondante dans table "matériels"

- Transformation des données correspondantes

- Suppression anciens champs

- Ajout table "documents"

- Sauvegarder les utilisateurs

- Transformer table "utilisateurs" en "users"

- Ajout table "configuration"

- Ajout clé étrangère emprunts (site_id)/suivis (type_suivi_id)

- Transformation des données correspondantes

- Suppression ancien champ emprunt (e_lieu_stockage), suivis (type_intervention)

---

h2. Schéma de la base de données (v2.6)

{{thumbnail(BDD_schema.png, size=2000, title=Labinvent data model 2.6)}}

h2. Schéma de la base de données (v2.0)

{{thumbnail(BDD_IRAP.png, size=2000, title=Labinvent data model 2.0)}}

---

h2. Utilisation du serveur web de dev de CakePHP (à la place de apache)

/!\ Votre serveur MySQL doit être lancé !!!

* Se placer à la racine du projet.

* Lancer la commande suivante :

 <pre> bin/cake server </pre>

* Rendez-vous sur http://localhost:8765/

---

h2. Cycle de vie du Matériel

---

h3. Diagramme d'états-transitions

{{thumbnail(equipment_status_state_diagram.png, size=2000, title=Cycle de vie du matériel)}}

---

h3. Diagramme de séquences

{{thumbnail(equipment_interactions_sequence_diagram.png, size=1500, title=Cycle de vie du matériel)}}

---

h2. ACL - Gestion des droits selon le profil

Document Google doc (à jour) : https://docs.google.com/document/d/1-OhEeoi96j6ueUl5NQCQ9ZsTfbJTFw3ZVaWU2iYly_o/edit?usp=sharing 

Ancien document (n'est plus à jour et est incomplet) : {{thumbnail(ACLs Droits selon les Roles.pdf, size=1500, title=Cycle de vie du matériel)}}

---

h2. ROADMAP - Plan de développement

*Stage de Thibault :* il se déroule du 10 avril au 30 juin 2017, soit sur 12 semaines (S1 à S12)

_*(Ne pas oublier de rédiger le rapport de stage au fur et à mesure)*_

Voir le détail de la roadmap: https://projects.irap.omp.eu/projects/inventirap/roadmap

* S01-SO2 : "version 2.5.x - Amélioraiton installation, pagination":https://projects.irap.omp.eu/versions/160

* S03-SO5 : "version 2.6.x - Emails, Etiquettes, bugfix...":https://projects.irap.omp.eu/versions/161

* S06-SO7 : "version 2.7.x - Synchronization avec LATMOS, ACLs ok partout":https://projects.irap.omp.eu/versions/162

* S08-S10 : "version 2.8.x - ACLs configurables via BDD, ...":https://projects.irap.omp.eu/versions/163

* S11-S12 : "version 2.9.x - upgrade Cakephp3, passage à Php7":https://projects.irap.omp.eu/versions/164

*Stage de Alexandre Cases (avril à juin 2016) :*

|                    |   |_.Prévu |_.Réalisé |

|/2=.S01 (11/4-15/4) |.1|/5=<."version 2.00 - Cakephp3 + Php5 (version de base from bake)":https://projects.irap.omp.eu/versions/105|/6=<.version 2.00|

                     |.2|

|/2=.S02 (18/4-22/4) |.1|

                     |.2|

|/2=.S03 (25/4-29/4) |.1|

                     |.2|/4=<."version 2.01 - Implémentation complète du CRUD":https://projects.irap.omp.eu/versions/101|

|/2=.S04 (02/5-06/5) |.1|/4=<.version 2.01|

                     |.2|

|/2=.S05 (09/5-13/5) |.1|

                     |.2|/3=<."version 2.02 - Implémentation de toutes les autres actions":https://projects.irap.omp.eu/versions/106|

|/2=.S06 (16/5-20/5) |.1|/2=<.version 2.02|

                     |.2|

|/2=.S07 (23/5-27/5) |.1|/2=<."version 2.03 - Implémentation du LDAP (vrai et fake)":https://projects.irap.omp.eu/versions/108|/2=<.version 2.03|

                     |.2|

|/2=.S08 (30/5-03/6) |.1|/2=<."version 2.04 - Implémentation des ACL (droits)":https://projects.irap.omp.eu/versions/107|_/10=<.version 2.04 (en cours)|

                     |.2|

|/2=.S09 (06/6-10/6) |.1|/2=<."version 2.05 - Documents attaches aux materiels (+ photos)":https://projects.irap.omp.eu/versions/99|

                     |.2|

|_/2=.S10 (13/6-17/6) |.1|/2=<."version 2.06 - Evolutions prévues dans 1.3 et 1.4":https://projects.irap.omp.eu/versions/110|

                     |.2|

|/2=.S11 (20/6-24/6) |.1|/1=<."version 2.07 - Corrections/Evolutions demandées par l'IAS":https://projects.irap.omp.eu/versions/124|

                     |.2|/2=<."version 2.08 - Cakephp3 + Php7 (compatible Php5)":https://projects.irap.omp.eu/versions/98|

|/2=.S12 (27/6-30/6) |.1|

                     |.2|/1=<."version 2.10 - Autres ajouts (+ fin rédaction rapport de stage)":https://projects.irap.omp.eu/versions/100|

---

h2. COMMIT : Procédure à suivre à chaque commit

NB: _cette procédure est détaillée davantage dans la section HOWTO de cette page (partie "CYCLE DE DEVELOPPEMENT A SUIVRE")_

Voici les différentes étapes à respecter au moment de chaque commit:

*1) S'assurer que tous les tests passent toujours !*

Cela permet de se prémunir contre toute régression (ce qui fonctionnait avant doit continuer de fonctionner)

*2) Optionnel : Incrementer la version et la date du projet*

A la fin du fichier src/Template/Layout/default.ctp

*3) Mettre à jour le fichier README-LABINVENT (ceci est un exemple, un template)*

Date: 11/05/2016

Version: 2.1.9

Mise à jour doc install

(Attention, changement structure BDD)

Demande(s) réalisée(s) : https://projects.irap.omp.eu/issues/3542

Version majeure en cours (2.1): https://projects.irap.omp.eu/versions/101

Remarques:

=> Version: 2.1.9 = 9ème commit sur la version 2.1

=> préciser "(bugfix)" si c'est le cas

=> ajouter "(Attention, changement structure BDD)" s'il y a eu une modif de la BDD

=> "Demande (terminée)" ou "Demande (en cours)", ou pas de demande du tout (exceptionnellement)

=> ces infos permettront de savoir quelle version (et date) exacte du projet on a actuellement sur son disque

*4) S'il y a eu un changement de structure de la BD*

* Copier la requête sql de modif dans un script db-update-AAAA-MM-JJ.sh du dossier database/update/

* Mettre à jour le script sql complet de création de la BD database/labinvent_2.1_12-05-16.sql (et les autres scripts sql associés si besoin, insert_users...)

* Mettre à jour le schéma (image png) de la BD (avec Mysql Workbench) dans le projet et sur le wiki (page "Documentation technique")

* Avertir dans le README (Attention, changement de structure de la BDD, il faut exécuter le script de mise à jour database/update/xxx ...)

*5) Si c'est la fin d'une version majeure (2.0, 2.1, 2.2, ...)*

* On doit normalement avoir écrit quelques nouveaux tests pour cette version, n'est-ce pas ??? (sinon, c'est po bien) !!!

* Ajouter cette version en tête de la section "MAIN CHANGES (MILESTONES)" dans le fichier README

* Mettre à jour la doc install/INSTALLATION à partir du wiki (si nécessaire)

* (On peut aussi tester une installation du logiciel from scratch)

*6) PULL*

(au cas où quelqu'un d'autre aurait fait un push)

*7) COMMIT*

Dans le message de commit, faire un simple copier/coller des infos du fichier README (sauf date):

Version: 2.1.9

Mise à jour doc install (bugfix)

(Attention, changement structure BDD)

Demande (terminée): https://projects.irap.omp.eu/issues/3542

Version majeure en cours (2.1): https://projects.irap.omp.eu/versions/101

*5) Si c'est la fin d'une version majeure (2.0, 2.1, 2.2, ...)*

* On doit normalement avoir écrit quelques nouveaux tests pour cette version, n'est-ce pas ??? (sinon, c'est po bien) !!!

* Ajouter cette version en tête de la section "MAIN CHANGES (MILESTONES)" dans le fichier README

* Mettre à jour la doc install/INSTALLATION à partir du wiki (si nécessaire)

* (On peut aussi tester une installation du logiciel from scratch)

* Voir aussi étape 9

*8) Optionnel : PUSH*

(seulement si le commit est important/urgent, ou suite à un ensemble de commits sur un même thème)

*9) Si c'est la fin d'une version majeure (2.0, 2.1, 2.2, ...), TAGUER la version*

Exemple:

<pre>

git tag 2.8 1b2e1d63ff

</pre>

The 1b2e1d63ff stands for the first 10 characters of the commit id you want to reference with your tag. 

You can get the commit id by looking at the log :

<pre>

git log

</pre>

---

h2. Procédure à suivre pour MERGER le code entre 2 labos

*0) Etat initial :*

- dev-LATMOS : état ok (tests passés & push fait)

- dev-IRAP : état ok (tests passés & push fait)

*A faire à l'IRAP :*

*1) Merger dev-IRAP => dev*

git checkout dev-IRAP

(dev-IRAP) Incrémenter date + version + commit/push

git checkout dev

*git merge --no-ff dev-IRAP*

Tests ok

git push [origin dev]

*2) Merger dev-LATMOS => dev*

git checkout dev-LATMOS

(dev-LATMOS) Tests ok

git checkout dev

*git merge --no-ff dev-LATMOS*

Si besoin, résoudre les conflits + add/commit/push

Si besoin, exécuter le(s) script(s) db-update.sh

si besoin, adapter le(s) script(s) db-update.sh

Tests ok

Faire un seul script db-update fusionnant toutes les modifs IRAP

Update le script de création général de la BD (en fonction du contenu de db-update.sh) + add/commit/push

Incrémenter date + version + add/commit/push

*3) Merger dev => dev-IRAP et dev-LATMOS*

git checkout dev-IRAP

*git merge --no-ff dev*

Tests ok

git push

git checkout dev-LATMOS

*git merge --no-ff dev*

Tests ok

git push

Si besoin : Prévenir LATMOS que db-update à faire (venant de dev-IRAP) ?

h2. Installation from scratch (Sous UBuntu)

h3. Création projet avec Composer

* Télécharger composer.phar : 

"curl -s https://getcomposer.org/installer | php"

* Avec le Composer créer un nouveau projet : 

"php composer.phar create-project --prefer-dist cakephp/app labinvent_2.0"

> Voir structure projet : http://book.cakephp.org/3.0/fr/intro/cakephp-folder-structure.html

* On rempli la base de données avec le fichier sql

* On indique la BD utiliser à CakePHP dans le fichier config/app.php, propriété "Datasources".

* On se place à la racine du projet

* On génère le code Scaffold : 

"bin/cake bake all nom_table" --> ça génére les modeles, les vues, et les controlleurs.

> Commande (en une fois) :

> > bin/cake bake all categories && bin/cake bake all emprunts && bin/cake bake all groupes_metiers && bin/cake bake all groupes_thematiques && bin/cake bake all organismes && bin/cake bake all sites && bin/cake bake all sous_categories && bin/cake bake all suivis && bin/cake bake all sur_categories && bin/cake bake all type_suivis && bin/cake bake all documents && bin/cake bake all users && bin/cake bake all materiels

h3. Modification de la base de données 

> Une version du sql corrigée au fur et à mesure est disponible dans le git :

> > Dans database/, le fichier labinvent_2.1_09-05-16 correspond à la création de la base.

> > Dans database/, le fichier labinvent_2.0_insert-irap_19-04-16 correspond aux insertions propre à l'IRAP, fichier insertion uniquement pour les dévellopeurs.

* Création table "config"

> > Mise à jour dans le fichier de création de base

> > Mise à jour à part : db-update-2016-05-09.sql

h3. Autres remarques lors du développement

* Suivre les conventions de CakePHP est le top pour ne pas avoir à refaire de la config (bidouiller), il faudrait vérifier réguliérement que c'est le cas (outil "cakephp-codesniffer")...

> Voir : http://book.cakephp.org/3.0/fr/contributing/cakephp-coding-conventions.html

* La solution pour insérer un utilisateur directement dans la base et pouvoir se connecter avec dans l'application est de l'insérer avec un mot de passe haché de la méme façon.

Le mot de passe "login" = "$2y$10$LZzpws3oDidBcqO/Fy1RTedLLk3ENTmplny5J7bZ6R1PqFoGOw3Ma".

Le mot de passe vide "" = "$2y$10$nBQMNstgN.sgad1ZANznY.pbJI.ZG/.Q5qX4gC8SXCFQnDIZC8rcW".

* Vérifier que la migration vers la prochaine version de cakephp3 (3.3 ?) sera facile... (décrire la procédure à suivre)

--> Une migration vers une version mineur 3.2 => 3.3, se réalise avec la mise à jour de CakePHP à l'aide de Composer

--> Puis il faut regarder les changements dans la page migration correspondant à la version voulu et adapter les changements au code.

> Voir : http://book.cakephp.org/3.0/fr/appendices/3-2-migration-guide.html

* Outil (plugin) "DebugKit" de CakePHP3 : 

--> DebugKit est un plugin qui fournit une toolbar pour aider à debugger les applications CakePHP plus facilement.

--> Par défaut il est installé avec le squelette de l'application, pour l'activer, il faut se placer à la racine.

--> Puis il faut éxécuter la ligne suivante : bin/cake plugin load DebugKit .

--> La commande va aller modifier le fichier config bootstrap.php.

--> Le fichier bootstrap.php actuel de l'application sur le git, est configuré pour charger le plugin lorsque l'application est en mode debug de CakePHP, je ne pense pas que exécuter la commande précédente soit utile vu la configuration de ce fichier dans notre application.

--> Le plugin nécessite l'extension php5-sqlite par défaut (il supporte l'équivalent avec de la config).

> Voir : http://book.cakephp.org/3.0/fr/debug-kit.html

* Mode debug personnaliser : 

> Faire $this->myDebug($var) dans un controlleur pour afficher le contenu de la variable si mode debug personnalisé actif, à condition que le mode debug soit activé.

> Voir : http://book.cakephp.org/3.0/fr/development/testing.html

* Pour charger une librairie (ex : phpqrcode, ...)

> Voir : http://book.cakephp.org/3.0/fr/core-libraries/app.html#charger-les-fichiers-de-vendor

* Pour créer les fichiers pdf d'entrée et de sortie, on utilise fpdf 1.8.1, on pourrait utiliser le plugin développer pour CakePHP3.

> Voir : https://github.com/FriendsOfCake/CakePdf

* Pour le JavaScript, le JS Helper a été retiré 

> Voir : http://book.cakephp.org/3.0/fr/appendices/3-0-migration-guide.html#jshelper

* Pour pouvoir éxécuter les tests depuis eclipse : 

> Voir : http://blog.loftdigital.com/running-phpunit-tests-in-eclipse-pdt

* Avant de déployer l'application sur le serveur de production, optimiser les performances

> Voir : http://book.cakephp.org/3.0/fr/deployment.html#ameliorer-les-performances-de-votre-application

h2. %{margin-left:0px; font-weight:bold; font-size:25px;  display:block; color:red;}Installation sur Mac (retour des pb)%

1) install.sh

=> 

chmod: Unable to change file mode on ./webroot/img//gqbee0pkerrl8h2rbekaa3t8j1.png: Operation not permitted

chmod: Unable to change file mode on ./tmp//cache/models/myapp_cake_model_default_configurations: Operation not permitted

chmod: Unable to change file mode on ./tmp//cache/models/myapp_cake_model_default_documents: Operation not permitted

chmod: Unable to change file mode on ./tmp//cache/persistent/myapp_cake_core_translations_cake_fr__f_r: Operation not permitted

chmod: Unable to change file mode on ./tmp//cache/persistent/myapp_cake_core_translations_debug_kit_fr__f_r: Operation not permitted

chmod: Unable to change file mode on ./tmp//cache/persistent/myapp_cake_core_translations_default_fr__f_r: Operation not permitted

=> sudo chmod -R 777 ../webroot/img

=> sudo chmod -R 777 ../tmp/

(=> sudo chmod -R 777 ../vendor)

2) connexion au site

=> mauvais affichage pourri

=> il faut configurer la BD dans app.php

            'username' => 'labinvent2user',

            'password' => 'labinvent2user',

            'database' => 'labinvent2',

3) login

=> epallier/login

---

h2. Pour mettre à jour CakePHP

* Utiliser le composer : "php composer.phar update" à la racine de l'application

> Voir : http://book.cakephp.org/3.0/fr/installation.html#rester-a-jour-avec-les-derniers-changements-de-cakephp

* Puis il faut modifier le fichier : ./vendor/cakephp/cakephp/src/View/Helper/PaginatorHelper.php

  Ce fichier contient le template de l'helper "paginator" et il faut modifier le tableau "$_defaultConfig" et remplacer les balise "li" par des balises "span".

  Enfin dans le même tableau, il faut remplacer la ligne suivante : 

> 'current' => '<span class="active"><a href="">{{text}}</a></span>',

           Par : 

> 'current' => '<span class="current">{{text}}</span>',

* Puis il faut vider le cache de l'application (et du navigateur) pour que debug_kit fonctionne.

---

h2. Pour utiliser php5.6 ET php7.1 sur le même OS (Fonctionne avec Ubuntu 14.04.5 - le 02/05/2017)

*Installation de php 5.6 et de php 7.1 :*

<pre>

sudo add-apt-repository ppa:ondrej/php

sudo apt-get update

sudo apt-get install php7.1 php5.6 php5.6-mysql php-gettext php5.6-mbstring php-mbstring php7.1-mbstring php-xdebug libapache2-mod-php5.6 libapache2-mod-php7.1

</pre>

*Comment changer de version :*

_*Depuis php5.6 vers php7.1 :*_

<pre>

sudo a2dismod php5.6 ; sudo a2enmod php7.0 ; sudo service apache2 restart

sudo update-alternatives --set php /usr/bin/php7.0

</pre>

_*Depuis php7.1 vers php5.6 :*_

<pre>

sudo a2dismod php7.0 ; sudo a2enmod php5.6 ; sudo service apache2 restart

sudo update-alternatives --set php /usr/bin/php5.6

</pre>

---

h2. Rappel d'intervention par mail

* Il faut définir un attribut *"rappel" de type "int"* dans la table suivis.

Cet attribut peut avoir *4 valeurs* : 

<pre>

0 ==> Pas d'envoi de rappel programmé

1 ==> Rappel programmé 1 mois avant

2 ==> Rappel programmé 15 jours avant

3 ==> Rappel programmé 2 jours avant

</pre>

* Dans *l'AppController*, il faut définir une fonction "rappelIntervention()" qui :

- Parcourt tous les suivis et garde ceux qui ont une date inferieur à 1 mois de la date du jour et qui ont un attribut "rappel" à "0".

- Met cette attribut à 1

- 

...........................

* Dans *l'UsersController*, il faut executer la fonction précédente une fois que l'utilisateur est connecté (dans fonction login()).

---

---

h2. %{margin-left:0px; font-weight:bold; font-size:25px;  display:block; color:red;}AMELIORATIONS A VENIR (TODO)%

h3. *1) POUR LE CODE SOURCE*

Bien maîtriser les 4 étapes qui s'enchainent lors de l'appel d'une action :

*a) Avant l'appel d'une action d'un controleur*

Ex: src/MaterielsController/isAuthorized()

Définir qui a droit à quoi dans src/<Model>Controller/isAuthorized(),

action par action, et à l'intérieur d'une action, role par role

Respecter cette structure de code :

<pre>

switch ($action) {

   case 'action1':

      switch ($role) :

         case USER:

         case RESP:

         case ADMIN:

         ...

   case 'action2':

      switch ($role) :

   ...

</pre>

*b) Dans le traitement de l'action, avant la vue*

Ex: src/MaterielsController/add()

Définir TOUTES les données dont la vue aura besoin, dans src/<Model>Controller/<action()>

La vue ne doit faire AUCUN traitement, elle doit se contenter d'afficher les données qu'on lui passe.

En particulier, selon le role (profil) actif, positionner ces tableaux (listes de champs pour dire à quels champs ce role à accès et dans quelles conditions (lecture seule, obligatoire, ...) :

 * $hiddenFields = [ fields list ]

 * $readonlyFields = [ fields list ]

 * $mandatoryFields = [ fields list ]

 * $defaultValueForFields = [ field1 => value1, field2 => value2, ..., fieldN => valueN ]

Passer ensuite ces listes à la vue avec set()

*c) Dans la vue correspondant à l'action*

Ex: dans src/Template/Materiels/add.ctp

Dans src/Template/<Model>/<action.ctp>

Afficher les données passées par le controleur pour cette action

(faire le moins de traitements possibles, seulement de l'affichage)

En particulier, la vue affichera les champs (fields) un par un, en utilisant une fonction displayField() qui tiendra compte automatiquement des listes définies à l'étape précédente :

$hiddenFields, $readonlyFields, $mandatoryFields, et $defaultValueForField

*d) (TODO) 4ème étape à envisager : ce qui se passe APRES que l'action a été exécutée*

* La sauvegarde dans la BD (voir aussi beforeSave())

* Quelle redirection vers quelle vue ?

h3. *2) POUR LES TESTS*

Les tests sont dans tests/TestCase/

Ils sont organisés par type :

* Controller/

* Model/

* View/

La plupart des tests sont dans Controller, mais il faudra aussi faire quelques tests de Model et de View...

Concernant les tests liés aux controleurs (dans Controller/), ils sont organisés par controleur :

* EmpruntsControllerTest.php

* MaterielsControllerTest.php

* PagesControllerTest.php

* SuivisControllerTest.php

* UsersControllerTest.php

Prenons l'exemple des tests du controleur de Materiels (MaterielsControllerTest.php)

Il faudrait organiser chaque test de controleur en 3 ou 4 parties correspondant aux 4 étapes présentées au point "1) POUR LE CODE SOURCE" ci-dessus :

*a) Avant l'appel d'une action d'un controleur :* 

Tester qui a le droit de faire quoi

*b+c) Dans la vue correspondant à l'action :*

Tester que la vue a bien été générée comme il faut pour cette action, et que les listes $readonlyFields, $mandatoryFields, ... sont bien remplies comme il faut

*d) Après la réalisation de l'action :*

Tester que l'action attendue a bien été réalisée et qu'on est bien sur la vue de redirection prévue

Exemples :

testUnauthenticatedUserCanLogin() : tester qu'un user non logué peut appeler l'action "login", et se trouve bien ensuite sur la page accueil

testUnauthenticatedUserCanViewAboutPage() : tester qu'un user non logué peut voir la page "about"

testUnauthenticatedUserCannotDoAnythingElse() : tester qu'un user non logué ne peut voir que les pages "accueil" et "about", et rien d'autre

testAuthenticatedUserCanLogout() : tester qu'un user logué peut se déloguer et atteint bien la page de login

*Tests spécifiques pour le controleur Materiels (les tests doivent être organisés PAR ACTION) :*

testOnMaterielsActionViewCanBeDoneByAll() : tester que tout le monde peut voir un matériel

testOnMaterielsActionAddCanBeDoneByAll() : tester que tout le monde peut créer un matériel, sans toutefois voir les mêmes champs (et pas dans les mêmes conditions), et vérifier que l'ajout d'un matériel a bien été fait et qu'on arrive sur la vue détaillée du matériel (oui, tout ça doit être testé, les 4 étapes citées plus haut, et cela pour tous les profils)

testOnMaterielsActionEditCanBeDoneByXXXWithConditions() : tester que selon les profils, on ne peut pas éditer les mêmes matériels (USER doit être owner, RESP doit appartenir au même groupe thématique ou métier, ...)

Pour chaque test, on peut imaginer des SOUS-TESTS de ce type (on prend ici l'exemple du test précédent) :

* testOnMaterielsInViewEditXXXCanSeeOnlyTheseFields (fields list) : test des hidden fields

* testOnMaterielsInViewEditXXXCannotChangeTheseFields (fields list) : test des readonly fields

* testOnMaterielsInViewEditXXXMustFillTheseFields (fields list) : test des mandatory fields

* testOnMaterielsInViewEditXXXTheseFieldsHaveDefaultValues (fields list with default values) : test des default value fields

h2. %{margin-left:0px; font-weight:bold; font-size:25px;  display:block; color:red;}HOWTO (nouvelle version avec CakePhp3)%

* *Auth : Chemin parcouru lors d'une connexion au site web*

Ce chemin est parcouru dans l'ordre :

<pre>

webroot/index.php 

config/bootstrap.php => lit config/app.php

src/Controller/PagesController/display()

src/Controller/UsersController/login() sans POST

src/Template/Users/login.ctp => formulaire de login => POST

src/Controller/UsersController/login() avec POST

   user = $this->LdapAuth->connection();

     src/Controller/Component/LdapAuthComponent/connection()

        $resp = TableRegistry::get('LdapConnections')->ldapAuthentication($login, $password);

        src/Model/Table/LdapConnectionsTable.php::ldapAuthentication()

		if ($this->USE_LDAP) {

			$ldapConnection = ldap_connect($this->host, $this->port);

       		        if (@ldap_bind($ldapConnection, $this->authenticationType . '=' . $login . ',' . $this->baseDn, $password)) {

		            return $this->getUserAttributes($login)[0];

		}

		else {

		        $user = $this->getFakeLdapUser($login);

			if ($user != false && (new DefaultPasswordHasher)->check($password, $user['userpassword'][0]))

			    return $user;

                }

                return FALSE

   if ($user != FALSE) {

      $this->LdapAuth->setUser($user);

      return $this->redirect($this->LdapAuth->redirectUrl());

</pre>

Pour info, si ça bogue (par exemple, à une époque on retournait "YOLO" au lieu de FALSE en cas d'échec de connection ldap), c'est *src/Template/Error/error400.ctp* qui prend le relais...

* *Champ facultatif/obligatoire : Comment rendre facultatif ou obligatoire un champ, et définir les vérifications à faire sur ce champ ?*

=> src/Model/Table/<Model>Table.php

ex : src/Model/Table/MaterielsTable.php pour définir les règles sur les champs de la table "materiels"

* *Où définir les éléments passés à une vue (c'est à dire à une action) ?*

=> src/Controller/<Model>Controller/nom_de_la_vue_ou_action()

ex : src/Controller/MaterielsController/edit() pour définir (avec set()) les éléments passés à la vue "edit" des materiels

* *ACL* : 

 * *ACL1 : Comment définir qui a droit de faire quelles actions (c'est à dire qui a le droit d'accéder à quelles vues) ?*

=> Régles générales par défaut pour tous les controleurs : src/Controller/AppController.php/isAuthorized()

(héritage de Cake\Controller\Component/AuthComponent/isAuthorized())

(cf https://book.cakephp.org/3.0/fr/controllers/components/authentication.html et https://book.cakephp.org/3.0/fr/tutorials-and-examples/blog-auth-example/auth.html)

_Voir aussi beforeFilter()_

=> Régles pour un controleur donné : src/Controller/<Model>Controller.php/isAuthorized()

 * *ACL2 : Une fois qu'on est dans une vue, comment définir qui a droit de voir quels éléments de la vue ?*

=> src/Template/<Model>/nom_de_la_vue.ctp

ex : src/Template/Materiels/edit.ctp pour les règles concernant la vue "edit" des materiels

h2. %{margin-left:0px; font-weight:bold; font-size:25px;  display:block; color:red;}HOWTO (ancienne version LabInvent 1.3 avec CakePhp2)%

*_Attention, ce howto est sans doute obsolète car il concerne l'ancienne version LabInvent 1.3 avec CakePhp2, mais il contient sûrement des conseils encore bien utiles_*

Ce document est un HOWTO, c'est à dire un guide pour savoir "comment faire quoi".

Il donne des solutions à différents types de besoins ou problèmes, et explique aussi "où trouver quoi".

* *VERSION DE CAKEPHP*

Version de cakephp ?

Configure::version(); // 2.1.3

Et aussi : fichier cakephp/lib/Cake/VERSION.txt

* *CYCLE DE DEVELOPPEMENT A SUIVRE (11 commandements)*

Je veux apporter un changement (correction ou evolution) au projet, comment dois-je faire ?

1) Incrementer la version du projet, a la fin du fichier cakephp/app/View/Layouts/default.ctp, et mettre à jour la date

2) Selectionner le changement a apporter (une demande) dans le Redmine du projet (https://projects.irap.omp.eu/projects/inventirap) :

- soit depuis la liste des demandes : onglet Demandes

- soit depuis la roadmap : onglet Roadmap, cocher la case "Anomalie", cliquer sur Appliquer, puis "version 1.3" (la version en cours depuis fin 2012)

Commencer de préférence par les "anomalies" parmi celles qui ont la plus haute priorité (et faire les "évolutions" dans un 2ème temps).

Choisir une demande et cliquer dessus pour aller sur sa fiche detaillee et voir le travail a faire.

Cliquer sur "mettre a jour", selectionner le statut "En cours", modifier eventuellement d'autres champs..., puis cliquer sur "Soumettre".

Noter l'URL de cette fiche (par exemple : https://projects.irap.omp.eu/issues/1050)

NB : Si la demande n'existe pas encore, la creer :

- cliquer sur l'onglet "Nouvelle demande"

- Selectionner "Anomalie" ou "Evolution"

- Positionner le statut a "En cours" si on veut travailler aussitot dessus (sinon, laisser a "Nouveau")

- Completer le reste de la fiche de demande (mettre "Assigne a" a "<<moi>>", choisir la version cible "version 1.3" ou "version 1.4", ...)

- cliquer sur le bouton "Creer"

3) Verifier que cette nouvelle demande apparait bien dans la roadmap (cliquer sur onglet "Roadmap", ..., puis version 1.3)

ÉTAPE OPTIONNELLE MAIS FORTEMENT CONSEILLÉE :

4) Ecrire un test qui vérifie que cette fonctionnalité ne marche pas encore (bug) ou bien n'est pas encore implémentée

On utilise ici l'approche TDD (Test Driven Development)

Ce test ne devrait pas passer (il est au rouge) ; il passera plus tard, quand on aura écrit le code nécessaire.

Bien sur, c'est dans la mesure du possible, car on ne peut pas TOUT tester.

Dans tous les cas, il faut ecrire un test qui s'approche le plus possible de la réalité à tester.

Voir pour cela la section "TESTS" (à la fin de ce document)

5) Faire les changements necessaires dans le code Php

Si ce changement implique aussi un changement dans la base de donnees,

copier le script SQL correspondant à ce changement dans un fichier database/update/db-update-YYYY-MM-DD.sql

portant la date du jour (voir des exemples dans database/update/old/).

Plus tard, il faudra penser à intégrer ce changement dans le script general de creation de la BDD database/BDD_IRAP.sql

(et/ou éventuellement les fichiers Insert_TablesFunct.sql, Insert_Users.sql, et Upd_TableConstraints.sql)

et donc deplacer le script de modification database/update/db-update-YYYY-MM-DD.sql dans database/update/old/db-update-YYYY-MM-DD.sql

6) Tester manuellement ce changement jusqu'a ce qu'il soit totalement OK

a) faire quelques tests manuels

b) Le test écrit à l'étape (4) doit maintenant passer (il est au vert).

Il doit être inclus dans l'ensemble des tests accessibles par le lien "AllTests".

c) Test de non régression : afin de s'assurer que cette modification du code n'entraîne aucune régression sur le reste du code, 

tous les autres tests écrits avant doivent aussi passer (vert) : pour cela, exécuter l'url /test.php?case=AllTests

7) Compléter le fichier /README.txt, section HISTORIQUE DES VERSIONS (fichier situé à la racine du projet)

Y mettre le même commentaire que ce que tu mettras lors du commit

8) Mettre a jour TON code (en mode console, "svn update" depuis la racine du projet, ou bien depuis Eclipse, clic droit sur le projet, "Team/Update") 

C'est important, au cas ou quelqu'un d'autre aurait fait des modifs (avant ou en meme temps que toi), et pour etre bien sur d'avoir la derniere version

9) Faire un "commit" du code, en collant dans le commentaire l'URL de la demande realisee (exemple : https://projects.irap.omp.eu/issues/1050)

10) Fermer la demande sur redmine

Sur la fiche detaillee, cliquer sur "Mettre a jour", changer le statut a "ferme", changer "% realise" a 100%, (copier l'URL de la fiche), cliquer sur Soumettre

11) Si c'est un changement important, le répercuter sur le site officiel 

Le changement est important si c'est une anomalie ou bien si c'est une évolution attendue.

Demander alors au service informatique de le répercuter sur l'installation officielle (faire un "svn update", mail à loic.jahan@irap.omp.eu).  

Si ce changement implique aussi la base de données, donner la directive que le fichier database/update/db-update-YYYY-MM-DD.sql doit être exécuté sur leur BDD.

Si ce changement impliquer une modification du fichier de configuration labinvent.php, donner la procédure à suivre dans le mail.

* *CORRIGER UNE ERREUR, RESOUDER UN PROBLEME, COMMENT DEBOGUER (DEBUG)*

Cakephp vous affiche une erreur, mais vous ne savez pas d'ou vient le probleme.

Don't panic.

En general, un bon moyen de le savoir est de lire le fichier de log des erreurs

dans cakephp/app/tmp/logs/error.log

Dans le dossier logs, vous trouverez d'autres logs utiles :

- labinvent.log

- debug.log (pas sur que ce fichier soit encore utilisé...)

Remarque :

$this->log('Something broke');

==> écrit dans cakephp/app/tmp/logs/ :

- error.log

- inventirap.log

* *OU EST QUOI (WHERE IS WHAT) ?*

- OU mettre a jour la VERSION du soft (AVANT CHAQUE COMMIT) ?

En attendant mieux, on fait cela a la fin du fichier cakephp/app/View/Layouts/default.ctp

- OU EST LA PAGE GENERALE (qui contient tous les elements) ? : cakephp/app/View/Layouts/default.ctp

- OU EST LA PAGE D'ACCUEIL ? : app/View/Pages/home.ctp

- OU SONT LES MENUS ? : app/View/Elements/

	- menu general + Recherche generale : menu.ctp

	- sous le menu general, et sous le champ "Recherche", titre du modele a ajouter : menu_index.ctp

- OU EST LA FEUILLE DE STYLE CSS ? : cakephp/app/webroot/css/inventirap.css

- OU EST DEFINIE LA PAGINATION ?

Dans le Controleur

Ex : la pagination des materiels est definie dans app/Controller/MaterielsController.php 

	public $paginate = array(

		'limit' => 50,

		'order' => array('Materiel.id' => 'desc'));

- OU SONT LES INFOS CONCERNANT UNE ENTITE quelconque (Materiel, Emprunt, Suivi, Utilisateur) ?

par exemple, ou trouver les infos sur l'entite "Materiel" ? : Aller dans cakephp/app/

- le Modele : Model/Materiel.php

- le Controleur : Controller/MaterielsController.php

- les Vues (templates) : View/Materiels

	- Vue de consultation : scaffold.view.ctp

	- Vue d'ajout (add) et edition (edit) : scaffold.form.ctp

	- vue de liste : index.ctp

- OU SONT DEFINIS LES ROLES (ACL) ?

Dans app/Model/Utilisateur.php :

	private $acceptedRoles = array ('Utilisateur', 'Responsable', 'Administration', 'Super Administrateur');

	public function getAuthenticationLevelFromRole($role) {

		if ($role == 'Utilisateur')

			return 1;

		elseif ($role == 'Responsable')

			return 2;

		elseif ($role == 'Administration')

			return 3;

		elseif ($role == 'Super Administrateur')

			return 4;

		return 0;

	}

* *WORKFLOW des materiels*

Le statut d'un materiel change selon le workflow suivant :

1) Un utilisateur lambda le cree (n'importe qui du labo) --> CREATED

2) L'Administration le valide (apres avoir eventuellement complete la fiche) --> VALIDATED

3) Un utilisateur lambda demande a l'archiver --> TOBEARCHIVED

4) L'Administration le sort de l'inventaire --> ARCHIVED

Notes : 

- Dans l'ideal, le materiel est premierement cree par l'utilisateur concerne,

puis mis a jour par l'administration au moment de la commande (puis validé)

- L'administration peut toujours retrograder le statut d'un materiel (ce qui revient a annuler un changement de statut) 

* *STRUCTURE GENERALE D'UNE PAGE WEB (TEMPLATE) = default.ctp*

app/View/Layouts/default.ctp contient la structure suivante :

	<div id="container">

		<div id="header">

			LE HEADER AVEC SON LOGO

			<div class="user">

				BIENVENUE $userName (ou invité)

			</div>

		</div>

		<div id="content">

			<?php echo $this->Session->flash(); ?>

			<?php echo $this->fetch('content'); ?>

		</div>

		<div id="footer">

			LE FOOTER

		</div>

	</div>

La DIV "content" insère 2 contenus :

	- le message flash éventuel (qui dit si une opération demandée s'est bien passée ou pas...)

	- la section "content", qui n'est autre que le coeur de la page

La page d'ACCUEIL n'est qu'un "content" parmi d'autres.

Elle se trouve dans app/View/Pages/home.ctp

(elle est affichée par le controleur de pages nommé PagesController)

* *COMMENT VOIR LES REQUETES SQL FAITES PAR CAKEPHP ?*

Dans le layout general (cakephp/app/View/Layouts/default.php), ajouter cette ligne :

	<?php echo $this->element('SQL_DUMP'); ?>

Vous devez aussi vous assurer que vous etes bien en mode DEBUG=2 (et non pas 0 ou 1)

dans le fichier de configuration Config/labinvent.php (ou bien dans le fichier Config/core.php)

* *OU EST FAIT LE CHARGEMENT DU FICHIER CONFIG database.php ?*

lib/Cake/Model/ConnectionManager.php (fonction _init())

Ce fichier fait partie de la librairie standard de CakePhp. Il ne faut donc pas y toucher.

A l'origine, j'avais (EP) changé ici le nom du fichier config "database.php" en "config.php",

ce qui marchait très très bien...

MAIS il ne vaut mieux pas modifier le comportement par défaut de cakephp,

car si un jour on change de version de cakephp, ça ne marchera plus.

* *CREATION ET GESTION DU NOUVEAU FICHIER DE CONFIG labinvent.php*

(cf http://book.cakephp.org/2.0/fr/development/configuration.html#loading-configuration-files)

1) J'ai créé le nouveau fichier de config dans app/Config/ (par exemple labinvent.php)

Ce fichier doit au minimum contenir un tableau nommé $config :

	$config = array(

			'labName' => 'IRAP',

			...

	);

2) Charger ce nouveau fichier de config au démarrage

Pour cela, ajouter cette ligne dans app/Config/bootstrap.php :

	Configure::load('labinvent');

3) Lire (ou même modifier) les paramètres de ce fichier de config, depuis N'IMPORTE OU (controleur, modèle, vue) :

		debug(Configure::version()); // pour afficher la version de Cakephp

		debug(Configure::read()); // tout lire

		debug(Configure::read('localisation')); // le tableau $localisation

		$labName = strtoupper(Configure::read('localisation.labNameShort'));

		debug(Configure::read('localisation.labName'));

		if (Configure::read('USE_LDAP')) ...

		if (Configure::read('debug') > 0 ) ...

On peut même modifier la valeur d'un paramètre dynamiquement comme ceci :

		Configure::write('debug',2)

C'est d'ailleurs ce qui est fait dans app/Config/core.php

4) Penser à modifier le script d'installation install/installation.sh pour qu'il prenne en compte ce nouveau fichier

* *LOCALISATION (adapatation du logiciel à l'entité locale)*

Vues (Pages) impactées :

- app/View/Layouts/default.ctp (template)

- app/View/Pages/home.ctp (Accueil)

- app/View/Pages/about.ctp (A propos)

Controleurs impactés :

- MaterielsController.php (fonction getLabNumber())

Documents impactés :

- Etiquette

- app/View/Documents/admission.ctp (Document d'admission)

- app/View/Documents/admission_cnrs.ctp (Document d'admission CNRS)

- app/View/Documents/admission_ups.ctp (Document d'admission UPS)

* *AJOUTER UNE NOUVELLE PAGE WEB*

Par exemple, voici ce que j'ai fait pour ajouter la page "about", qui est accessible via l'url https://inventirap.irap.omp.eu/pages/about

1) Aller dans app/View/Pages/

1) Faire un copier/coller d'une page existante, par exemple infos.ctp, et l'appeler about.ctp

2) Remplir cette page avec le contenu souhaité

3) Tester que cette page est bien accessible via l'url http://.../pages/about

4) Ajouter un lien vers cette page, soit dans le menu outils (app/View/Pages/tools.ctp), soit dans le menu général (app/View/Elements/menu.ctp)

5) Si cette page ne doit pas être accessible a tout le monde, définir le profil minimum exigé dans app/Controller/PagesController.php, en ajoutant une ligne dans le tableau $minProfileAllowedForPage

* *LOGIN workflow*

Controller/UtilisateursController/login() : 

; cherche l'utilisateur dans la table utilisateurs pour voir si c'est un user SPECIAL ou bien un user quelconque

; appelle Controller/Component/LdapAuthComponent/connection() et getUserName($ldapAuthentication)

Controller/Component/LdapAuthComponent : contient les 2 méthodes 

	- connection() : appelle Model/LdapConnection/ldapAuthentication($login, $password)

	- getUserName() : appelle Model/LdapConnection/getUserAttributes($ldapAuthentication)

Page d'accueil = View/Pages/home.ctp

(Controleur des pages simples = Controller/PagesController.php)

* *LOG*

$this->log('Something broke');

==> écrit dans cakephp/app/tmp/logs/ :

- error.log

- inventirap.log