Semaine du 9 au 13 février

Journal de stage : semaine du lundi 9 au vendredi 13 février 2015

Voici mes entrées de journal pour cette cinquième semaine de stage. Cette semaine je continuerais le développement de mon application web pour bientôt arriver à terme.

Lundi 9 février 2015

J’ai poursuivi le développement de ma fonction pour générer mon formulaire affichant les détails d’un ticket, cette même fonction utilise plusieurs autre fonctions, il faudra bien faire attention à faire toute les bonnes inclusions dans les fichiers qui l’utiliseront.

Après avoir écrit cette fonction, j’ai rencontré un petit problème sur la page de détails pour attribuer le ticket, lorsque que je valide mon formulaire, le comportement attendu est que la table ticket se met à jour (avec un SQL UPDATE) sur les colonnes « lieu », « importance », etc. Ors ces colonnes sont des clefs étrangères et j’ai l’erreur suivante qui apparaît :

Cannot add or update a child row: a foreign key constraint fails

Le problème me semble clair mais je ne comprend pas pourquoi j’ai ce problème. J’ai fais quelque recherche sur internet et la solution qui revient c’est qu’il faut supprimé la contrainte de clef étrangère, mettre à jour la colonne, et recréé la contrainte de clef étrangère … Je suis sûr que c’est autre chose.

J’avance un petit peu, apparemment on peut dire au moteur SQL quoi faire en cas d’update sur une clef étrangère, mais je ne trouve pas de paramètre qui convient : autoriser la modification de la clef étrangère. C’est quand même étrange c’est la première fois que je rencontre ce problème alors que je suis sûr que je l’avais déjà auparavant.

J’ai essayé d’exécuter ma requête seule sur phpMyAdmin, ça ne fonctionne toujours pas mais en revanche cela fonctionne lorsque que je ne met qu’une ligne sur ma clause « SET« .

SET `ID_RESPONSABLE` = '3',
	`NUM_CATEGORIE` = '2',
	`NUM_LIEU` = '4',
	`NUM_IMPORTANCE` = '7'
WHERE `ID` = 1;
Fonctionne pas
SET `ID_RESPONSABLE` = '3'
WHERE `ID` = 1;
Fonctionne !..

Finalement c’était tout bête, je ne prenais pas le problème comme il le fallait, si on regarde de plus près je fournissais une valeur pour la clef étrangère « NUM_IMPORTANCE » qui n’existait pas, d’où l’erreur. J’avais juste inversé une variable dans mon script PHP …

<?php

$sql = "UPDATE `atelier`.`ticket`\n"
	 . "SET `ID_RESPONSABLE` = '$importance',\n\t"
	 . "`NUM_CATEGORIE` = '$lieu',\n\t"
	 . "`NUM_LIEU` = '$categorie',\n\t"
	 . "`NUM_IMPORTANCE` = '$agent'\n"
	 . "WHERE `ID` = $id_ticket;";

?>
Suis-je bête ...

Maintenant que ce problème est résolu, l’attribution fonctionne, il faut maintenant que j’ajoute l’ajout de l’évolution la concernant, que la redirection se fasse sur la liste des tickets à attribuer et peut être ajouté un message d’information pour prévenir que tout s’est bien passé. Je pense d’ailleurs ajouté une option de regroupement « Ne pas regrouper« , au cas où l’utilisateur ne veut pas regrouper les tickets.

J’ai continué par améliorer mon module Evolution, désormais il affiche tout les évolutions qu’il trouve pour un ticket, auparavant il n’affichait que le créateur, j’ai mis une petite condition sur les colonnes à afficher : seulement si l’action vaut « Modifier » (dans le cas d’une modification de ticket), on affiche le champ qui à été modifier. Car pour les autres actions il ne s’agira que du statut qui changera une fois le ticket en cours.

Aperçu des évolutions

Aperçu des évolutions

Je n’ai pas poursuivi le module commentaire aujourd’hui, je ferrais cela pour demain.

