# TaskLog2
| ID | Description | US liée(s) |
| ----------- |:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:----------:|
| T | L'option `edit` correspondra à la fonction `issueEdit()`. Cette fonction permettra la mise en place de l'affichage permettant de modifier une issue, c'est-à-dire l'affichage de différent champs tels que `description`, `difficulté` et `l'importance` et un bouton `submit` pour envoyer l'informations. La `difficulté` devra être une valeur numérique appartenant à la suite de `Fibonacci`. Si le nombre n'appartient pas à la suite alors un message d'erreur sera affiché. `L'importance` sera affichée avec une liste déroulante contenant les valeurs `low/medium/high` avec `high` la plus grande importance. Une fois le bouton `submit` appuyé la base de données sera mise à jour (`db.collection.update(query)`) et l'affichage du menu sera enlevé pour laisser place à la liste des issues (liste horizontale). | |
| T GHERKIN | Ecrire un scénario en Gherkin et créer un test en selenium qui vérifient que lorsque l'on valide une édition d'une issue (appel à la fonction `issueEdit()`) , les données entrées par l'utilisateurs correspondent bien à celles afichées et à celles présentes dans la base. | |
| T | L'option `delete` correspondra à la fonction `issueDelete()`. Cette fonction demandera à l'utilisateur si celui-ci est sûr de vouloir supprimer l'issue via un pop-up. S'il répond positivement alors l'issue sera effacée de la base de données (`db.collection.remove(query)`). | |
| T GHERKIN | Ecrire un scénario en Gherkin et créer un test en selenium qui vérifient que lorsque l'on valide une suppression d'une issue (appel à la fonction `issueDelete()`), l'élément à bien été supprimé de l'affichage et de la base de données. | |
| T | Dans le fichier `issue.js`, si l'utilisateur clique sur le bouton `newIssue` alors l'affichage sera changé comme explique dans la `T?`. L'utilisateur pourra entrer la description de l'issue (obligatoire) à travers un champ. Une fois le champ rempli il pourra appuyer sur le bouton `submit` afin de valider la création de son projet. On enverra à la base de données la description entrée par l'utilisateur ainsi que l'ID de l'issue qui sera générée automatiquement en récupérant la derniere id du tableau et en lui ajoutant + 1. La base de données sera mise à jour (`db.collection.insert(query)`). Il pourra également annuler son souhait de vouloir ajouter un nouveau developpeur en appuyant sur le bouton `cancel`. | |
| T GHERKIN | Ecrire un scénario en Gherkin et créer un test en selenium qui vérifient qu'une ligne est bien ajouté dans l'affichage de la liste des issues quand on appuis sur `newIssue` dans la page `issues.js`. Une fois la description ajoutée, on vérifie si l'issue est bien présente dans la base de données et si la description correspond. Si on appuie sur cancel alors rien n'est ajouté a la base et dans l'affichage. | |
| T GHERKIN | Ecrire un scénario en Gherkin et créer un test en selenium qui vérifient si lors de la suppression les données ont bién été misent à jour dans la base et dans le backlog, et au niveau des ID des US. | |
| T | Dans le fichier `issue.js`, aprés que l'utilisateur ait appuyé sur le bouton `submit` ou `cancel` l'affichage de la parte edit sera enlevée pour laissé place à la liste des developpeurs qui sera remise à l'horizontale grâce à la fonction `issueDefaultDisplay()`. | |
| T | Dans le fichier `issue.js`, après que l'utilisateur ait choisi le type de tri qu'il veut avoir pour le backlog, la fonction `sortBacklog(type)` doit être lancée avec `type` qui est soit `difficulty`, `importance` ou `id`. Cette fonction mettra à jour l'affichage du backlog en fonction du tableau aprés le tri. | |
| T | Création de la base de données `Cdp2020` avec les tables suivantes. | |
| T | Ajout de la table : `User(UserName)` (userName : String - unique/required) | |
| T | Ajout de la table : `Project(Id, Title, Description, UserId)` (Id : Number - unique/required, Title : String/required - unique, Description : String, UserId : String - required) | |
| T | Ajout de la table : `UserStory(Id, Description, Difficulty, Priority, Sprint, ProjectsId)` (Id : Number - unique/required, Description : String - required, Priority : PriorityType, Sprint : int, ProjectId : int - required) | |
| T | Ajout de la table : `Task(Id, Description, UserStoriesId, Dependences, EstimatedTime, State, DevId)` (Id : Number - unique/required, Description : String - required, UsId : Number, Dependences : DependencesType, EstimatedTime : EstimatedTimeType, State : TaskStateType, DevId : number) | |
| T | Ajout de la table : `Dev(DevName, ProjectId)` (DevName : String - unique/required, ProjectId : Number - required)
| T | Ajout de la table : `Documentation(Version, Type, File, ProjectId)` (ProjectId : number - required, Version : VersionType - required, Type : DocumentationType - required, File : File - required) | |
| T | Ajout de la table : `Sprint(Id, SprintCount, Duration, BeginingDate, Tasks, ProjectId)` (Id : Number - required, SprintCount : Number - required, Duration : Date, BeginingDate : Date, Tasks : ListIdTasks) | |
| T | Ajout de la table : `Test(ProjectId, Type, Version)` (ProjectId : number - required, Type : TestType - required, Version : VersionType - required) | |
| T | Création d'un fichier `dockerFile` et d'un fichier `docker-compose.yaml` afin d'éxécuter l'architecture de l'application web. # TO DO | |
| T | Création d'un fichier `planification.ejs` correspondant à la page ou l'utilisateur va pouvoir associer des développeurs à des tâches. Dans le header de la page se trouvera le fichier `header.ejs` afin d'avoir la `navBar`. En dessous de celle-ci se trouvera sur la partie gauche de l'écran un tableau composé des développeurs liés au projet. Sur la partie droite de l'écran se trouvera un tableau composé des tâches liées au projet. Et en dessous des deux tableaux se trouvera un bouton `Pert` permettant de générer et d'afficher le diagramme de Pert lié au projet. | |
| T | Dans la page `planification.ejs`, il pourra être fait des glisser-deposer afin d'ajouter un développeur à une tache. Cependant, il ne pourra avoir qu'un seul développeur par tache. On pourra enlever le développeur d'une tache en le selectionnant et en le déposant dans le contenu vide de la page. | |
| T | Création d'un fichier `planification.js` correspondant à la page `planification.ejs`. Ce script doit pouvoir lors de l'affichage de la page `planification.ejs` récupérer la liste des développeurs du projet (`db.collection.find()`) et la la liste des tâches (`db.collection.find()`) et les afficher. | |
| T GHERKIN | Ecrire un scénario en Gherkin et créer un test en selenium qui vérifient que les données affichées sur la page `planification.ejs` correspondent a celles présentent dans la base de données. | |
| T | Dans le fichier `planification.js`, une fois le bouton `Pert` appuyé il faut créer un diagramme de Pert en utilisant les données de la table `tâche` (`db.collection.find()`). | |
| T | Dans le fichier `planification.js`, doit se trouver une fonction permettant de gérer le glisser-deposer des développeurs aux taches. Une fois le glisser-deposer effectué, il faudra mettre à jour la base de données des tâches (`db.collection.update(query)`). Cependant, le développeur ayant été glisser-deposer doit toujours apparaitre dans la liste des développeurs. | |
| T GHERKIN | Ecrire un scénario en Gherkin et créer un test en selenium qui vérifient que lorsqu'on a glissé-déposé un developpeur vers une tache, il à bien été ajouté à la tache dans la base de données et dans l'affichage. On vérifie également qu'il est toujours affiché dans la liste des développeurs. | |
| T | Dans le fichier `planification.js`, si le développeur a été selectionné depuis la liste des tâches, une fois celui-ci déposer dans le vide il faudra mettre à jour la table des tâches (`db.collection.update()`). Egalement si le développeur a été selectionne depuis la liste des développeurs et qu'il est deposé dans le vide alors on le fera juste disparaitre de la sélection. | |
| T GHERKIN | Ecrire un scénario en Gherkin et créer un test en selenium qui vérifient que lorsqu'on a glissé-déposé un developpeur d'une tâche vers le vide de la page, alors il n'est plus affiché sur la tâche et il n'est plus associé à la tâche dans la base de données. | |
| T | Création d'un fichier `sprint.ejs` correspondant à la page ou l'utilisateur peut gérer les sprints du projet. Dans le header de la page se trouvera le fichier `header.ejs` afin d'avoir la `navBar`. La premiere fois que l'utilisateur se rendra sur la page, il y aura au centre de la fenetre un formulaire avec un champ pour mettre le nombre de sprint voulu et un champ pour la durée d'un sprint (identique pour tous les sprints). En dessous de ces deux champs se trouvera un bouton `submit` permettant d'envoyer les informations. | |
| T | Dans la page `sprint.ejs`, une fois le tableau de sprints crée, il sera affiché en dessous du header. En dessous du tableau se trouvera la liste des issues du projet. | |
| T | Dans la page `sprint.ejs`, il sera possible de selectionner une issue et de faire un glisser-deposer afin de la mettre dans un sprint. | |
| T | Dans la page `sprint.ejs`, lors qu'un clic droit sera effectué sur une case du tableau de sprint, alors un petit menu s'affichera afin de sélectionner une date de début. | |
| T | Création d'un fichier `sprint.js` correspondant à la page `sprint.ejs`. Ce script doit pouvoir lors de l'affichage de la page `sprint.ejs` afficher le tableau de création de sprint lorsque c'est la premiere fois qu'on y accéde. L'utilisateur doit alors entrer une durée et un nombre de sprint dans un formulaire. Si ce n'est pas la premiere fois, le script doit pouvoir récupérer la liste des sprints du projet (`db.collection.find()`) et la liste des issues du projet (`db.collection.find()`) et les afficher. | |
| T GHERKIN | Ecrire un scénario en Gherkin et créer un test en selenium qui vérifient que le nombre et la durée des sprints affichés et dans la base de données sont égaux à ce qu'a entré l'utilisateur. Ce test vérifie également que les données affichées dans la page corresondent a celles de la base de données. | |
| T | Dans le fichier `sprint.js`, si une case du tableau de sprint est sélectionnée avec un clic droit, alors il devra être possible de lui associer une date de début (`db.collection.update()`). Cependant, la case `sprint x` ne peut pas avoir une date de début antérieure à celle du `sprint x - 1`. | |
| T GHERKIN | Ecrire un scénario en Gherkin et créer un test en selenium qui vérifient que la date du `sprint x` est antérieure à celle du `sprint x + 1`. Si c'est le cas, ce test vérifie également que la date entrée par l'utilisateur correspond à celle qui est affichée et présente dans la base. | |
| T A CHANGER ET TESTER | Dans le fichier `sprint.js`, doit se trouver une fonction permettant de gérer le glisser-deposer des issues aux sprints. Une fois le glisser-deposer effectué, il faudra mettre à jour la base de données des sprints (`db.collection.update(query)`). | |
| T A CHANGER ET TESTER | Dans le fichier `sprint.js`, si l'issue a été selectionnée depuis les sprints, une fois celle-ci déposée dans le vide il faudra mettre à jour la table des sprints et des issues (`db.collection.update()`). Egalement si l'issue a été selectionnée depuis la liste des issues et qu'elle est deposée dans le vide alors on la fera juste disparaitre de la sélection. | | T | Création d'un fichier `documentation.ejs` correspond à la page ou l'utilisateur va pouvoir gérer sa documentation. Dans le header de la page se trouvera le fichier `header.ejs` afin d'avoir la `navBar`. En dessous de celle-ci se trouvera dans un tableau une liste de répertoire contenant les fichiers de type documentation. Ce tableau sera de la forme version du répertoire, liste des fichiers documentation contenus dans le répertoire. En dessous de ce tableau se trouvera un bouton `addRepertoire` permettant d'ajouter un nouveau répertoire. | |
| T | Dans la page `documentation.ejs`, il sera possible de trier les répertoires en fonction de la version via une liste déroule ayant comme attributs `old version to current version` et `current version to old version`. Cette liste déroulante se trouvera au dessus du tableau. | |
| T | Création d'un fichier `documentation.js` correspondant à la page `documentation.js`. Ce script doit pouvoir lors de l'affichage de la page `documentation.ejs` faire une requete à notre base de données (`db.collection.find(query)`) afin d'afficher les différents répertoires et les fichiers de documentation dans le tableau de la page. Si l'utilisateur effectue un clic droit sur un répertoire alors un menu sera affiché à l'endroit du curseur avec les options `edit` et `delete`. L'option `edit` correspondra à la fonction `documentationEdit()` et l'option `delete` correspondra à la fonction `documentationDelete()`. | |
| T GHERKIN A VERIFIER | Ecrire un scénario en Gherkin et créer un test en selenium qui vérifient que les fichiers sont bien présents dans les répertoires, et que les types des fichiers de documentations correspondent bien à ceux stockées dans la base de données. | |
| T | L'option `edit` correspondra à la fonction `documentationEdit()`. Cette fonction permettra la mise en place de l'affichage permettant de modifier un répertoire de documentation, c'est-à-dire l'affichage des champs tels que `typeDocumentation`, `version` et un bouton `submit` pour envoyer l'informations. Il y a aura également un champ permettant à l'utilisateur de pouvoir importer son fichier depuis son ordinateur. Une fois le bouton `submit` appuyé, la base de données sera mise à jour (`db.documentation.update(query)`), l'affichage du menu sera enlevé pour laissé place à la liste des répertoires contenant les fichiers de documentation (liste horizontale). | |
| T GHERKIN | Ecrire un scénario en Gherkin et créer un test en selenium qui vérifient que lorsque l'on édite une documentation et que l'on valide les valeurs (appel à la fonction `documentationEdit()`), alors la base de données et l'affichage sont mis à jour et les données correspondent à ce qu'a entré l'utilisateur. Le test vérifie également l'intégrité des valeurs. | |
| T | L'option `delete` correspondra à la fonction `documentationDelete()`. Cette fonction demandera à l'utilisateur si celui-ci est sûr de vouloir supprimer la documentation via un pop-up. S'il répond positivement alors la documentaton sera effacée de la base de données (`db.documentation.remove(query)`). | |
| T GHERKIN | Ecrire un scénario en Gherkin et créer un test en selenium qui vérifient que lorsque l'on valide une suppression d'une documentation (appel à la fonction `documentationDelete()`), l'élément à bien été supprimé de l'affichage et de la base de données. | |
| T | Dans le fichier `documentation.js`, lorsqu'un clic sera effectué sur `addDocumentation` le menu `edit` s'ouvrira sur la partie droite de l'écran laissant le choix à l'utilisateur de créer un répertoir en indiquant la `version` de sa documentation (on mettra à jour la base de données en fonction de ces informations). | |
| T GHERKIN | Ecrire un scénario en Gherkin et créer un test en selenium qui vérifient que lorsque l'on valide la création d'une documentation, elle est bien affichée sur la page et ajoutée dans la base de données. On vérifie également que les données entrées par l'utilisateur correspondent à celles affichées et dans la base. | |
| T | Dans le fichier `documentation.js`, si un clic gauche est effectué sur un documentent de la documentation, alors sur la partie droite de l'écran sera affiché la description du fichier (.md). | |
| T GHERKIN | Ecrire un scénario en Gherkin et créer un test en selenium qui vérifient que lorsque l'on clic gauche sur un document de la documentation, alors les information affichée sur la partie droite correspondent bien à celles présentent dans la base. | |
| T | Dans le fichier `documentation.js`, il sera possible de trier les répertoires en fonction de leurs version. | |
| T GHERKIN | Ecrire un scénario en Gherkin et créer un test en selenium qui vérifient que le tri des documentation est est valide | |
| T | Création d'un fichier `task.js` correspondant à la page `task.ejs`. Si l'utilisateur effectue un clic droit sur une tache, alors un menu sera affiché à l'endroit du curseur avec les options `edit` et `delete`. L'option `edit` correspondra à la fonction `taskEdit()` et l'option `delete` correspondra à la fonction `taskDelete()`. | |
| T | Dans le fichier `task.js`, la fonction `taskEdit()` permettra la mise en place de l'affichage permettant de modifier une tache, c'est-à-dire l'affichage de différent champs tels que `description`, `us liees` et `tache dépendante`, `temps estimé` et `sate` et un bouton `submit` pour envoyer l'informations. Le champ `us liee` aura une liste déroulante contenant la liste des us du projet (`db.userStory.find()`) mais indiquera seulement l'id de l'us et non sa description. Le champ `tache dépendante` aura une liste déroulante contenant la liste des tâches du projet (`db.task.find()`). Le champ `estimed time` ne pourra être rempli que par des valeurs soit en `djH` (demie-journée homme) ou en `jH` (journée Homme). Une fois le bouton `submit` appuyé la base de données sera mise à jour (`db.task.update(query)`), l'affichage du menu sera enlevé pour laissé place à la liste des taches (liste horizontale). | |
| T GHERKIN | Ecrire un scénario en Gherkin et créer un test en selenium qui vérifient que lorsque l'on édite une tâche et que l'on valide les valeurs (appel à la fonction `taskEdit()`), alors la base de données et l'affichage sont mis à jour et les données correspondent à ce qu'a entré l'utilisateur. Le test vérifie également l'intégrité des valeurs. | |
| T | Dans le fichier `task.js`, la fonction `taskDelete()` demandera à l'utilisateur si celui-ci est sûr de vouloir supprimer l'issue via un pop-up. S'il répond positivement alors l'issue sera effacée de la base de données (`db.task.remove(query)`). | |
| T GHERKIN | Ecrire un scénario en Gherkin et créer un test en selenium qui vérifient que lorsque l'on valide une suppression d'une tâche (appel à la fonction `taskDelete()`), l'élément à bien été supprimé de l'affichage et de la base de données. | |
| T | Dans le fichier `task.js`, si l'utilisateur clique sur le bouton `newTask` alors l'affichage sera changé comme explique dans la `T?`.L'utilisateur pourra entrer la description de la tache (obligatoire) à travers un champ. Une fois le champ rempli il pourra appuyer le bouton `submit` afin de valider la création de la tache. On enverra à la base de données la description entrée par l'utilisateur ainsi que l'ID de l'issue qui sera générée automatiquement en récupérant la derniere id du tableau et en lui ajoutant + 1. La base de données sera mise à jour (`db.task.insert(query)`). Il pourra également annuler son souhait de vouloir ajouter un nouveau developpeur en appuyant sur le bouton `cancel`. | |
| T GHERKIN | Ecrire un scénario en Gherkin et créer un test en selenium qui vérifient que dans lorsque l'on valide la création d'une tâche (clic sur `submit`), elle est bien ajoutée à l'affichage et dans la base de données avec les données qu'a entré l'utilisateur. De plus on vérifie que l'id de la tâche s'est correctement ajouté (+1 par rapport à l'id précédent). Si l'utilisateur appuie sur `cancel` alors rien n'est ajouté. | |
| T | Création d'un fichier `release.ejs` qui correspond à la page ou l'utilisateur va pouvoir gérer les différentes releases liées au projet. Dans le header de la page se trouvera le fichier `header.ejs` afin d'avoir la `navBar`. En dessous de celle-ci, se trouvera un tableau contenant la liste des différentes releases du projet tel que (fileName, file (bouton de téléchargement), version). Sous ce tableau se trouvera un bouton `newRelease` permettant d'ajouter une nouvelle release. Il sera possible de modifier les releases, donc un menu `edit` s'affichera sur la partie droite de l'écran et le tableau des releases sera sur la partie gauche de l'écran. | |
| T | Dans la page `release.ejs`, il sera possible de trier les releases en fonction de leur version via une liste déroulante ayant comme attributs `old version to current version` et `current version to old version`. | |
| T | Dans la page `release.ejs`, si un clic est effectué sur le file de la release alors un téléchargement sera effectué sur le browser de l'utilisateur. | |
| T | Création d'un fichier `release.js` correspond à la page `release.ejs`. Si l'utilisateur effectue un clic droit sur une release, alors un menu sera affiché à l'endroit du curseur avec les options `edit` et `delete`. L'option `edit` correspondra à la fonction `releaseEdit()` et l'option `delete` correspondra à la fonction `releaseDelete()`. | |
| T | Dans le fichier `release.js`, la fonction `releaseEdit()` permettra la mise en place de l'affichage permettant de modifier une release, c'est-à-dire l'affichage du champ tel que `fileName`, `version` et un bouton `submit` pour envoyer l'informations. Il y a aura également un champ permettant à l'utilisateur de pouvoir importer son fichier depuis son ordinateur. Une fois le bouton `submit` appuyé, la base de données sera mise à jour (`db.release.update(query)`) et l'affichage du menu sera enlevé pour laissé place à la liste des releases (liste horizontale). | |
| T GHERKIN | Ecrire un scénario en Gherkin et créer un test en selenium qui vérifient que lorsque l'on édite une release et que l'on valide les valeurs (appel à la fonction `releaseEdit()`), alors la base de données et l'affichage sont mis à jour et les données correspondent à ce qu'a entré l'utilisateur. Le test vérifie également l'intégrité des valeurs entrée par l'utilisateur et si le fichier importé est valide (bon format par exemple). | |
| T | Dans le fichier `release.js`, la fonction `releaseDelete()` demandera à l'utilisateur si celui-ci est sûr de vouloir supprimer la release via un pop-up. S'il répond positivement alors la release sera effacée de la base de données (`db.release.remove(query)`) | |
| T GHERKIN | Ecrire un scénario en Gherkin et créer un test en selenium qui vérifient que lorsque l'on valide une suppression d'une release (appel à la fonction `releaseDelete()`), l'élément à bien été supprimé de l'affichage et de la base de données. | |
| T | Dans le fichier `release.js`, si un clic gauche est effectué sur le bouton de téléchargement d'une release, alors l'utilisateur aura via son browser le téléchargement de la release en question (`db.release.find(query)`). | |
| T GHERKIN | Ecrire un scénario en Gherkin et créer un test en selenium qui vérifient que lorsque le fichier à été téléchargé il est bien présent dans le repertoire destination. | |
| T | Dans le fichier `release.js`, après que l'utilisateur ait choisi le type de tri qu'il veut avoir pour le tableau des releases, la fonction `sortRelease(type)` doit être lancée avec `type` qui est soit `oldToRecent` ou `recentToOld`. On devra trier les releases en fonction de leur version, c'est à dire que par exemple la version `1.5.01` est plus récente que la version `1.4.15`. Cette fonction mettre à jour l'affichage du tableau des releases en fonction du résultat obtenu via la fonction. | |
| T GHERKIN | Ecrire un scénario en Gherkin et créer un test en selenium qui vérifient que le tri des releases affichées est valide. | |