J’ai arranger ma fonction pour générer la page de détails pour qu’elle la génère en mode « édition », toutes les informations du tickets se transforment en champs de formulaire, cela marche plutôt bien, il suffit d’appuyer sur un bouton « modifier » et la fiche de détail se transforme …

mod1

mod2

Avec toute ces fonction de finies, l’adaptation pour les différentes page à été très rapide, j’ai ainsi fini mon après midi en développant toute les étapes de vie du ticket, avec leurs gestion des évolutions. Désormais tout fonctionne de la création du ticket, jusqu’à sa résolution.

Je suis bloqué à la résolution car après ça, le ticket doit être supprimé et mis dans la table historique, qui n’existe pas pour le moment. Enfin c’est le scénario que suivait l’ancienne application, maintenant que la base à changé cela peut être remis en question.

clot

Je peux peut-être ajouté un statut « Archivé » de façon temporaire pour quand même gérer le cas de la clôture du ticket

Dans mes fiches de détails pour En cours et Résolu, on peut y faire plusieurs actions, qui se traduise par plusieurs éléments submit, et de ce fait je ne sais pas trop comment identifier quelle était tel ou tel action, dans la version avec l’ancienne bas de données j’avais utilisé des boutons radios, ce qui n’était pas très pratique. Je pense qu’il y a mieux à faire. En javascript je vois très comment faire mais en PHP brut …

Finalement il suffisait d’utiliser l’attribut « name » sur le bouton d’envoie, de ce fait un peut tester avec quel bouton le formulaire à été envoyer et ainsi déterminé quel script exécuter.

<input type="submit" name="resoudre" value="Résoudre le ticket">
<input type="submit" name="attente" value="Mettre le ticket en attente">
<?php

// Si l'utilisateur a envoyer le formulaire
if ($_SERVER["REQUEST_METHOD"] == "POST") {

	if (isset($_POST['resoudre'])) {
		// traitement
	}

	if (isset($_POST['attente'])) {
		// traitement
	}

}

?>

Demain je terminerais le développement de ce module « gestion du ticket » en peaufinant quelques détails, en finissant le module commentaire et enfin si j’ai le temps j’attaquerais la partie final, le back office.


 Mardi 10 février 2015

J’ai commencé par poursuivre le développement du module commentaire, j’ai améliorer la fonction qui les affichait pour qu’elle affiche tout les commentaires disponibles pour ce ticket, et j’ai créer une fonction qui ajoute le commentaire sur le ticket, il a suffit ensuite de quelque ligne pour traiter les paramètres dans les pages qui possède ce module commentaire et voilà !

<?php

/**
 * Permet d'afficher le module commentaire, comprenant la liste des commentaires pour un ticket
 * et le formulaire pour que l'utilisateur en rédige un nouveau.
 * @param  int $id_ticket	Identifiant du ticket sur lequel on affiche les commentaires
 * @param  PDO $pdo			Instance de l'objet PDO permettant de dialoguer avec la base de donnée
 * @return string			Elements HTML pour afficher les commentaires et le formulaire pour en rédiger un
 */
function getCommentaire($id_ticket, PDO $pdo) {...}

/**
 * Permet d'ajout un commentaire pour un ticket donné, sans avoir à gérer l'identifiant relatif
 * @param  string $commentaire	Valeur du champs "commentaire"
 * @param  int $id_ticket		Identifiant du ticket où on ajoute le commentaire
 * @param  int $id_usr			Identifiant de l'auteur du commentaire
 * @param  PDO $pdo				Instance de l'objet PDO permettant de dialoguer avec la base de donnée
 */
function newCom($commentaire, $id_ticket, $id_usr, PDO $pdo) {...}

comscoms

Le réel intérêt de passer par une fonction pour ajouter un commentaire dans la base est de ne pas avoir à gérer l’identifiant relatif, on fourni seulement les paramètres et la fonction va gérer l’identifiant relatif pour tout les cas de figure.

J’ai également ajouté une fonctionnalité que j’avais un peu oublié : pouvoir supprimer un ticket. Je ne sais plus si seulement l’administrateur à le droit de supprimer un ticket, ou si l’agent chef peut aussi le faire. En tout cas j’ai ajouté la possibilité de le faire, j’ai préparé la fonction pour qu’elle gère déjà quel type d’utilisateur peut l’utiliser, et j’ai seulement autorisé l’administrateur pour le moment.

suppr

Comme pour les commentaires, l’évolution, etc. j’ai créer une fonction pour obtenir le formulaire dans la page, et une fonction pour faire l’opération avec la base (surpression du ticket en l’occurrence).

<?php

/**
 * Permet d'obtennir le formulaire de suppression du ticket 
 * @param  int $id_usr	Identifiant de l'utilisateur, permet de déterminer s'il a accès à ce formulaire ou non
 * @return string		Retourne mes éléments HTML permettant d'afficher le formulaire de suppression d'un ticket
 */
function getSupprimer($id_usr) {...}

?>
<?php

/**
 * Permet de supprimer un ticket ainsi toutes ses évolutions et commentaire
 * @param  int $id_ticket	Identifiant du ticket à supprimer
 * @param  PDO $pdo			Instance de l'objet PDO permettant de dialoguer avec la base de donnée
 */
function supprimer($id_ticket, PDO $pdo) {...}

?>

J’ai ajouté une toute petite fonction JavaScript, un pop-up de confirmation avant la suppression. D’habitude je n’aime pas trop les pop-up car c’est très agressif pour l’utilisateur, mais dans le cas d’une opération importante je pense qu’il faut arrêter la navigation pour lui demander s’il est sûr, car après la suppression, il ne reste aucune trace du ticket.

<form method="post" onsubmit="return confirm('Voulez vous réellement supprimer définitivement ce ticket ?');">

confimjs

Mme Fichet est passé me voir dans la mâtiné pour voir où j’en étais, et d’après l’avancement de mon travail il serait préférable de se préparer à la mise en place, de convoquer l’équipe de l’atelier encore une fois afin de faire une dernière validation et de commencer la mise en place la semaine prochaine.

Il faudra que je rentre en contact avec Samuel Josseau afin qu’il me fournisse tout les accès nécessaire pour la mise en place.

J’ai donc envoyé un mail à l’équipe de l’atelier dans ce sens, je vais faire comme la dernière fois, je me suis renseigné rapidement et la salle 208 sera libre vendredi 13 février à 10h30.

Mme Fichet m’a fait remarquer que pour les évolutions, il serait plus judicieux de présenter cela sous forme de tableau et non comme je fais. C’est vrai que cela sera plus intéressant sachant qu’il peut y avoir très vite beaucoup d’évolutions. J’ai donc procéder à cette modification.

historique

J’ai terminer le dernier point, on peut désormais clôturer un ticket, j’ai ajouté un statut « clôturé », qui correspond au statut d’un ticket terminer et théoriquement visible dans l’historique. Pour le moment on ne peut voir ces tickets que depuis la liste de tous les tickets.

Concernant l’historique, j’ai réfléchi et en faite j’ai juste a faire une vue en plus sur les tickets, comme pour les autres, mais cette fois sur ceux qui ont le statut « Clôturé ». Pour le moment je m’occuperais de cela après.

J’ai décidé de continuer le « mode édition », pour modifier un ticket. J’ai commencer par ajouter un bouton lorsque l’on entre dans ce mode pour pouvoir en sortir en annulant les modifications.

cnceledit

Ensuite j’ai mis en place le script derrière le formulaire d’édition, il faut faire des vérification comme à la création (au cas où l’utilisateur « sabote » tout et mette tout les champs à vide) et en plus comparé les nouvelles valeurs avec les anciennes pour savoir quelle évolutions ajouter au ticket.

<?php

/*
 * Titre
 * -----------
 * ~ Requis
 * ~ Pas de condition de validation particulière 
 */
if (empty($_POST["titre"])) {
	$titre_err = TRUE;
} else {
	if ($_POST["titre"] != $titre)
		$champ_mod[] = 'Titre';

	$titre = test_input($_POST["titre"]);
}

?>

Ce ne fut pas très compliqué mais plutôt long, j’ai pris mon formulaire d’ajout de ticket comme base pour créer ce deuxième formulaire, de modification cette fois.

A la fin de la journée j’ai terminer le développement de ce mode édition, j’ai seulement quelque problème de clef étrangère avec l’agent responsable, mais rien de méchant, je corrigerais cela demain. Avec ceci de terminé je pense que mon module « gestion du ticket » est fini, je peaufinerais quelque détails demain. J’essayerais de faire une vue pour les tickets clôturés


 Mercredi 11 février 2015

J’ai commencer par essayer de corriger le problème que j’avais avec la clef étrangère du responsable, en fait je ne gère pas l’utilisateur comme les tables paramètres, ce qui complique la chose. Les tables paramètres comportent toutes un champ « Aucun(e) », c’est impératif pour l’application car c’est possible que la colonne correspondante dans le ticket reste vide.

Ainsi à l’édition, on peut laisser ces valeurs sur « Aucune », en revanche pour les utilisateurs je n’ai pas de telles valeurs, ce qui fait que si à l’édition on laisse « Non attribué », valeur ajoutée manuellement avec PHP, lorsqu’on valide tout plante à cause d’une contrainte de clef étrangère … Logique.

Pour palier ce problème j’ai simplement rendu obligatoire le responsable sur l’édition.

<?php

// Si titre & description correct et que l'agent et l'importance sont ok, on envoie le formulaire
if (!($titre_err || $description_err || $agent_err || $importance_err)) {
 # ...
}

?>

J’ai commencé à faire une vue pour les tickets clôturés, ce qui correspond dans le menu à « Historique ». J’ai fais exactement comme pour les autres vues de tickets, j’ai créer une liste avec regroupement, en arrangeant mon script gérant ces regroupements pour cette dernière liste.

 

Ensuite j’ai créé la page de détail de ces tickets, j’ai dû arranger mes scripts pour que rien de soit modifiables sur cette page, donc pas de mode édition, de suppression … Cette page de détail est prévue pour seulement visualiser un ticket clôturé.

info_histo

Pas de boutons « Modifier », « Attribuer, etc.

Voilà qui clôt le module de gestion des tickets. Je vais commencé à intégrer la gestion utilisateurs, gérer qui a accès a telle ou telle page, etc. et ensuite terminer le module d’administration.

admin

Pour la partie gestion des utilisateurs, ou back office, j’ai seulement adapté le menu en fonction de l’utilisateur qui se connecte, mais je commence à également à ajouté des redirection dans les pages, au cas où l’utilisateur qui n’a pas accès à une certaine page puisse y accéder en tapant simplement la bonne URL dans son navigateur, ou parle biais d’un favori … etc.

<?php

if ($_SESSION['usr_connected']['classe'] == 3){

	$_SESSION['msg'] = "Vous n'avez pas l'autorisation d'accèder à cette page.";
	header('Location: ../accueil.php');
	exit();

}

?>

Au passage je relis rapidement mes scripts, je corrige les petites erreurs si j’en vois. Il faut que je fasse une relecture globale de l’application pour corriger les fautes de français.

J’ai arrangé ma snackbar pour qu’elle ne disparaisse pas au bout de 7 secondes mais au clique de l’utilisateur. Je pense que c’est mieux car, si on ignore le message et qu’il nous gène, c’est désagréable de devoir attendre qu’il s’en aille, par contre, s’il est long est que l’on prend le temps de bien le lire, il risque de s’en aller trop tôt.

J’ai également rajouter, très rapidement, une icône de favori, ou « favicon ». Le favicon fait partie intégrante de l’identité visuelle d’un site web, grâce à elle, l’œil possède un point d’accroche pour repérer le site parmi les onglets ou les favoris. Moi même je retrouve plus facilement l’onglet où l’application est ouverte grâce à cela.

favicon

Demain je poursuivrais la gestion des accès utilisateur et je créerais les pages d’administration pour les tables paramètres de la base de données.


  Jeudi 12 février 2015

Après une relecture de tout mes fichiers existant et quelque bref tests supplémentaires, je pense que ma partie gestion des tickets est opérationnelle, prêt pour la réunion de demain donc !

Mme Fichet est passée brièvement et elle m’a fait remarqué que pour les évolutions, en particulier les modifications de tickets, il faudra très certainement enregistré en plus du nom du champs modifié, l’ancienne valeur que possédait ce champ. C’est vrai que je n’y avais pas pensé mais c’est quand même plus intéressant.

De toute façon ce n’est pas une modification très importante à réaliser puisque les données sont déjà accessible, il y a juste a les ajoutées. J’ai donc commencé à modifier le script de création de la base pour créer une nouvelle colonne pour accueillir cette valeur supplémentaire. J’ai ajouté quelques petites modifications sur certains libellé des tables paramètres.

Je finaliserais cela plus tard car je voudrais commencer le module administration pour avoir quelque chose à montrer dessus demain.

Ainsi je commence, j’avais déjà prévu les liens vers les pages dans mon menu, je n’ai eu qu’à créer les pages. J’ai pris exemple sur l’ancienne application, je fais quelque chose de très simple et basique, ces pages ne serviront presque pas de toute façon mais c’est plus pratique si elles existent.

En premier je construis la page pour gérer les lieux, et en prenant modèle sur l’ancienne application je fais :

  • Une liste des valeurs stockées dans la table « lieu »
  • Un petit formulaire pour ajouter un nouveau lieu
  • Une liste avec tout les lieux existant à sélectionner pour pouvoir en supprimé un
  • Et c’est tout, je pourrais peut être ajouté un formulaire pour modifier les lieux existant mais c’est du détail, à faire plus tard si j’ai encore du temps.

gestion

Et je procède ainsi pour chaque page, les lieux donc, les catégories, et les utilisateurs. C’est forcement plus long pour les utilisateurs puisque le formulaire d’ajout est beaucoup plus conséquent, d’ailleurs pour l’instant je n’ai pas le temps de le faire fonctionner mais il est là. J’essayerais de le finir demain matin avant la réunion.

Au début je comptais ajouter une page d’administration pour les actions mais j’ai réfléchi et ça n’a pas lieu d’être puisque les actions sont manipulées par l’application seulement donc l’utilisateur ne doit pas avoir la main dessus.

Avant je n’entourais pas mes instructions risquant des erreurs avec des bloc try/catch, pour les requêtes notamment. Mais là je commence petit à petit à le faire, et à afficher le message d’erreur dans la snackbar. C’est pareille pour moi puisqu’en développement, je vois les erreurs s’afficher mais en revanche, sur la production, les erreurs sont désactivées et ces messages sont le seul moyen de savoir s’il y a eu un problème ou non.

J’affiche ces erreurs grâce à ma snackbar, je retirerais les messages d’erreur SQL lors de la mise en production.

pdoerr

 

A la fin de la journée j’ai terminer toute mes pages administration, pour les lieux, les catégories et les utilisateurs. J’ai juste à faire fonctionner le formulaire d’ajout d’utilisateurs et tout est terminée.

Pour demain j’essayerais d’ajouter l’enregistrement des anciennes données lors d’une modification. Je pense créer 2 méthodes, une avec l’ajout de l’évolution pour une action majeure (attribuer, résoudre …) et une pour une évolution avec comme action « modifier ».


  Vendredi 13 février 2015

Juste avant la réunion de ce matin j’ai commencer à créer ma deuxième méthode pour ajouter l’ancienne valeurs d’un champ qui a été modifié, mais le temps m’a manqué alors je n’ai pas pu finir.

Avant la réunion, j’ai imprimer une fiche avec 5 tickets dessus pour donné un aperçu d’une fiche une fois imprimer avec mon application. J’ai également épurer la base de mes données de test pour la démonstration.

La réunion s’est très bien passée, il y avait un peu plus de monde que prévu, mais comme cela a peu près tout les acteurs de l’application on pu voir ce que mon application rendait. Il y avait :

  • Moi même
  • Mme Fichet
  • M. Josseau
  • Mme Chassagnoux
  • M. Dousset
  • M. Grelet
  • M. Vicedo
  • et Mme Raimond

Il y avait beaucoup de monde que je n’avais pas encore vus, le risque était que les personnes qui n’avait encore jamais vus l’application ne soit absolument pas en accord avec ce que j’avais fais, ou qui ne comprenne pas les choix qui on était fais … Ce genre de situation n’est pas rare.

Mais ce ne fut pas le cas, tout le monde semblait content du travail que j’avais fais, bien sûr il y a toujours des petites remarques à faire, on voit toujours des petites amélioration à apporter mais de façon générale tout le monde y trouvait son compte. Je pense donc que je peux considérer que l’application est validé, je n’ai plus qu’à corrigé les derniers petits détails et passer à la mise en production.

Comme M. Josseau était présent, nous avons pu nous arranger concernant ce dernier point : il passera me voir lundi pour me donner les accès au serveurs, base de données,etc.

Je vais peut être rédiger un petit compte rendu de cette réunion, afin de créer une trace de ce qui a été fait et de ce qu’il y a encore à faire.

Dans la salle où je travaille il y a des ordinateurs avec Ubuntu d’installé dessus, une chance, sur cette distribution de Linux, un serveur LAMP est très simple à mettre en place, ce que j’ai fais, ainsi je vais essayer de faire un premier test de mise en place sur serveur Linux.

Et malheureusement, il y a beaucoup de problème de mise en place, en faite sur le script de création de la base, WAMP créer les noms de tables en minuscules et LAMP en majuscule. Dans ma grand naïveté je ne pensais pas qu’il y aurait eu de problème alors j’ai créer mes scripts avec les noms de tables en minuscules …

J’ai donc corriger tout ces problèmes, ça m’a pris un certain temps mais ça sera déjà ce temps en moins de perdu lors de la mise en place sur le serveur de production, au cas où il y ai d’autre problèmes qui me prennent encore plus de temps.

Ensuite j’ai achevé les petits derniers détails qu’il manquait, il y avait un petit bug sur ma page pour afficher les détails de tous les tickets, c’était simplement un fichier qui n’était pas à jour avec mes nouvelles fonctions. J’ai terminer la partie « gestion des utilisateurs », désormais l’agent ne voit que ses tickets, et peut seulement les résoudre, ou les mettre en attente. Il peut consulter les tickets qu’il a résolu et il peut consulter tous les ticket sans pour autant pouvoir y faire quelque chose.

Comme cela été confirmer à la réunion, le module commentaire n’est jamais bloqué, ainsi un agent qui n’a plus de ticket à faire peut consulter ceux de ses collègues et peut être lui donner un « coup de main ».

Pour que l’application soit totalement finalisé il faut que j’améliore le module évolution pour qu’il conserve l’ancienne valeur d’un champ modifié et que je fasse fonctionné le formulaire d’ajout d’utilisateur.

Enfin comme amélioration à faire je peux ajouter un formulaire de modification d’utilisateurs et ajouté quelque chiffres de « supervision » de la base, comme le nombre de ticket total, en cours, etc. sur la page d’accueil, qui pour le moment, n’a pas un grand intérêt.

La semaine prochaine je procéderais à la mise en place de mon application sur le serveur de production, j’ajouterais quelque petite amélioration si le temps le permet et je verrais peut être les débuts d’utilisation de l’application, pour voir si tout se passe bien.

⇐ Page de journal pour la semaine précédente 

Page de journal pour la semaine suivante 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *