https://air.imag.fr/api.php?action=feedcontributions&feedformat=atom&user=Zoran.Chanet 2026-07-28T04:15:46Z User contributions MediaWiki 1.39.17 https://air.imag.fr/index.php?title=User:Zoran.Chanet&diff=45427 2019-03-20T10:12:29Z

<p>Zoran.Chanet: /* Articles */</p> <hr /> <div>= Contact =<br /> Profil LinkedIn : [https://www.linkedin.com/in/zoran-chanet Zoran CHANET]&lt;br&gt;<br /> Profil GitHub : [https://github.com/ProfesseurSid ProfesseurSid]&lt;br&gt;<br /> Profil GitLab : [https://gitlab.com/CHANET_Zoran CHANET_Zoran]&lt;br&gt;<br /> Profil gricad.gitlab : [https://gricad-gitlab.univ-grenoble-alpes.fr/chanetz chanetz]&lt;br&gt;<br /> E-mail : [mailto:zoran.chanet@etu.univ-grenoble-alpes.fr zoran.chanet@etu.univ-grenoble-alpes.fr] (expire en 2020)<br /> <br /> = Projets =<br /> == 2017-2018 ==<br /> [[RICM4 2017 2018 - Nucleo]] <br /> <br /> == 2018-2019 ==<br /> [[VT2018 Thorntail]]&lt;br&gt;<br /> [[ECOM-1F0 1819 BTB]] &lt;br&gt;<br /> [[PROJET-INFO5 1819 EDCampus]]<br /> <br /> = Articles =<br /> Diverses pages de technologies du projet [[ECOM-1F0 1819 BTB#Technologies | ECOM]]&lt;br&gt;<br /> [[VT2018 Thorntail]]&lt;br&gt;<br /> [[VT2018 Thorntail Demo]]&lt;br&gt;<br /> [[SonarQube Scanner]]&lt;br&gt;<br /> [[GitLab Runners]]&lt;br&gt;<br /> [[GitLab CI/CD]]&lt;br&gt;<br /> [[Apache mod_rewrite]]&lt;br&gt;<br /> [[Let's Encrypt]]&lt;br&gt;</div>

Zoran.Chanet https://air.imag.fr/index.php?title=PROJET-INFO5_1819_EDCampus&diff=45426 2019-03-20T10:08:59Z

<p>Zoran.Chanet: /* Platforme */</p> <hr /> <div>[[File:Logo_EDCampus.png|thumb|right| Logo EDCampus]]<br /> = Le projet en quelques mots =<br /> La plateforme [[Contributions open-source au projet Eclipse EdCampus | EDCampus]] est une plateforme de gestion de projet développée par Disrupt Campus Grenoble. La plateforme est actuellement en train d’être soumise à la fondation Eclipse afin d’être mise en open source sous licence Eclipse. Dans le cadre du projet Disrupt Campus, les étudiants sont invités à contribuer à la plateforme. Dans le cadre de vos formations c’est une vraie plus valu de contribuer à de réels projets plutôt qu’à des projets one-shot qui seront mis à la poubelle sitôt votre soutenance terminée. EDCampus est donc une opportunité de contribuer au logiciel libre et à la fondation Eclipse (et de s'assurer une jolie ligne sur son CV plutôt qu'un projet qui sera aussi vite oublié que l'ECOM !).<br /> <br /> = L'équipe et leurs rôles =<br /> <br /> * GEOURJON Anthony - Chef de projet (EXT)<br /> * [[User:Servan.Charlot | CHARLOT Servan]] - Chef de groupe<br /> * [[User:Zoran.Chanet | CHANET Zoran]] - Responsable DevOps<br /> <br /> = Roadmap =<br /> * '''20-22 février 2019 :''' Hack Ton Campus, la plateforme EDCampus sera utilisée pour la gestion des défis.<br /> * '''Avril 2019 :''' Projet pilote, un projet mêlant une entreprise, l'UGA et des étudiants servira de test à la plateforme.<br /> * '''Septembre 2019 :''' Mise en production globale.<br /> <br /> = Captures d’écran =<br /> <br /> == Plateforme ==<br /> <br /> &lt;gallery&gt;<br /> File:EDCampus 2019 P1.png<br /> File:EDCampus 2019 P2.png<br /> File:EDCampus 2019 P3.png<br /> &lt;/gallery&gt;<br /> <br /> == Vitrine ==<br /> <br /> &lt;gallery&gt;<br /> File:EDCampus 2019 VitrineUni.png<br /> File:EDCampus 2019 Vitrine1.png<br /> File:EDCampus 2019 Vitrine2.png<br /> File:EDCampus 2019 Vitrine3.png<br /> File:EDCampus 2019 Vitrine4.png<br /> &lt;/gallery&gt;<br /> <br /> = Documents =<br /> <br /> *[[Media:Rapport-Projet-EDCampus-2019.pdf|Rapport Final]].<br /> *[[Media:EDCampus-Final-CHANET-CHARLOT.pdf|Presentation Finale]].<br /> <br /> = Carnet de bord =<br /> <br /> == Semaine 1 ==<br /> <br /> === 28/01/19 ===<br /> <br /> Assignation du sujet [[Contributions open-source au projet Eclipse EdCampus | EDCampus]].<br /> <br /> === 29/01/19 ===<br /> <br /> * Rencontre avec Anthony au [http://fabmstic.liglab.fr/ Fablab], présentation du sujet, des enjeux, et de la roadmap<br /> * Installation du projet<br /> ** Difficultés dues au DNS des réseaux universitaires (impossible de télécharger le contenu nécessaire depuis les containers)<br /> <br /> === 30/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $scope._getProjectParent()&lt;/code&gt; qui ne marchait pas du tout. Il y avait une faute dans la plupart des variables qui s'appelaient &lt;code&gt;currentParentProject&lt;/code&gt; au lieu de &lt;code&gt;currentProjectParent&lt;/code&gt;.<br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $rootScope._checkProject()&lt;/code&gt; qui oubliait un paramètre dans son appel à &lt;code&gt;$scope._setProject()&lt;/code&gt;.<br /> <br /> ==== Zoran ====<br /> * Assignation d'une première tâche : réparer la création d'un projet indépendant<br /> * Découverte du code du projet<br /> * Poursuite de l'arborescence des appels depuis le bouton jusqu'à l'appel à la base de données<br /> <br /> === 01/02/19 ===<br /> ==== Servan ====<br /> <br /> * Assignation de la tâche consistant à réparer le système de fichier.<br /> * Exploration du système de fichier et son implémentation.<br /> <br /> ==== Zoran ====<br /> * Production d'une méthode permettant des logs personnalisés<br /> * Recherches sur le rewriting d'URL<br /> * Correction du problème (lié au rewriting)<br /> * Production d'une fiche explicative de la solution<br /> <br /> == Semaine 2 ==<br /> <br /> === 04/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction des bugs suivants :<br /> <br /> * Affichage des fichiers du portefeuille père ssi il y a au moins un fichier présent dans le projet fils.<br /> ** Dans le backend, la fonction qui get les fichiers exécutait un &lt;code&gt;return false&lt;/code&gt; avant de get les fichiers parents dans le cas ou il n'y avait pas de fichier à la base.<br /> * N'actualise pas la liste des fichiers si on supprime le dernier fichier.<br /> * Tous les dossiers sont affichés comme des fichiers. Lors de la première sélection à la souris, si on sélectionne le fichier-dossier, il se transforme en dossier et on peut y accéder. Rien ne se passe pour les sélections suivantes.<br /> ** Dans le backend, un paramètre était traité comme chaîne de caractère alors qu'il représentait un booléen. Le résultat de ça est que l'on entrait dans la mauvaise partie d'un if, qui exécutait la mauvaise requête SQL nous privant de l'information concernant le type de fichier lu (un dossier est un type de fichier).<br /> * Le bouton qui permet de revenir en arrière, sortir du dossier ne fonctionne pas.<br /> * On ne peut pas entrer dans un dossier hérité.<br /> <br /> ==== Zoran ====<br /> * Assignation de la mise en place de techniques DevOps<br /> * Recherches sur la mise en place de pipeline dans GitLab : voir [[GitLab CI/CD | compte-rendu]]<br /> * Mise en place d'un pipeline à chaque push<br /> * Production d'un tutoriel de création de runner GitLab : voir [[GitLab Runners | tutoriel]]<br /> * Recherches sur SonarQube et les tests unitaires<br /> ** Priorisation de SonarQube<br /> <br /> === 05/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug qui faisait que lors de la suppression d'un dossier, les fichiers à l'intérieur ne sont pas supprimés (le champ statut dans le BDD ne passe pas à 0).<br /> ** La fonctionnalité de suppression récursive n'était pas implémentée dans &lt;code&gt;File.php&lt;/code&gt;.<br /> * Début de l'analyse du système de droit des utilisateurs (Administrateur/Tuteur/Élève) sur les fichiers et dossiers (hérités ou non).<br /> <br /> ==== Zoran ====<br /> * Compréhension des scanners sonar : voir [[SonarQube Scanner | compte-rendu]]<br /> * Mise en place d'un scan dans le pipeline<br /> ** Nécessité d'un serveur sonar exposé<br /> ** Décision d'utiliser SonarCloud<br /> ** Configuration du scanner pour envoyer le rapport dans le bon projet sonarcloud<br /> ** Réussite du premier scan<br /> <br /> === 06/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Suite de la correction du système de droits des fichiers/dossiers.<br /> <br /> * Correction d'un bug qui faisait que les utilisateurs ne peuvent pas entrer dans les dossiers hérites (ou télécharger les fichiers hérites).<br /> ** Le check de droit se fait dans une fonction qui check d'abord le &lt;code&gt;ownerId&lt;/code&gt;, puis le &lt;code&gt;projectId&lt;/code&gt; et puis enfin si le fichier appartient à un parent. Pour cela elle fait appel à la base pour récupérer la relation d’héritage. IL y avait une erreur de comparaison entre le résultat de la requête et les information fichier (erreur de type parce que PHP).<br /> * Analyse complète du système de droit création d'un tableau explicatif de l'état actuel et l'état voulu.<br /> [[File:EDCampus_2019_Tableau_de_droits.png|center]]<br /> * Suite au tableau, mise en place de la protection des fichiers hérités.<br /> ** Ajout d'une vérification sur le &lt;code&gt;projectId&lt;/code&gt;, empêchant les utilisateurs non propriétaires du fichier de le supprimer, renommer ou déplacer.<br /> <br /> ==== Zoran ====<br /> * Extension du scan sonar dans le pipeline à toutes les sections du projet<br /> * Affichage de badges d'état du pipeline sur la page de présentation de chaque section du projet<br /> * Reprise des recherches concernant les tests unitaires<br /> * Tentative de systématisation des tests dans le pipeline<br /> ** Difficulté : les tests nécessitent des fichiers de configurations qui ne sont pas présents sur le repository git<br /> * Recherche de contournement pour ne pas exposer des configurations privées dans le projet public<br /> <br /> === 08/02/19 ===<br /> <br /> ==== Servan ====<br /> Suppression de la vue pour les non membres et correction partielle du système de droits.<br /> * Lorsque qu'une commande est envoyée par le front-end vers le back-end, elle passe dans une fonction qui vérifie les droits (&lt;code&gt;Right.php checkRights($command)&lt;/code&gt;). La fonction compare la commande utilisée par l'utilisateur aux commandes que cet utilisateur a en général le droit d'utiliser. Le problème était que le tableau de commandes au sein de la fonction (permettant la comparaison) contenait des commandes mal formatées. J'ai donc corrigé celle qui m'intéressais pour empêcher les non membres d'un projet à consulter les fichiers, et j'en ai profiter pour corriger toutes les autres.<br /> <br /> ==== Zoran ====<br /> * Configuration des scanners sonar dans le pipeline (redirection vers une branche du projet sonarcloud nommée selon la branche GitLab sur laquelle le pipeline est lancé)<br /> * Aide à la correction du système de droits<br /> * Réalisation de tâches mineures importantes pour le Hackaton<br /> ** Retirer la vidéo Waza de l'accueil de la plateforme<br /> ** Redirection de l'utilisateur vers la plateforme lorsqu'il accède à l'url du dossier : [[Apache mod_rewrite]]<br /> ** Correction de l'url donné lors de l'appel au service de mails pour la validation de compte<br /> <br /> == Semaine 3 ==<br /> <br /> === 12/02/19 ===<br /> <br /> ==== Servan ====<br /> * Système de droits entièrement corrigé pour le cas des fichiers.<br /> ** Privilèges administrateurs.<br /> *** Dans la fonction qui vérifie les droits &lt;code&gt;Right.php checkRights($command)&lt;/code&gt;, le cas de l'administrateur n'était pas vraiment traité. Il y avait une vérification pour empêcher tout utilisateur non administrateur d’exécuter une commande administrateur, mais sinon l'administrateur était traité comme un utilisateur lambda. J'ai donc ajouté un test permettant de donner les pleins pouvoirs. Presque. Il fallait aussi ajouter un test dans la fonction &lt;code&gt;File.php _checkFileAccess(...)&lt;/code&gt; qui pour certaines actions sur les fichiers, agit comme une surcouche à la fonction &lt;code&gt;checkRights&lt;/code&gt; (ce qui permet entre autres des actions sur les fichiers hérités pour le tuteur et les membres).<br /> ** Cas du déplacement de fichier hérités.<br /> *** Avec l'accord d'Anthony, on a conclu que le déplacement de fichier hérité était une mauvaise idée, donc cela reste non autorisé, même pour les admins.<br /> * Correction du fait que les fichiers ayant un numéro pour nom ne peuvent pas être supprimés.<br /> ** Les appels à la base effectuait une comparaison avec un &lt;code&gt;LIKE&lt;/code&gt; au lieu d'un &lt;code&gt;=&lt;/code&gt; dans la requête SQL, ce qui ne marchait pas dans le cas présent.<br /> * Correction du fait que les fichiers ayant un numéro pour nom ne peuvent pas être renommés.<br /> ** Le nom du fichier est traité et enregistré par le fichier JS, qui est non typé donc il décide que si le nom n'est que des numéros, alors ce ne sera pas une string. Or pour renommer le fichier, on veux modifier la partie du nom qui est avant le point (de l'extension), donc on fait un appel à &lt;code&gt;name.lastIndexOf(&quot;.&quot;);&lt;/code&gt;, qui s’exécute exclusivement sur une string. J'ai donc réalise un &lt;code&gt;.toString()&lt;/code&gt; sur le nom à chaque fois que nécessaire.<br /> * Correction du fait que lorsque l'on supprimait un fichier dans un dossier, on était renvoyé à la racine du projet plutôt que dans le dossier.<br /> ** Il manquait un paramètre (le dossier) à la fonction &lt;code&gt;getFiles(...)&lt;/code&gt; appelée après la suppression.<br /> * Transformation du bouton &quot;Ajouter&quot; en deux boutons, un pour les dossiers, un pour les fichiers.<br /> <br /> ==== Zoran ====<br /> * Mise à Jour de templates de mail (&gt;100 templates)<br /> ** Remplacement des références à Waza Education par EDCampus<br /> ** Production d'une banière et remplacement de l'ancienne<br /> * Tests des fichiers de configuration des tests unitaires<br /> * Recherches sur le passage de l'HTTP vers HTTPS avec [https://letsencrypt.org/ Let's Encrypt] : voir le [[Let's Encrypt | résumé rapide]]<br /> ** Choix d'utilisation de [https://certbot.eff.org/ Certbot]<br /> <br /> === 13/02/19 ===<br /> <br /> ==== Servan ====<br /> Nouvelle tâche assignée : Améliorer les tâches, faire en sorte que si un nom est placé sur un label d'une couleur au sein d'un projet, tous les labels de cette couleur auront ce même nom.<br /> <br /> ==== Zoran ====<br /> * Sauvegarde de la base de données de l'ancienne plateforme<br /> * Passage de l'ancienne plateforme de l'HTTP à l'HTTPS<br /> ** Réparation de la configuration d'Apache<br /> ** Génération des certificats<br /> ** Configuration d'Apache pour l'HTTPS<br /> <br /> === 14/02/19 ===<br /> <br /> ==== Servan ====<br /> * Backend corrigé, on ne peux plus créer un label d'un nom au choix si il y a déjà un label de cette couleur avec un nom dans le projet.<br /> * Etude approfondie du front-end et du système événementiel pour corriger les défauts de mise à jour.<br /> <br /> ==== Zoran ====<br /> * Recherches sur l'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Découverte et compréhension d'une [https://github.com/BirgerK/docker-apache-letsencrypt image existante]<br /> * Tentative de passage de l'HTTP à l'HTTPS dans un Docker<br /> ** Sur la VM de l'ancienne plateforme (pour ne pas briser la version en prod)<br /> ** Fusion du Dockerfile existant et du Dockerfile de l'image trouvée<br /> <br /> === 15/02/19 ===<br /> <br /> ==== Servan ====<br /> * Correction superficielle des problèmes des mise a jour a de la vue du système de tache. Le soucis étant que les taches et le petit menu qui indique les détails ne sont pas le même module et n'interagissent pas vraiment entre eux, donc on ne peux pas actualiser l'un depuis l'autre.<br /> * Correction du fait que dans le système de fichier, on ne pouvait pas délacer un fichier/dossier vers le dossier parent en le glissant sur la flèche retour. <br /> ** Le soucis venait du fichier html, qui avait l'air correct mais la variable qu'il était censé récupérer renvoyait undefined au lieu de l'identifiant du dossier parent.<br /> <br /> ==== Zoran ====<br /> * Poursuite de la tentative d'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Succès de la création de certificat<br /> ** L'HTTPS ne fonctionne toujours pas (sans doute à cause de la configuration d'Apache)<br /> <br /> == Semaine 4 ==<br /> <br /> Hack ton campus.<br /> <br /> == Semaine 5 ==<br /> <br /> Vacances d'hiver.<br /> <br /> == Semaine 6 ==<br /> <br /> === 05/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug trouvé lors que hackaton qui empêchait les étudiants de télécharger un fichier hérité appartenant à un tuteur. <br /> * Début d'un travail sur les tests unitaires du backend. Le but est de vérifier les tests existants, essayer de les faire fonctionner, et s'en inspirer pour en créer d'autres et à terme, couvrir tout le code.<br /> <br /> ==== Zoran ====<br /> * Succès de la mise en place d'HTTPS dans un docker<br /> ** Modification de &lt;code&gt;docker-compose.yml&lt;/code&gt; pour lier les ports 443 de l'hôte et du conteneur<br /> ** Finalisation de la configuration d'Apache dans le conteneur<br /> <br /> === 06/03/19 ===<br /> <br /> ==== Servan et Zoran ====<br /> <br /> * Lecture de la [https://phpunit.readthedocs.io/en/8.0/ documentation de PHPUNit.]<br /> Après un travail de recherche, nous nous sommes rendu compte que PHPUnit allait être difficile à mettre en place sur le backend du projet. En effet, toutes les fonctions sont en ''static'' et il est impossible de mocker les fonctions statiques avec PHPUnit. Il faudrait donc revoir l'architecture du code pour mocker le statique, et donc remplacer les appels à la base de données par des appels simulés. Cela éviterait d'avoir à créer une base externe accessible ou construire une base dans le runner du pipeline. Cependant cela est trop long a mettre en place sachant que l'on arrive sur la fin du projet, donc nous avons donné priorité à la vitrine, suite à une réunion avec les membres de Disrupt campus. <br /> <br /> La vitrine est un endroit où le public (étudiants/professeurs/entreprises) peut consulter les projets réalisés ou en cours. Cette vitrine se décompose en un endroit ou l'on peut consulter la liste des projets d'une université, et des pages de projet individuelles avec une image, une description et les livrables.<br /> <br /> === 07/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction d'un bug en rapport avec les accents dans les noms. Lorsque qu'un utilisateur possède un accent dans son nom (ex: Amélie), au moment de la création du login la chaîne de caractère est mal interprétée et le login est tronqué au niveau de l'accent (ex: amY). L'architecture fait que lors du transfert du nom du front vers le back, l'accent est codé avec des caractères classiques, qui sont ensuite interprétés correctement lors de l'ajout en base. Mais cela veux dire que pendant tout le passage en backend on travaille avec des accents codés. Le login était créé à partir du nom et du prénom de l'utilisateur, qui peuvent donc être temporairement corrompus par des accents codés. La correction de ce soucis est donc détecter la présence d'accents dans les noms, et si il y en a, créer le login à partir de la première partie de l'adresse mail de l'utilisateur (avant le @), sinon, on fait comme avant avec les noms.<br /> <br /> ==== Zoran ====<br /> * Correction d'un bug empêchant l'envoi d'e-mail lors de l'ajout d'un utilisateur à un projet<br /> * Prospection dans le code et la base de donnée pour permettre l'affichage ou non des évaluations dans le menu des projets. La section des évaluations étant gérée différemment des autres sections, ce travail nécessitera plus de temps que prévu et a donc été reporté au profit de la vitrine<br /> <br /> === 08/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Archéologie sur le prototype de vitrine.<br /> * Rédaction de documentation générale sur l'architecture End-To-End du projet (ci-dessous).<br /> <br /> [[File:EDCampus 2019 EndToEnd.png|border]]<br /> <br /> Détails de la fonction &lt;code&gt;checkRights&lt;/code&gt; :<br /> <br /> * La commande en cours est envoyée à &lt;code&gt;checkRights&lt;/code&gt; sous forme de string.<br /> * On vérifie d'abord si elle fait partie des commandes publiques, que l'on peux exécuter lorsque l'on a pas de session. (Via une comparaison avec un tableau contenant toutes les commandes publiques.)<br /> * Si ce n'est pas la cas, on récupère ensuite les informations de session et l'identifiant utilisateur.<br /> * Si on ne trouve pas d'utilisateur, on regarde si on essai d’accéder a une page publique, sinon on bloque l'accès.<br /> * On a maintenant un utilisateur avec une session, qui essaie d'agir sur une page non publique.<br /> * On vérifie si l'utilisateur est super-administrateur.<br /> * On vérifie si l'utilisateur essai d’exécuter une commande administrateur, en tant qu'administrateur.<br /> * Puisque la page est non-publique et que l'on est pas administrateur, il s'agit forcement d'une page de projet. <br /> * On vérifie si l'utilisateur est propriétaire du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est propriétaire du projet courant et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet courant et que cette commande est autorisée.<br /> * Si aucun des tests ci dessus n'a raté (ou n'a déjà accordé l'accès), on accorde l'accès.<br /> <br /> ==== Zoran ====<br /> * Archéologie sur le prototype de vitrine<br /> * Réparation des appels au serveur opérés par le prototype de vitrine existant<br /> ** La vitrine étant écrite en php et non en utilisant AngularJS comme le reste du front-end, la gestion des appels est différente<br /> ** Correction du lien par lequel le serveur est appelé<br /> ** Correction des arguments et de la commande donnés lors de l'appel au serveur<br /> * Correction du nombre de projets affichés avant extension<br /> * Prospection pour l'utilisation future de la vitrine<br /> <br /> == Semaine 7 - Vitrine ==<br /> <br /> === 11/03/19 ===<br /> <br /> * Correction d'un bug d'affichage. L'administrateur peut choisir dans son profil quel est son campus principal, et cela est utile entre autres dans la partie communication de son dashboard. C'est à cet endroit qu'il peut choisir de rendre publique la page de son université (ie. la vitrine). A cet endroit, la vitrine est renseignée par un lien (&lt;code&gt;http://localhost/app/campus/?u=UGA&lt;/code&gt;), contenant le nom du campus au bout (UGA). Le bug faisait que ce nom n'était pas affiché et donc l'URL était incomplet. Le soucis venait du backend, ou la requête du campus à la base ne demandait pas le champ nom.<br /> * Correction des projets affichés en vitrine<br /> ** Affichage des projets fils et indépendants seulement (pas les portefeuilles)<br /> ** Explicitation du nom des projets fils (Si ''Equipe A'' appartient au portefeuille ''Défi 3'', son nom affiché sera ''Défi 3 &gt; Equipe A'')<br /> * Ajout d'un texte de remplacement lorsqu'une section est vide (plus élégant qu'un grand espace vide)<br /> <br /> === 12/03/19 ===<br /> * Création d'une page vitrine de projet<br /> ** Ecriture de cette page comme un composant AngularJS, pour coller à la nouvelle méthode<br /> ** Création des sections principales (titre, description, membres)<br /> * Harmonisation du visuel<br /> ** Beaucoup de CSS<br /> <br /> === 13/03/19 ===<br /> * Ajout de nouvelles sections<br /> ** Modification des requêtes et des droits pour rendre public les informations souhaitées<br /> ** Sections dates, thèmes, mots-clés, organisations<br /> * Réunion/démonstration avec Gérard<br /> <br /> === 14/03/19 ===<br /> * Création de la section livrables<br /> ** Nombreux ajustements sur les requêtes<br /> * Implémentation des url externes comme livrable<br /> ** Section url externe à la remise des livrables<br /> ** Gestion des url en base<br /> <br /> === 15/03/19 ===<br /> * Gestion des droits de téléchargement des livrables depuis la vitrine<br /> * Gestion des url externes de vidéo comme vidéo embarquées<br /> ** Youtube<br /> * Réunion/démonstration avec l'équipe Disrupt campus<br /> * Gestion des url externes de vidéo comme vidéo embarquées<br /> ** Vimeo<br /> ** Dailymotion<br /> * Gestion du renommage des url<br /> ** Ajout d'un champ de renommage à la remise des livrables<br /> ** Prise en compte de ce nom dans l'affichage de la vitrine<br /> * Correction de l'affichage d'aperçu lors de l'ajout d'un url externe<br /> <br /> === 18/03/19 ===<br /> * Ouverture de certains liens dans un autre onglet pour plus de simplicité<br /> * Gestion des liens externes dans l'overview des fichiers des projets<br /> * Retrait des livrables actuels de la liste des fichiers des projets pour éviter les doublons</div>

Zoran.Chanet https://air.imag.fr/index.php?title=PROJET-INFO5_1819_EDCampus&diff=45348 2019-03-18T18:59:36Z

<p>Zoran.Chanet: /* Semaine 7 - Vitrine */</p> <hr /> <div>[[File:Logo_EDCampus.png|thumb|right| Logo EDCampus]]<br /> = Le projet en quelques mots =<br /> La plateforme [[Contributions open-source au projet Eclipse EdCampus | EDCampus]] est une plateforme de gestion de projet développée par Disrupt Campus Grenoble. La plateforme est actuellement en train d’être soumise à la fondation Eclipse afin d’être mise en open source sous licence Eclipse. Dans le cadre du projet Disrupt Campus, les étudiants sont invités à contribuer à la plateforme. Dans le cadre de vos formations c’est une vraie plus valu de contribuer à de réels projets plutôt qu’à des projets one-shot qui seront mis à la poubelle sitôt votre soutenance terminée. EDCampus est donc une opportunité de contribuer au logiciel libre et à la fondation Eclipse (et de s'assurer une jolie ligne sur son CV plutôt qu'un projet qui sera aussi vite oublié que l'ECOM !).<br /> <br /> = L'équipe et leurs rôles =<br /> <br /> * GEOURJON Anthony - Chef de projet (EXT)<br /> * [[User:Servan.Charlot | CHARLOT Servan]] - Chef de groupe<br /> * [[User:Zoran.Chanet | CHANET Zoran]] - Responsable DevOps<br /> <br /> = Roadmap =<br /> * '''20-22 février 2019 :''' Hack Ton Campus, la plateforme EDCampus sera utilisée pour la gestion des défis.<br /> * '''Avril 2019 :''' Projet pilote, un projet mêlant une entreprise, l'UGA et des étudiants servira de test à la plateforme.<br /> * '''Septembre 2019 :''' Mise en production globale.<br /> <br /> = Captures d’écran =<br /> <br /> == Platforme ==<br /> <br /> &lt;gallery&gt;<br /> File:EDCampus 2019 P1.png<br /> File:EDCampus 2019 P2.png<br /> File:EDCampus 2019 P3.png<br /> &lt;/gallery&gt;<br /> <br /> == Vitrine ==<br /> <br /> &lt;gallery&gt;<br /> File:EDCampus 2019 VitrineUni.png<br /> File:EDCampus 2019 Vitrine1.png<br /> File:EDCampus 2019 Vitrine2.png<br /> File:EDCampus 2019 Vitrine3.png<br /> File:EDCampus 2019 Vitrine4.png<br /> &lt;/gallery&gt;<br /> <br /> = Carnet de bord =<br /> <br /> == Semaine 1 ==<br /> <br /> === 28/01/19 ===<br /> <br /> Assignation du sujet [[Contributions open-source au projet Eclipse EdCampus | EDCampus]].<br /> <br /> === 29/01/19 ===<br /> <br /> * Rencontre avec Anthony au [http://fabmstic.liglab.fr/ Fablab], présentation du sujet, des enjeux, et de la roadmap<br /> * Installation du projet<br /> ** Difficultés dues au DNS des réseaux universitaires (impossible de télécharger le contenu nécessaire depuis les containers)<br /> <br /> === 30/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $scope._getProjectParent()&lt;/code&gt; qui ne marchait pas du tout. Il y avait une faute dans la plupart des variables qui s'appelaient &lt;code&gt;currentParentProject&lt;/code&gt; au lieu de &lt;code&gt;currentProjectParent&lt;/code&gt;.<br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $rootScope._checkProject()&lt;/code&gt; qui oubliait un paramètre dans son appel à &lt;code&gt;$scope._setProject()&lt;/code&gt;.<br /> <br /> ==== Zoran ====<br /> * Assignation d'une première tâche : réparer la création d'un projet indépendant<br /> * Découverte du code du projet<br /> * Poursuite de l'arborescence des appels depuis le bouton jusqu'à l'appel à la base de données<br /> <br /> === 01/02/19 ===<br /> ==== Servan ====<br /> <br /> * Assignation de la tâche consistant à réparer le système de fichier.<br /> * Exploration du système de fichier et son implémentation.<br /> <br /> ==== Zoran ====<br /> * Production d'une méthode permettant des logs personnalisés<br /> * Recherches sur le rewriting d'URL<br /> * Correction du problème (lié au rewriting)<br /> * Production d'une fiche explicative de la solution<br /> <br /> == Semaine 2 ==<br /> <br /> === 04/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction des bugs suivants :<br /> <br /> * Affichage des fichiers du portefeuille père ssi il y a au moins un fichier présent dans le projet fils.<br /> ** Dans le backend, la fonction qui get les fichiers exécutait un &lt;code&gt;return false&lt;/code&gt; avant de get les fichiers parents dans le cas ou il n'y avait pas de fichier à la base.<br /> * N'actualise pas la liste des fichiers si on supprime le dernier fichier.<br /> * Tous les dossiers sont affichés comme des fichiers. Lors de la première sélection à la souris, si on sélectionne le fichier-dossier, il se transforme en dossier et on peut y accéder. Rien ne se passe pour les sélections suivantes.<br /> ** Dans le backend, un paramètre était traité comme chaîne de caractère alors qu'il représentait un booléen. Le résultat de ça est que l'on entrait dans la mauvaise partie d'un if, qui exécutait la mauvaise requête SQL nous privant de l'information concernant le type de fichier lu (un dossier est un type de fichier).<br /> * Le bouton qui permet de revenir en arrière, sortir du dossier ne fonctionne pas.<br /> * On ne peut pas entrer dans un dossier hérité.<br /> <br /> ==== Zoran ====<br /> * Assignation de la mise en place de techniques DevOps<br /> * Recherches sur la mise en place de pipeline dans GitLab : voir [[GitLab CI/CD | compte-rendu]]<br /> * Mise en place d'un pipeline à chaque push<br /> * Production d'un tutoriel de création de runner GitLab : voir [[GitLab Runners | tutoriel]]<br /> * Recherches sur SonarQube et les tests unitaires<br /> ** Priorisation de SonarQube<br /> <br /> === 05/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug qui faisait que lors de la suppression d'un dossier, les fichiers à l'intérieur ne sont pas supprimés (le champ statut dans le BDD ne passe pas à 0).<br /> ** La fonctionnalité de suppression récursive n'était pas implémentée dans &lt;code&gt;File.php&lt;/code&gt;.<br /> * Début de l'analyse du système de droit des utilisateurs (Administrateur/Tuteur/Élève) sur les fichiers et dossiers (hérités ou non).<br /> <br /> ==== Zoran ====<br /> * Compréhension des scanners sonar : voir [[SonarQube Scanner | compte-rendu]]<br /> * Mise en place d'un scan dans le pipeline<br /> ** Nécessité d'un serveur sonar exposé<br /> ** Décision d'utiliser SonarCloud<br /> ** Configuration du scanner pour envoyer le rapport dans le bon projet sonarcloud<br /> ** Réussite du premier scan<br /> <br /> === 06/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Suite de la correction du système de droits des fichiers/dossiers.<br /> <br /> * Correction d'un bug qui faisait que les utilisateurs ne peuvent pas entrer dans les dossiers hérites (ou télécharger les fichiers hérites).<br /> ** Le check de droit se fait dans une fonction qui check d'abord le &lt;code&gt;ownerId&lt;/code&gt;, puis le &lt;code&gt;projectId&lt;/code&gt; et puis enfin si le fichier appartient à un parent. Pour cela elle fait appel à la base pour récupérer la relation d’héritage. IL y avait une erreur de comparaison entre le résultat de la requête et les information fichier (erreur de type parce que PHP).<br /> * Analyse complète du système de droit création d'un tableau explicatif de l'état actuel et l'état voulu.<br /> [[File:EDCampus_2019_Tableau_de_droits.png|center]]<br /> * Suite au tableau, mise en place de la protection des fichiers hérités.<br /> ** Ajout d'une vérification sur le &lt;code&gt;projectId&lt;/code&gt;, empêchant les utilisateurs non propriétaires du fichier de le supprimer, renommer ou déplacer.<br /> <br /> ==== Zoran ====<br /> * Extension du scan sonar dans le pipeline à toutes les sections du projet<br /> * Affichage de badges d'état du pipeline sur la page de présentation de chaque section du projet<br /> * Reprise des recherches concernant les tests unitaires<br /> * Tentative de systématisation des tests dans le pipeline<br /> ** Difficulté : les tests nécessitent des fichiers de configurations qui ne sont pas présents sur le repository git<br /> * Recherche de contournement pour ne pas exposer des configurations privées dans le projet public<br /> <br /> === 08/02/19 ===<br /> <br /> ==== Servan ====<br /> Suppression de la vue pour les non membres et correction partielle du système de droits.<br /> * Lorsque qu'une commande est envoyée par le front-end vers le back-end, elle passe dans une fonction qui vérifie les droits (&lt;code&gt;Right.php checkRights($command)&lt;/code&gt;). La fonction compare la commande utilisée par l'utilisateur aux commandes que cet utilisateur a en général le droit d'utiliser. Le problème était que le tableau de commandes au sein de la fonction (permettant la comparaison) contenait des commandes mal formatées. J'ai donc corrigé celle qui m'intéressais pour empêcher les non membres d'un projet à consulter les fichiers, et j'en ai profiter pour corriger toutes les autres.<br /> <br /> ==== Zoran ====<br /> * Configuration des scanners sonar dans le pipeline (redirection vers une branche du projet sonarcloud nommée selon la branche GitLab sur laquelle le pipeline est lancé)<br /> * Aide à la correction du système de droits<br /> * Réalisation de tâches mineures importantes pour le Hackaton<br /> ** Retirer la vidéo Waza de l'accueil de la plateforme<br /> ** Redirection de l'utilisateur vers la plateforme lorsqu'il accède à l'url du dossier : [[Apache mod_rewrite]]<br /> ** Correction de l'url donné lors de l'appel au service de mails pour la validation de compte<br /> <br /> == Semaine 3 ==<br /> <br /> === 12/02/19 ===<br /> <br /> ==== Servan ====<br /> * Système de droits entièrement corrigé pour le cas des fichiers.<br /> ** Privilèges administrateurs.<br /> *** Dans la fonction qui vérifie les droits &lt;code&gt;Right.php checkRights($command)&lt;/code&gt;, le cas de l'administrateur n'était pas vraiment traité. Il y avait une vérification pour empêcher tout utilisateur non administrateur d’exécuter une commande administrateur, mais sinon l'administrateur était traité comme un utilisateur lambda. J'ai donc ajouté un test permettant de donner les pleins pouvoirs. Presque. Il fallait aussi ajouter un test dans la fonction &lt;code&gt;File.php _checkFileAccess(...)&lt;/code&gt; qui pour certaines actions sur les fichiers, agit comme une surcouche à la fonction &lt;code&gt;checkRights&lt;/code&gt; (ce qui permet entre autres des actions sur les fichiers hérités pour le tuteur et les membres).<br /> ** Cas du déplacement de fichier hérités.<br /> *** Avec l'accord d'Anthony, on a conclu que le déplacement de fichier hérité était une mauvaise idée, donc cela reste non autorisé, même pour les admins.<br /> * Correction du fait que les fichiers ayant un numéro pour nom ne peuvent pas être supprimés.<br /> ** Les appels à la base effectuait une comparaison avec un &lt;code&gt;LIKE&lt;/code&gt; au lieu d'un &lt;code&gt;=&lt;/code&gt; dans la requête SQL, ce qui ne marchait pas dans le cas présent.<br /> * Correction du fait que les fichiers ayant un numéro pour nom ne peuvent pas être renommés.<br /> ** Le nom du fichier est traité et enregistré par le fichier JS, qui est non typé donc il décide que si le nom n'est que des numéros, alors ce ne sera pas une string. Or pour renommer le fichier, on veux modifier la partie du nom qui est avant le point (de l'extension), donc on fait un appel à &lt;code&gt;name.lastIndexOf(&quot;.&quot;);&lt;/code&gt;, qui s’exécute exclusivement sur une string. J'ai donc réalise un &lt;code&gt;.toString()&lt;/code&gt; sur le nom à chaque fois que nécessaire.<br /> * Correction du fait que lorsque l'on supprimait un fichier dans un dossier, on était renvoyé à la racine du projet plutôt que dans le dossier.<br /> ** Il manquait un paramètre (le dossier) à la fonction &lt;code&gt;getFiles(...)&lt;/code&gt; appelée après la suppression.<br /> * Transformation du bouton &quot;Ajouter&quot; en deux boutons, un pour les dossiers, un pour les fichiers.<br /> <br /> ==== Zoran ====<br /> * Mise à Jour de templates de mail (&gt;100 templates)<br /> ** Remplacement des références à Waza Education par EDCampus<br /> ** Production d'une banière et remplacement de l'ancienne<br /> * Tests des fichiers de configuration des tests unitaires<br /> * Recherches sur le passage de l'HTTP vers HTTPS avec [https://letsencrypt.org/ Let's Encrypt] : voir le [[Let's Encrypt | résumé rapide]]<br /> ** Choix d'utilisation de [https://certbot.eff.org/ Certbot]<br /> <br /> === 13/02/19 ===<br /> <br /> ==== Servan ====<br /> Nouvelle tâche assignée : Améliorer les tâches, faire en sorte que si un nom est placé sur un label d'une couleur au sein d'un projet, tous les labels de cette couleur auront ce même nom.<br /> <br /> ==== Zoran ====<br /> * Sauvegarde de la base de données de l'ancienne plateforme<br /> * Passage de l'ancienne plateforme de l'HTTP à l'HTTPS<br /> ** Réparation de la configuration d'Apache<br /> ** Génération des certificats<br /> ** Configuration d'Apache pour l'HTTPS<br /> <br /> === 14/02/19 ===<br /> <br /> ==== Servan ====<br /> * Backend corrigé, on ne peux plus créer un label d'un nom au choix si il y a déjà un label de cette couleur avec un nom dans le projet.<br /> * Etude approfondie du front-end et du système événementiel pour corriger les défauts de mise à jour.<br /> <br /> ==== Zoran ====<br /> * Recherches sur l'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Découverte et compréhension d'une [https://github.com/BirgerK/docker-apache-letsencrypt image existante]<br /> * Tentative de passage de l'HTTP à l'HTTPS dans un Docker<br /> ** Sur la VM de l'ancienne plateforme (pour ne pas briser la version en prod)<br /> ** Fusion du Dockerfile existant et du Dockerfile de l'image trouvée<br /> <br /> === 15/02/19 ===<br /> <br /> ==== Servan ====<br /> * Correction superficielle des problèmes des mise a jour a de la vue du système de tache. Le soucis étant que les taches et le petit menu qui indique les détails ne sont pas le même module et n'interagissent pas vraiment entre eux, donc on ne peux pas actualiser l'un depuis l'autre.<br /> * Correction du fait que dans le système de fichier, on ne pouvait pas délacer un fichier/dossier vers le dossier parent en le glissant sur la flèche retour. <br /> ** Le soucis venait du fichier html, qui avait l'air correct mais la variable qu'il était censé récupérer renvoyait undefined au lieu de l'identifiant du dossier parent.<br /> <br /> ==== Zoran ====<br /> * Poursuite de la tentative d'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Succès de la création de certificat<br /> ** L'HTTPS ne fonctionne toujours pas (sans doute à cause de la configuration d'Apache)<br /> <br /> == Semaine 4 ==<br /> <br /> Hack ton campus.<br /> <br /> == Semaine 5 ==<br /> <br /> Vacances d'hiver.<br /> <br /> == Semaine 6 ==<br /> <br /> === 05/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug trouvé lors que hackaton qui empêchait les étudiants de télécharger un fichier hérité appartenant à un tuteur. <br /> * Début d'un travail sur les tests unitaires du backend. Le but est de vérifier les tests existants, essayer de les faire fonctionner, et s'en inspirer pour en créer d'autres et à terme, couvrir tout le code.<br /> <br /> ==== Zoran ====<br /> * Succès de la mise en place d'HTTPS dans un docker<br /> ** Modification de &lt;code&gt;docker-compose.yml&lt;/code&gt; pour lier les ports 443 de l'hôte et du conteneur<br /> ** Finalisation de la configuration d'Apache dans le conteneur<br /> <br /> === 06/03/19 ===<br /> <br /> ==== Servan et Zoran ====<br /> <br /> * Lecture de la [https://phpunit.readthedocs.io/en/8.0/ documentation de PHPUNit.]<br /> Après un travail de recherche, nous nous sommes rendu compte que PHPUnit allait être difficile à mettre en place sur le backend du projet. En effet, toutes les fonctions sont en ''static'' et il est impossible de mocker les fonctions statiques avec PHPUnit. Il faudrait donc revoir l'architecture du code pour mocker le statique, et donc remplacer les appels à la base de données par des appels simulés. Cela éviterait d'avoir à créer une base externe accessible ou construire une base dans le runner du pipeline. Cependant cela est trop long a mettre en place sachant que l'on arrive sur la fin du projet, donc nous avons donné priorité à la vitrine, suite à une réunion avec les membres de Disrupt campus. <br /> <br /> La vitrine est un endroit où le public (étudiants/professeurs/entreprises) peut consulter les projets réalisés ou en cours. Cette vitrine se décompose en un endroit ou l'on peut consulter la liste des projets d'une université, et des pages de projet individuelles avec une image, une description et les livrables.<br /> <br /> === 07/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction d'un bug en rapport avec les accents dans les noms. Lorsque qu'un utilisateur possède un accent dans son nom (ex: Amélie), au moment de la création du login la chaîne de caractère est mal interprétée et le login est tronqué au niveau de l'accent (ex: amY). L'architecture fait que lors du transfert du nom du front vers le back, l'accent est codé avec des caractères classiques, qui sont ensuite interprétés correctement lors de l'ajout en base. Mais cela veux dire que pendant tout le passage en backend on travaille avec des accents codés. Le login était créé à partir du nom et du prénom de l'utilisateur, qui peuvent donc être temporairement corrompus par des accents codés. La correction de ce soucis est donc détecter la présence d'accents dans les noms, et si il y en a, créer le login à partir de la première partie de l'adresse mail de l'utilisateur (avant le @), sinon, on fait comme avant avec les noms.<br /> <br /> ==== Zoran ====<br /> * Correction d'un bug empêchant l'envoi d'e-mail lors de l'ajout d'un utilisateur à un projet<br /> * Prospection dans le code et la base de donnée pour permettre l'affichage ou non des évaluations dans le menu des projets. La section des évaluations étant gérée différemment des autres sections, ce travail nécessitera plus de temps que prévu et a donc été reporté au profit de la vitrine<br /> <br /> === 08/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Archéologie sur le prototype de vitrine.<br /> * Rédaction de documentation générale sur l'architecture End-To-End du projet (ci-dessous).<br /> <br /> [[File:EDCampus 2019 EndToEnd.png|border]]<br /> <br /> Détails de la fonction &lt;code&gt;checkRights&lt;/code&gt; :<br /> <br /> * La commande en cours est envoyée à &lt;code&gt;checkRights&lt;/code&gt; sous forme de string.<br /> * On vérifie d'abord si elle fait partie des commandes publiques, que l'on peux exécuter lorsque l'on a pas de session. (Via une comparaison avec un tableau contenant toutes les commandes publiques.)<br /> * Si ce n'est pas la cas, on récupère ensuite les informations de session et l'identifiant utilisateur.<br /> * Si on ne trouve pas d'utilisateur, on regarde si on essai d’accéder a une page publique, sinon on bloque l'accès.<br /> * On a maintenant un utilisateur avec une session, qui essaie d'agir sur une page non publique.<br /> * On vérifie si l'utilisateur est super-administrateur.<br /> * On vérifie si l'utilisateur essai d’exécuter une commande administrateur, en tant qu'administrateur.<br /> * Puisque la page est non-publique et que l'on est pas administrateur, il s'agit forcement d'une page de projet. <br /> * On vérifie si l'utilisateur est propriétaire du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est propriétaire du projet courant et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet courant et que cette commande est autorisée.<br /> * Si aucun des tests ci dessus n'a raté (ou n'a déjà accordé l'accès), on accorde l'accès.<br /> <br /> ==== Zoran ====<br /> * Archéologie sur le prototype de vitrine<br /> * Réparation des appels au serveur opérés par le prototype de vitrine existant<br /> ** La vitrine étant écrite en php et non en utilisant AngularJS comme le reste du front-end, la gestion des appels est différente<br /> ** Correction du lien par lequel le serveur est appelé<br /> ** Correction des arguments et de la commande donnés lors de l'appel au serveur<br /> * Correction du nombre de projets affichés avant extension<br /> * Prospection pour l'utilisation future de la vitrine<br /> <br /> == Semaine 7 - Vitrine ==<br /> <br /> === 11/03/19 ===<br /> <br /> * Correction d'un bug d'affichage. L'administrateur peut choisir dans son profil quel est son campus principal, et cela est utile entre autres dans la partie communication de son dashboard. C'est à cet endroit qu'il peut choisir de rendre publique la page de son université (ie. la vitrine). A cet endroit, la vitrine est renseignée par un lien (&lt;code&gt;http://localhost/app/campus/?u=UGA&lt;/code&gt;), contenant le nom du campus au bout (UGA). Le bug faisait que ce nom n'était pas affiché et donc l'URL était incomplet. Le soucis venait du backend, ou la requête du campus à la base ne demandait pas le champ nom.<br /> * Correction des projets affichés en vitrine<br /> ** Affichage des projets fils et indépendants seulement (pas les portefeuilles)<br /> ** Explicitation du nom des projets fils (Si ''Equipe A'' appartient au portefeuille ''Défi 3'', son nom affiché sera ''Défi 3 &gt; Equipe A'')<br /> * Ajout d'un texte de remplacement lorsqu'une section est vide (plus élégant qu'un grand espace vide)<br /> <br /> === 12/03/19 ===<br /> * Création d'une page vitrine de projet<br /> ** Ecriture de cette page comme un composant AngularJS, pour coller à la nouvelle méthode<br /> ** Création des sections principales (titre, description, membres)<br /> * Harmonisation du visuel<br /> ** Beaucoup de CSS<br /> <br /> === 13/03/19 ===<br /> * Ajout de nouvelles sections<br /> ** Modification des requêtes et des droits pour rendre public les informations souhaitées<br /> ** Sections dates, thèmes, mots-clés, organisations<br /> * Réunion/démonstration avec Gérard<br /> <br /> === 14/03/19 ===<br /> * Création de la section livrables<br /> ** Nombreux ajustements sur les requêtes<br /> * Implémentation des url externes comme livrable<br /> ** Section url externe à la remise des livrables<br /> ** Gestion des url en base<br /> <br /> === 15/03/19 ===<br /> * Gestion des droits de téléchargement des livrables depuis la vitrine<br /> * Gestion des url externes de vidéo comme vidéo embarquées<br /> ** Youtube<br /> * Réunion/démonstration avec l'équipe Disrupt campus<br /> * Gestion des url externes de vidéo comme vidéo embarquées<br /> ** Vimeo<br /> ** Dailymotion<br /> * Gestion du renommage des url<br /> ** Ajout d'un champ de renommage à la remise des livrables<br /> ** Prise en compte de ce nom dans l'affichage de la vitrine<br /> * Correction de l'affichage d'aperçu lors de l'ajout d'un url externe<br /> <br /> === 18/03/19 ===<br /> * Ouverture de certains liens dans un autre onglet pour plus de simplicité<br /> * Gestion des liens externes dans l'overview des fichiers des projets<br /> * Retrait des livrables actuels de la liste des fichiers des projets pour éviter les doublons</div>

Zoran.Chanet https://air.imag.fr/index.php?title=PROJET-INFO5_1819_EDCampus&diff=45315 2019-03-18T12:30:39Z

<p>Zoran.Chanet: /* 15/03/19 */</p> <hr /> <div>[[File:Logo_EDCampus.png|thumb|right| Logo EDCampus]]<br /> = Le projet en quelques mots =<br /> La plateforme [[Contributions open-source au projet Eclipse EdCampus | EDCampus]] est une plateforme de gestion de projet développée par Disrupt Campus Grenoble. La plateforme est actuellement en train d’être soumise à la fondation Eclipse afin d’être mise en open source sous licence Eclipse. Dans le cadre du projet Disrupt Campus, les étudiants sont invités à contribuer à la plateforme. Dans le cadre de vos formations c’est une vraie plus valu de contribuer à de réels projets plutôt qu’à des projets one-shot qui seront mis à la poubelle sitôt votre soutenance terminée. EDCampus est donc une opportunité de contribuer au logiciel libre et à la fondation Eclipse (et de s'assurer une jolie ligne sur son CV plutôt qu'un projet qui sera aussi vite oublié que l'ECOM !).<br /> <br /> = L'équipe et leurs rôles =<br /> <br /> * GEOURJON Anthony - Chef de projet (EXT)<br /> * [[User:Servan.Charlot | CHARLOT Servan]] - Chef de groupe<br /> * [[User:Zoran.Chanet | CHANET Zoran]] - Responsable DevOps<br /> <br /> = Roadmap =<br /> * '''20-22 février 2019 :''' Hack Ton Campus, la plateforme EDCampus sera utilisée pour la gestion des défis.<br /> * '''Avril 2019 :''' Projet pilote, un projet mêlant une entreprise, l'UGA et des étudiants servira de test à la plateforme.<br /> * '''Septembre 2019 :''' Mise en production globale.<br /> <br /> = Carnet de bord =<br /> <br /> == Semaine 1 ==<br /> <br /> === 28/01/19 ===<br /> <br /> Assignation du sujet [[Contributions open-source au projet Eclipse EdCampus | EDCampus]].<br /> <br /> === 29/01/19 ===<br /> <br /> * Rencontre avec Anthony au [http://fabmstic.liglab.fr/ Fablab], présentation du sujet, des enjeux, et de la roadmap<br /> * Installation du projet<br /> ** Difficultés dues au DNS des réseaux universitaires (impossible de télécharger le contenu nécessaire depuis les containers)<br /> <br /> === 30/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $scope._getProjectParent()&lt;/code&gt; qui ne marchait pas du tout. Il y avait une faute dans la plupart des variables qui s'appelaient &lt;code&gt;currentParentProject&lt;/code&gt; au lieu de &lt;code&gt;currentProjectParent&lt;/code&gt;.<br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $rootScope._checkProject()&lt;/code&gt; qui oubliait un paramètre dans son appel à &lt;code&gt;$scope._setProject()&lt;/code&gt;.<br /> <br /> ==== Zoran ====<br /> * Assignation d'une première tâche : réparer la création d'un projet indépendant<br /> * Découverte du code du projet<br /> * Poursuite de l'arborescence des appels depuis le bouton jusqu'à l'appel à la base de données<br /> <br /> === 01/02/19 ===<br /> ==== Servan ====<br /> <br /> * Assignation de la tâche consistant à réparer le système de fichier.<br /> * Exploration du système de fichier et son implémentation.<br /> <br /> ==== Zoran ====<br /> * Production d'une méthode permettant des logs personnalisés<br /> * Recherches sur le rewriting d'URL<br /> * Correction du problème (lié au rewriting)<br /> * Production d'une fiche explicative de la solution<br /> <br /> == Semaine 2 ==<br /> <br /> === 04/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction des bugs suivants :<br /> <br /> * Affichage des fichiers du portefeuille père ssi il y a au moins un fichier présent dans le projet fils.<br /> ** Dans le backend, la fonction qui get les fichiers exécutait un &lt;code&gt;return false&lt;/code&gt; avant de get les fichiers parents dans le cas ou il n'y avait pas de fichier à la base.<br /> * N'actualise pas la liste des fichiers si on supprime le dernier fichier.<br /> * Tous les dossiers sont affichés comme des fichiers. Lors de la première sélection à la souris, si on sélectionne le fichier-dossier, il se transforme en dossier et on peut y accéder. Rien ne se passe pour les sélections suivantes.<br /> ** Dans le backend, un paramètre était traité comme chaîne de caractère alors qu'il représentait un booléen. Le résultat de ça est que l'on entrait dans la mauvaise partie d'un if, qui exécutait la mauvaise requête SQL nous privant de l'information concernant le type de fichier lu (un dossier est un type de fichier).<br /> * Le bouton qui permet de revenir en arrière, sortir du dossier ne fonctionne pas.<br /> * On ne peut pas entrer dans un dossier hérité.<br /> <br /> ==== Zoran ====<br /> * Assignation de la mise en place de techniques DevOps<br /> * Recherches sur la mise en place de pipeline dans GitLab : voir [[GitLab CI/CD | compte-rendu]]<br /> * Mise en place d'un pipeline à chaque push<br /> * Production d'un tutoriel de création de runner GitLab : voir [[GitLab Runners | tutoriel]]<br /> * Recherches sur SonarQube et les tests unitaires<br /> ** Priorisation de SonarQube<br /> <br /> === 05/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug qui faisait que lors de la suppression d'un dossier, les fichiers à l'intérieur ne sont pas supprimés (le champ statut dans le BDD ne passe pas à 0).<br /> ** La fonctionnalité de suppression récursive n'était pas implémentée dans &lt;code&gt;File.php&lt;/code&gt;.<br /> * Début de l'analyse du système de droit des utilisateurs (Administrateur/Tuteur/Élève) sur les fichiers et dossiers (hérités ou non).<br /> <br /> ==== Zoran ====<br /> * Compréhension des scanners sonar : voir [[SonarQube Scanner | compte-rendu]]<br /> * Mise en place d'un scan dans le pipeline<br /> ** Nécessité d'un serveur sonar exposé<br /> ** Décision d'utiliser SonarCloud<br /> ** Configuration du scanner pour envoyer le rapport dans le bon projet sonarcloud<br /> ** Réussite du premier scan<br /> <br /> === 06/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Suite de la correction du système de droits des fichiers/dossiers.<br /> <br /> * Correction d'un bug qui faisait que les utilisateurs ne peuvent pas entrer dans les dossiers hérites (ou télécharger les fichiers hérites).<br /> ** Le check de droit se fait dans une fonction qui check d'abord le &lt;code&gt;ownerId&lt;/code&gt;, puis le &lt;code&gt;projectId&lt;/code&gt; et puis enfin si le fichier appartient à un parent. Pour cela elle fait appel à la base pour récupérer la relation d’héritage. IL y avait une erreur de comparaison entre le résultat de la requête et les information fichier (erreur de type parce que PHP).<br /> * Analyse complète du système de droit création d'un tableau explicatif de l'état actuel et l'état voulu.<br /> [[File:EDCampus_2019_Tableau_de_droits.png|center]]<br /> * Suite au tableau, mise en place de la protection des fichiers hérités.<br /> ** Ajout d'une vérification sur le &lt;code&gt;projectId&lt;/code&gt;, empêchant les utilisateurs non propriétaires du fichier de le supprimer, renommer ou déplacer.<br /> <br /> ==== Zoran ====<br /> * Extension du scan sonar dans le pipeline à toutes les sections du projet<br /> * Affichage de badges d'état du pipeline sur la page de présentation de chaque section du projet<br /> * Reprise des recherches concernant les tests unitaires<br /> * Tentative de systématisation des tests dans le pipeline<br /> ** Difficulté : les tests nécessitent des fichiers de configurations qui ne sont pas présents sur le repository git<br /> * Recherche de contournement pour ne pas exposer des configurations privées dans le projet public<br /> <br /> === 08/02/19 ===<br /> <br /> ==== Servan ====<br /> Suppression de la vue pour les non membres et correction partielle du système de droits.<br /> * Lorsque qu'une commande est envoyée par le front-end vers le back-end, elle passe dans une fonction qui vérifie les droits (&lt;code&gt;Right.php checkRights($command)&lt;/code&gt;). La fonction compare la commande utilisée par l'utilisateur aux commandes que cet utilisateur a en général le droit d'utiliser. Le problème était que le tableau de commandes au sein de la fonction (permettant la comparaison) contenait des commandes mal formatées. J'ai donc corrigé celle qui m'intéressais pour empêcher les non membres d'un projet à consulter les fichiers, et j'en ai profiter pour corriger toutes les autres.<br /> <br /> ==== Zoran ====<br /> * Configuration des scanners sonar dans le pipeline (redirection vers une branche du projet sonarcloud nommée selon la branche GitLab sur laquelle le pipeline est lancé)<br /> * Aide à la correction du système de droits<br /> * Réalisation de tâches mineures importantes pour le Hackaton<br /> ** Retirer la vidéo Waza de l'accueil de la plateforme<br /> ** Redirection de l'utilisateur vers la plateforme lorsqu'il accède à l'url du dossier : [[Apache mod_rewrite]]<br /> ** Correction de l'url donné lors de l'appel au service de mails pour la validation de compte<br /> <br /> == Semaine 3 ==<br /> <br /> === 12/02/19 ===<br /> <br /> ==== Servan ====<br /> * Système de droits entièrement corrigé pour le cas des fichiers.<br /> ** Privilèges administrateurs.<br /> *** Dans la fonction qui vérifie les droits &lt;code&gt;Right.php checkRights($command)&lt;/code&gt;, le cas de l'administrateur n'était pas vraiment traité. Il y avait un versification pour empêcher tout utilisateur non administrateur d’exécuter une commande administrateur, mais sinon l'administrateur était traité comme un utilisateur lambda. J'ai donc ajouté un test permettant de donner les pleins pouvoirs. Presque. Il fallait aussi ajouter un test dans la fonction &lt;code&gt;File.php _checkFileAccess(...)&lt;/code&gt; qui pour certaines actions sur les fichiers, agit comme une surcouche à la fonction &lt;code&gt;checkRights&lt;/code&gt; (ce qui permet entre autres des actions sur les fichiers hérités pour le tuteur et les membres).<br /> ** Cas du déplacement de fichier hérités.<br /> *** Avec l'accord d'Anthony, on a conclu que le déplacement de fichier hérité était une mauvaise idée, donc cela reste non autorisé, même pour les admins.<br /> * Correction du fait que les fichiers ayant un numéro pour nom ne peuvent pas être supprimés.<br /> ** Les appels à la base effectuait une comparaison avec un &lt;code&gt;LIKE&lt;/code&gt; au lieu d'un &lt;code&gt;=&lt;/code&gt; dans la requête SQL, ce qui ne marchait pas dans le cas présent.<br /> * Correction du fait que les fichiers ayant un numéro pour nom ne peuvent pas être renommés.<br /> ** Le nom du fichier est traité et enregistré par le fichier JS, qui est non typé donc il décide que si le nom n'est que des numéros, alors ce ne sera pas une string. Or pour renommer le fichier, on veux modifier la partie du nom qui est avant le point (de l'extension), donc on fait un appel à &lt;code&gt;name.lastIndexOf(&quot;.&quot;);&lt;/code&gt;, qui s’exécute exclusivement sur une string. J'ai donc réalise un &lt;code&gt;.toString()&lt;/code&gt; sur le nom à chaque fois que nécessaire.<br /> * Correction du fait que lorsque l'on supprimait un fichier dans un dossier, on était renvoyé à la racine du projet plutôt que dans le dossier.<br /> ** Il manquait un paramètre (le dossier) à la fonction &lt;code&gt;getFiles(...)&lt;/code&gt; appelée après la suppression.<br /> * Transformation du bouton &quot;Ajouter&quot; en deux boutons, un pour les dossiers, un pour les fichiers.<br /> <br /> ==== Zoran ====<br /> * Mise à Jour de templates de mail (&gt;100 templates)<br /> ** Remplacement des références à Waza Education par EDCampus<br /> ** Production d'une banière et remplacement de l'ancienne<br /> * Tests des fichiers de configuration des tests unitaires<br /> * Recherches sur le passage de l'HTTP vers HTTPS avec [https://letsencrypt.org/ Let's Encrypt] : voir le [[Let's Encrypt | résumé rapide]]<br /> ** Choix d'utilisation de [https://certbot.eff.org/ Certbot]<br /> <br /> === 13/02/19 ===<br /> <br /> ==== Servan ====<br /> Nouvelle tâche assignée : Améliorer les tâches, faire en sorte que si un nom est placé sur un label d'une couleur au sein d'un projet, tous les labels de cette couleur auront ce même nom.<br /> <br /> ==== Zoran ====<br /> * Sauvegarde de la base de données de l'ancienne plateforme<br /> * Passage de l'ancienne plateforme de l'HTTP à l'HTTPS<br /> ** Réparation de la configuration d'Apache<br /> ** Génération des certificats<br /> ** Configuration d'Apache pour l'HTTPS<br /> <br /> === 14/02/19 ===<br /> <br /> ==== Servan ====<br /> * Backend corrigé, on ne peux plus créer une tache d'un nom au choix si il y a déjà une tache de cette couleur avec un nom dans le projet.<br /> * Etude approfondie du front-end et du système événementiel pour corriger les défauts de mise à jour.<br /> <br /> ==== Zoran ====<br /> * Recherches sur l'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Découverte et compréhension d'une [https://github.com/BirgerK/docker-apache-letsencrypt image existante]<br /> * Tentative de passage de l'HTTP à l'HTTPS dans un Docker<br /> ** Sur la VM de l'ancienne plateforme (pour ne pas briser la version en prod)<br /> ** Fusion du Dockerfile existant et du Dockerfile de l'image trouvée<br /> <br /> === 15/02/19 ===<br /> <br /> ==== Servan ====<br /> * Correction superficielle des problèmes des mise a jour a de la vue du système de tache. Le soucis étant que les taches et le petit menu qui indique les détails ne sont pas le même module et n'interagissent pas vraiment entre eux, donc on ne peux pas actualiser l'un depuis l'autre.<br /> * Correction du fait que dans le système de fichier, on ne pouvait pas délacer un fichier/dossier vers le dossier parent en le glissant sur la flèche retour. <br /> ** Le soucis venait du fichier html, qui avait l'air correct mais la variable qu'il était censé récupérer renvoyait undefined au lieu de l'identifiant du dossier parent.<br /> <br /> ==== Zoran ====<br /> * Poursuite de la tentative d'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Succès de la création de certificat<br /> ** L'HTTPS ne fonctionne toujours pas (sans doute à cause de la configuration d'Apache)<br /> <br /> == Semaine 4 ==<br /> <br /> Hack ton campus.<br /> <br /> == Semaine 5 ==<br /> <br /> Vacances d'hiver.<br /> <br /> == Semaine 6 ==<br /> <br /> === 05/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug trouvé lors que hackaton qui empêchait les étudiants de télécharger un fichier hérité appartenant à un tuteur. <br /> * Début d'un travail sur les tests unitaires du backend. Le but est de vérifier les tests existants, essayer de les faire fonctionner, et s'en inspirer pour en créer d'autres et à terme, couvrir tout le code.<br /> <br /> ==== Zoran ====<br /> * Succès de la mise en place d'HTTPS dans un docker<br /> ** Modification de &lt;code&gt;docker-compose.yml&lt;/code&gt; pour lier les ports 443 de l'hôte et du conteneur<br /> ** Finalisation de la configuration d'Apache dans le conteneur<br /> <br /> === 06/03/19 ===<br /> <br /> ==== Servan et Zoran ====<br /> <br /> * Lecture de la [https://phpunit.readthedocs.io/en/8.0/ documentation de PHPUNit.]<br /> Après un travail de recherche, nous nous sommes rendu compte que PHPUnit allait être difficile à mettre en place sur le backend du projet. En effet, toutes les fonctions sont en ''static'' et il est impossible de mocker les fonctions statiques avec PHPUnit. Il faudrait donc revoir l'architecture du code pour mocker le statique, et donc remplacer les appels à la base de données par des appels simulés. Cela éviterait d'avoir à créer une base externe accessible ou construire une base dans le runner du pipeline. Cependant cela est trop long a mettre en place sachant que l'on arrive sur la fin du projet, donc nous avons donné priorité à la vitrine, suite à une réunion avec les membres de Disrupt campus. <br /> <br /> La vitrine est un endroit où le public (étudiants/professeurs/entreprises) peut consulter les projets réalisés ou en cours. Cette vitrine se décompose en un endroit ou l'on peut consulter la liste des projets d'une université, et des pages de projet individuelles avec une image, une description et les livrables.<br /> <br /> === 07/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction d'un bug en rapport avec les accents dans les noms. Lorsque qu'un utilisateur possède un accent dans son nom (ex: Amélie), au moment de la création du login la chaîne de caractère est mal interprétée et le login est tronqué au niveau de l'accent (ex: amY). L'architecture fait que lors du transfert du nom du front vers le back, l'accent est codé avec des caractères classiques, qui sont ensuite interprétés correctement lors de l'ajout en base. Mais cela veux dire que pendant tout le passage en backend on travaille avec des accents codés. Le login était créé à partir du nom et du prénom de l'utilisateur, qui peuvent donc être temporairement corrompus par des accents codés. La correction à se soucis est donc détecter la présence d'accents dans les noms, et si il y en a, créer le login à partir de la première partie de l'adresse mail de l'utilisateur (avant le @), sinon, on fait comme avant avec les noms.<br /> <br /> ==== Zoran ====<br /> * Correction d'un bug empêchant l'envoi d'e-mail lors de l'ajout d'un utilisateur à un projet<br /> * Prospection dans le code et la base de donnée pour permettre l'affichage ou non des évaluations dans le menu des projets. La section des évaluations étant gérée différemment des autres sections, ce travail nécessitera plus de temps que prévu et a donc été reporté au profit de la vitrine<br /> <br /> === 08/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Archéologie sur le prototype de vitrine.<br /> * Rédaction de documentation générale sur l'architecture End-To-End du projet (ci-dessous).<br /> <br /> [[File:EDCampus 2019 EndToEnd.png|border]]<br /> <br /> Détails de la fonction &lt;code&gt;checkRights&lt;/code&gt; :<br /> <br /> * La commande en cours est envoyée à &lt;code&gt;checkRights&lt;/code&gt; sous forme de string.<br /> * On vérifie d'abord si elle fait partie des commandes publiques, que l'on peux exécuter lorsque l'on a pas de session. (Via une comparaison avec un tableau contenant toutes les commandes publiques.)<br /> * Si ce n'est pas la cas, on récupère ensuite les informations de session et l'identifiant utilisateur.<br /> * Si on ne trouve pas d'utilisateur, on regarde si on essai d’accéder a une page publique, sinon on bloque l'accès.<br /> * On a maintenant un utilisateur avec une session, qui essaie d'agir sur une page non publique.<br /> * On vérifie si l'utilisateur est super-administrateur.<br /> * On vérifie si l'utilisateur essai d’exécuter une commande administrateur, en tant qu'administrateur.<br /> * Puisque la page est non-publique et que l'on est pas administrateur, il s'agit forcement d'une page de projet. <br /> * On vérifie si l'utilisateur est propriétaire du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est propriétaire du projet courant et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet courant et que cette commande est autorisée.<br /> * Si aucun des tests ci dessus n'a raté (ou n'a déjà accordé l'accès), on accorde l'accès.<br /> <br /> ==== Zoran ====<br /> * Archéologie sur le prototype de vitrine<br /> * Réparation des appels au serveur opérés par le prototype de vitrine existant<br /> ** La vitrine étant écrite en php et non en utilisant AngularJS comme le reste du front-end, la gestion des appels est différente<br /> ** Correction du lien par lequel le serveur est appelé<br /> ** Correction des arguments et de la commande donnés lors de l'appel au serveur<br /> * Correction du nombre de projets affichés avant extension<br /> * Prospection pour l'utilisation future de la vitrine<br /> <br /> == Semaine 7 - Vitrine ==<br /> <br /> === 11/03/19 ===<br /> <br /> * Correction d'un bug d'affichage. L'administrateur peut choisir dans son profil quel est son campus principal, et cela est utile entre autres dans la partie communication de son dashboard. C'est à cet endroit qu'il peut choisir de rendre publique la page de son université (ie. la vitrine). A cet endroit, la vitrine est renseignée par un lien (&lt;code&gt;http://localhost/app/campus/?u=UGA&lt;/code&gt;), contenant le nom du campus au bout (UGA). Le bug faisait que ce nom n'était pas affiché et donc l'URL était incomplet. Le soucis venait du backend, ou la requête du campus à la base ne demandait pas le champ nom.<br /> * Correction des projets affichés en vitrine<br /> ** Affichage des projets fils et indépendants seulement (pas les portefeuilles)<br /> ** Explicitation du nom des projets fils (Si ''Equipe A'' appartient au portefeuille ''Défi 3'', son nom affiché sera ''Défi 3 &gt; Equipe A''<br /> * Ajout d'un texte de remplacement lorsqu'une section est vide (plus élégant qu'un grand espace vide)<br /> <br /> === 12/03/19 ===<br /> * Création d'une page vitrine de projet<br /> ** Ecriture de cette page comme un composant AngularJS, pour coller à la nouvelle méthode<br /> ** Création des sections principales (titre, description, membres)<br /> * Harmonisation du visuel<br /> ** Beaucoup de CSS<br /> <br /> === 13/03/19 ===<br /> * Ajout de nouvelles sections<br /> ** Modification des requêtes et des droits pour rendre public les informations souhaitées<br /> ** Sections dates, thèmes, mots-clés, organisations<br /> * Réunion/démonstration avec Gérard<br /> <br /> === 14/03/19 ===<br /> * Création de la section livrables<br /> ** Nombreux ajustements sur les requêtes<br /> * Implémentation des url externes comme livrable<br /> ** Section url externe à la remise des livrables<br /> ** Gestion des url en base<br /> <br /> === 15/03/19 ===<br /> * Gestion des droits de téléchargement des livrables depuis la vitrine<br /> * Gestion des url externes de vidéo comme vidéo embarquées<br /> ** Youtube<br /> * Réunion/démonstration avec l'équipe Disrupt campus<br /> * Gestion des url externes de vidéo comme vidéo embarquées<br /> ** Vimeo<br /> ** Dailymotion<br /> * Gestion du renommage des url<br /> ** Ajout d'un champ de renommage à la remise des livrables<br /> ** Prise en compte de ce nom dans l'affichage de la vitrine<br /> * Correction de l'affichage d'aperçu lors de l'ajout d'un url externe</div>

Zoran.Chanet https://air.imag.fr/index.php?title=PROJET-INFO5_1819_EDCampus&diff=45314 2019-03-18T11:41:30Z

<p>Zoran.Chanet: /* Semaine 7 */</p> <hr /> <div>[[File:Logo_EDCampus.png|thumb|right| Logo EDCampus]]<br /> = Le projet en quelques mots =<br /> La plateforme [[Contributions open-source au projet Eclipse EdCampus | EDCampus]] est une plateforme de gestion de projet développée par Disrupt Campus Grenoble. La plateforme est actuellement en train d’être soumise à la fondation Eclipse afin d’être mise en open source sous licence Eclipse. Dans le cadre du projet Disrupt Campus, les étudiants sont invités à contribuer à la plateforme. Dans le cadre de vos formations c’est une vraie plus valu de contribuer à de réels projets plutôt qu’à des projets one-shot qui seront mis à la poubelle sitôt votre soutenance terminée. EDCampus est donc une opportunité de contribuer au logiciel libre et à la fondation Eclipse (et de s'assurer une jolie ligne sur son CV plutôt qu'un projet qui sera aussi vite oublié que l'ECOM !).<br /> <br /> = L'équipe et leurs rôles =<br /> <br /> * GEOURJON Anthony - Chef de projet (EXT)<br /> * [[User:Servan.Charlot | CHARLOT Servan]] - Chef de groupe<br /> * [[User:Zoran.Chanet | CHANET Zoran]] - Responsable DevOps<br /> <br /> = Roadmap =<br /> * '''20-22 février 2019 :''' Hack Ton Campus, la plateforme EDCampus sera utilisée pour la gestion des défis.<br /> * '''Avril 2019 :''' Projet pilote, un projet mêlant une entreprise, l'UGA et des étudiants servira de test à la plateforme.<br /> * '''Septembre 2019 :''' Mise en production globale.<br /> <br /> = Carnet de bord =<br /> <br /> == Semaine 1 ==<br /> <br /> === 28/01/19 ===<br /> <br /> Assignation du sujet [[Contributions open-source au projet Eclipse EdCampus | EDCampus]].<br /> <br /> === 29/01/19 ===<br /> <br /> * Rencontre avec Anthony au [http://fabmstic.liglab.fr/ Fablab], présentation du sujet, des enjeux, et de la roadmap<br /> * Installation du projet<br /> ** Difficultés dues au DNS des réseaux universitaires (impossible de télécharger le contenu nécessaire depuis les containers)<br /> <br /> === 30/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $scope._getProjectParent()&lt;/code&gt; qui ne marchait pas du tout. Il y avait une faute dans la plupart des variables qui s'appelaient &lt;code&gt;currentParentProject&lt;/code&gt; au lieu de &lt;code&gt;currentProjectParent&lt;/code&gt;.<br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $rootScope._checkProject()&lt;/code&gt; qui oubliait un paramètre dans son appel à &lt;code&gt;$scope._setProject()&lt;/code&gt;.<br /> <br /> ==== Zoran ====<br /> * Assignation d'une première tâche : réparer la création d'un projet indépendant<br /> * Découverte du code du projet<br /> * Poursuite de l'arborescence des appels depuis le bouton jusqu'à l'appel à la base de données<br /> <br /> === 01/02/19 ===<br /> ==== Servan ====<br /> <br /> * Assignation de la tâche consistant à réparer le système de fichier.<br /> * Exploration du système de fichier et son implémentation.<br /> <br /> ==== Zoran ====<br /> * Production d'une méthode permettant des logs personnalisés<br /> * Recherches sur le rewriting d'URL<br /> * Correction du problème (lié au rewriting)<br /> * Production d'une fiche explicative de la solution<br /> <br /> == Semaine 2 ==<br /> <br /> === 04/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction des bugs suivants :<br /> <br /> * Affichage des fichiers du portefeuille père ssi il y a au moins un fichier présent dans le projet fils.<br /> ** Dans le backend, la fonction qui get les fichiers exécutait un &lt;code&gt;return false&lt;/code&gt; avant de get les fichiers parents dans le cas ou il n'y avait pas de fichier à la base.<br /> * N'actualise pas la liste des fichiers si on supprime le dernier fichier.<br /> * Tous les dossiers sont affichés comme des fichiers. Lors de la première sélection à la souris, si on sélectionne le fichier-dossier, il se transforme en dossier et on peut y accéder. Rien ne se passe pour les sélections suivantes.<br /> ** Dans le backend, un paramètre était traité comme chaîne de caractère alors qu'il représentait un booléen. Le résultat de ça est que l'on entrait dans la mauvaise partie d'un if, qui exécutait la mauvaise requête SQL nous privant de l'information concernant le type de fichier lu (un dossier est un type de fichier).<br /> * Le bouton qui permet de revenir en arrière, sortir du dossier ne fonctionne pas.<br /> * On ne peut pas entrer dans un dossier hérité.<br /> <br /> ==== Zoran ====<br /> * Assignation de la mise en place de techniques DevOps<br /> * Recherches sur la mise en place de pipeline dans GitLab : voir [[GitLab CI/CD | compte-rendu]]<br /> * Mise en place d'un pipeline à chaque push<br /> * Production d'un tutoriel de création de runner GitLab : voir [[GitLab Runners | tutoriel]]<br /> * Recherches sur SonarQube et les tests unitaires<br /> ** Priorisation de SonarQube<br /> <br /> === 05/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug qui faisait que lors de la suppression d'un dossier, les fichiers à l'intérieur ne sont pas supprimés (le champ statut dans le BDD ne passe pas à 0).<br /> ** La fonctionnalité de suppression récursive n'était pas implémentée dans &lt;code&gt;File.php&lt;/code&gt;.<br /> * Début de l'analyse du système de droit des utilisateurs (Administrateur/Tuteur/Élève) sur les fichiers et dossiers (hérités ou non).<br /> <br /> ==== Zoran ====<br /> * Compréhension des scanners sonar : voir [[SonarQube Scanner | compte-rendu]]<br /> * Mise en place d'un scan dans le pipeline<br /> ** Nécessité d'un serveur sonar exposé<br /> ** Décision d'utiliser SonarCloud<br /> ** Configuration du scanner pour envoyer le rapport dans le bon projet sonarcloud<br /> ** Réussite du premier scan<br /> <br /> === 06/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Suite de la correction du système de droits des fichiers/dossiers.<br /> <br /> * Correction d'un bug qui faisait que les utilisateurs ne peuvent pas entrer dans les dossiers hérites (ou télécharger les fichiers hérites).<br /> ** Le check de droit se fait dans une fonction qui check d'abord le &lt;code&gt;ownerId&lt;/code&gt;, puis le &lt;code&gt;projectId&lt;/code&gt; et puis enfin si le fichier appartient à un parent. Pour cela elle fait appel à la base pour récupérer la relation d’héritage. IL y avait une erreur de comparaison entre le résultat de la requête et les information fichier (erreur de type parce que PHP).<br /> * Analyse complète du système de droit création d'un tableau explicatif de l'état actuel et l'état voulu.<br /> [[File:EDCampus_2019_Tableau_de_droits.png|center]]<br /> * Suite au tableau, mise en place de la protection des fichiers hérités.<br /> ** Ajout d'une vérification sur le &lt;code&gt;projectId&lt;/code&gt;, empêchant les utilisateurs non propriétaires du fichier de le supprimer, renommer ou déplacer.<br /> <br /> ==== Zoran ====<br /> * Extension du scan sonar dans le pipeline à toutes les sections du projet<br /> * Affichage de badges d'état du pipeline sur la page de présentation de chaque section du projet<br /> * Reprise des recherches concernant les tests unitaires<br /> * Tentative de systématisation des tests dans le pipeline<br /> ** Difficulté : les tests nécessitent des fichiers de configurations qui ne sont pas présents sur le repository git<br /> * Recherche de contournement pour ne pas exposer des configurations privées dans le projet public<br /> <br /> === 08/02/19 ===<br /> <br /> ==== Servan ====<br /> Suppression de la vue pour les non membres et correction partielle du système de droits.<br /> * Lorsque qu'une commande est envoyée par le front-end vers le back-end, elle passe dans une fonction qui vérifie les droits (&lt;code&gt;Right.php checkRights($command)&lt;/code&gt;). La fonction compare la commande utilisée par l'utilisateur aux commandes que cet utilisateur a en général le droit d'utiliser. Le problème était que le tableau de commandes au sein de la fonction (permettant la comparaison) contenait des commandes mal formatées. J'ai donc corrigé celle qui m'intéressais pour empêcher les non membres d'un projet à consulter les fichiers, et j'en ai profiter pour corriger toutes les autres.<br /> <br /> ==== Zoran ====<br /> * Configuration des scanners sonar dans le pipeline (redirection vers une branche du projet sonarcloud nommée selon la branche GitLab sur laquelle le pipeline est lancé)<br /> * Aide à la correction du système de droits<br /> * Réalisation de tâches mineures importantes pour le Hackaton<br /> ** Retirer la vidéo Waza de l'accueil de la plateforme<br /> ** Redirection de l'utilisateur vers la plateforme lorsqu'il accède à l'url du dossier : [[Apache mod_rewrite]]<br /> ** Correction de l'url donné lors de l'appel au service de mails pour la validation de compte<br /> <br /> == Semaine 3 ==<br /> <br /> === 12/02/19 ===<br /> <br /> ==== Servan ====<br /> * Système de droits entièrement corrigé pour le cas des fichiers.<br /> ** Privilèges administrateurs.<br /> *** Dans la fonction qui vérifie les droits &lt;code&gt;Right.php checkRights($command)&lt;/code&gt;, le cas de l'administrateur n'était pas vraiment traité. Il y avait un versification pour empêcher tout utilisateur non administrateur d’exécuter une commande administrateur, mais sinon l'administrateur était traité comme un utilisateur lambda. J'ai donc ajouté un test permettant de donner les pleins pouvoirs. Presque. Il fallait aussi ajouter un test dans la fonction &lt;code&gt;File.php _checkFileAccess(...)&lt;/code&gt; qui pour certaines actions sur les fichiers, agit comme une surcouche à la fonction &lt;code&gt;checkRights&lt;/code&gt; (ce qui permet entre autres des actions sur les fichiers hérités pour le tuteur et les membres).<br /> ** Cas du déplacement de fichier hérités.<br /> *** Avec l'accord d'Anthony, on a conclu que le déplacement de fichier hérité était une mauvaise idée, donc cela reste non autorisé, même pour les admins.<br /> * Correction du fait que les fichiers ayant un numéro pour nom ne peuvent pas être supprimés.<br /> ** Les appels à la base effectuait une comparaison avec un &lt;code&gt;LIKE&lt;/code&gt; au lieu d'un &lt;code&gt;=&lt;/code&gt; dans la requête SQL, ce qui ne marchait pas dans le cas présent.<br /> * Correction du fait que les fichiers ayant un numéro pour nom ne peuvent pas être renommés.<br /> ** Le nom du fichier est traité et enregistré par le fichier JS, qui est non typé donc il décide que si le nom n'est que des numéros, alors ce ne sera pas une string. Or pour renommer le fichier, on veux modifier la partie du nom qui est avant le point (de l'extension), donc on fait un appel à &lt;code&gt;name.lastIndexOf(&quot;.&quot;);&lt;/code&gt;, qui s’exécute exclusivement sur une string. J'ai donc réalise un &lt;code&gt;.toString()&lt;/code&gt; sur le nom à chaque fois que nécessaire.<br /> * Correction du fait que lorsque l'on supprimait un fichier dans un dossier, on était renvoyé à la racine du projet plutôt que dans le dossier.<br /> ** Il manquait un paramètre (le dossier) à la fonction &lt;code&gt;getFiles(...)&lt;/code&gt; appelée après la suppression.<br /> * Transformation du bouton &quot;Ajouter&quot; en deux boutons, un pour les dossiers, un pour les fichiers.<br /> <br /> ==== Zoran ====<br /> * Mise à Jour de templates de mail (&gt;100 templates)<br /> ** Remplacement des références à Waza Education par EDCampus<br /> ** Production d'une banière et remplacement de l'ancienne<br /> * Tests des fichiers de configuration des tests unitaires<br /> * Recherches sur le passage de l'HTTP vers HTTPS avec [https://letsencrypt.org/ Let's Encrypt] : voir le [[Let's Encrypt | résumé rapide]]<br /> ** Choix d'utilisation de [https://certbot.eff.org/ Certbot]<br /> <br /> === 13/02/19 ===<br /> <br /> ==== Servan ====<br /> Nouvelle tâche assignée : Améliorer les tâches, faire en sorte que si un nom est placé sur un label d'une couleur au sein d'un projet, tous les labels de cette couleur auront ce même nom.<br /> <br /> ==== Zoran ====<br /> * Sauvegarde de la base de données de l'ancienne plateforme<br /> * Passage de l'ancienne plateforme de l'HTTP à l'HTTPS<br /> ** Réparation de la configuration d'Apache<br /> ** Génération des certificats<br /> ** Configuration d'Apache pour l'HTTPS<br /> <br /> === 14/02/19 ===<br /> <br /> ==== Servan ====<br /> * Backend corrigé, on ne peux plus créer une tache d'un nom au choix si il y a déjà une tache de cette couleur avec un nom dans le projet.<br /> * Etude approfondie du front-end et du système événementiel pour corriger les défauts de mise à jour.<br /> <br /> ==== Zoran ====<br /> * Recherches sur l'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Découverte et compréhension d'une [https://github.com/BirgerK/docker-apache-letsencrypt image existante]<br /> * Tentative de passage de l'HTTP à l'HTTPS dans un Docker<br /> ** Sur la VM de l'ancienne plateforme (pour ne pas briser la version en prod)<br /> ** Fusion du Dockerfile existant et du Dockerfile de l'image trouvée<br /> <br /> === 15/02/19 ===<br /> <br /> ==== Servan ====<br /> * Correction superficielle des problèmes des mise a jour a de la vue du système de tache. Le soucis étant que les taches et le petit menu qui indique les détails ne sont pas le même module et n'interagissent pas vraiment entre eux, donc on ne peux pas actualiser l'un depuis l'autre.<br /> * Correction du fait que dans le système de fichier, on ne pouvait pas délacer un fichier/dossier vers le dossier parent en le glissant sur la flèche retour. <br /> ** Le soucis venait du fichier html, qui avait l'air correct mais la variable qu'il était censé récupérer renvoyait undefined au lieu de l'identifiant du dossier parent.<br /> <br /> ==== Zoran ====<br /> * Poursuite de la tentative d'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Succès de la création de certificat<br /> ** L'HTTPS ne fonctionne toujours pas (sans doute à cause de la configuration d'Apache)<br /> <br /> == Semaine 4 ==<br /> <br /> Hack ton campus.<br /> <br /> == Semaine 5 ==<br /> <br /> Vacances d'hiver.<br /> <br /> == Semaine 6 ==<br /> <br /> === 05/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug trouvé lors que hackaton qui empêchait les étudiants de télécharger un fichier hérité appartenant à un tuteur. <br /> * Début d'un travail sur les tests unitaires du backend. Le but est de vérifier les tests existants, essayer de les faire fonctionner, et s'en inspirer pour en créer d'autres et à terme, couvrir tout le code.<br /> <br /> ==== Zoran ====<br /> * Succès de la mise en place d'HTTPS dans un docker<br /> ** Modification de &lt;code&gt;docker-compose.yml&lt;/code&gt; pour lier les ports 443 de l'hôte et du conteneur<br /> ** Finalisation de la configuration d'Apache dans le conteneur<br /> <br /> === 06/03/19 ===<br /> <br /> ==== Servan et Zoran ====<br /> <br /> * Lecture de la [https://phpunit.readthedocs.io/en/8.0/ documentation de PHPUNit.]<br /> Après un travail de recherche, nous nous sommes rendu compte que PHPUnit allait être difficile à mettre en place sur le backend du projet. En effet, toutes les fonctions sont en ''static'' et il est impossible de mocker les fonctions statiques avec PHPUnit. Il faudrait donc revoir l'architecture du code pour mocker le statique, et donc remplacer les appels à la base de données par des appels simulés. Cela éviterait d'avoir à créer une base externe accessible ou construire une base dans le runner du pipeline. Cependant cela est trop long a mettre en place sachant que l'on arrive sur la fin du projet, donc nous avons donné priorité à la vitrine, suite à une réunion avec les membres de Disrupt campus. <br /> <br /> La vitrine est un endroit où le public (étudiants/professeurs/entreprises) peut consulter les projets réalisés ou en cours. Cette vitrine se décompose en un endroit ou l'on peut consulter la liste des projets d'une université, et des pages de projet individuelles avec une image, une description et les livrables.<br /> <br /> === 07/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction d'un bug en rapport avec les accents dans les noms. Lorsque qu'un utilisateur possède un accent dans son nom (ex: Amélie), au moment de la création du login la chaîne de caractère est mal interprétée et le login est tronqué au niveau de l'accent (ex: amY). L'architecture fait que lors du transfert du nom du front vers le back, l'accent est codé avec des caractères classiques, qui sont ensuite interprétés correctement lors de l'ajout en base. Mais cela veux dire que pendant tout le passage en backend on travaille avec des accents codés. Le login était créé à partir du nom et du prénom de l'utilisateur, qui peuvent donc être temporairement corrompus par des accents codés. La correction à se soucis est donc détecter la présence d'accents dans les noms, et si il y en a, créer le login à partir de la première partie de l'adresse mail de l'utilisateur (avant le @), sinon, on fait comme avant avec les noms.<br /> <br /> ==== Zoran ====<br /> * Correction d'un bug empêchant l'envoi d'e-mail lors de l'ajout d'un utilisateur à un projet<br /> * Prospection dans le code et la base de donnée pour permettre l'affichage ou non des évaluations dans le menu des projets. La section des évaluations étant gérée différemment des autres sections, ce travail nécessitera plus de temps que prévu et a donc été reporté au profit de la vitrine<br /> <br /> === 08/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Archéologie sur le prototype de vitrine.<br /> * Rédaction de documentation générale sur l'architecture End-To-End du projet (ci-dessous).<br /> <br /> [[File:EDCampus 2019 EndToEnd.png|border]]<br /> <br /> Détails de la fonction &lt;code&gt;checkRights&lt;/code&gt; :<br /> <br /> * La commande en cours est envoyée à &lt;code&gt;checkRights&lt;/code&gt; sous forme de string.<br /> * On vérifie d'abord si elle fait partie des commandes publiques, que l'on peux exécuter lorsque l'on a pas de session. (Via une comparaison avec un tableau contenant toutes les commandes publiques.)<br /> * Si ce n'est pas la cas, on récupère ensuite les informations de session et l'identifiant utilisateur.<br /> * Si on ne trouve pas d'utilisateur, on regarde si on essai d’accéder a une page publique, sinon on bloque l'accès.<br /> * On a maintenant un utilisateur avec une session, qui essaie d'agir sur une page non publique.<br /> * On vérifie si l'utilisateur est super-administrateur.<br /> * On vérifie si l'utilisateur essai d’exécuter une commande administrateur, en tant qu'administrateur.<br /> * Puisque la page est non-publique et que l'on est pas administrateur, il s'agit forcement d'une page de projet. <br /> * On vérifie si l'utilisateur est propriétaire du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est propriétaire du projet courant et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet courant et que cette commande est autorisée.<br /> * Si aucun des tests ci dessus n'a raté (ou n'a déjà accordé l'accès), on accorde l'accès.<br /> <br /> ==== Zoran ====<br /> * Archéologie sur le prototype de vitrine<br /> * Réparation des appels au serveur opérés par le prototype de vitrine existant<br /> ** La vitrine étant écrite en php et non en utilisant AngularJS comme le reste du front-end, la gestion des appels est différente<br /> ** Correction du lien par lequel le serveur est appelé<br /> ** Correction des arguments et de la commande donnés lors de l'appel au serveur<br /> * Correction du nombre de projets affichés avant extension<br /> * Prospection pour l'utilisation future de la vitrine<br /> <br /> == Semaine 7 - Vitrine ==<br /> <br /> === 11/03/19 ===<br /> <br /> * Correction d'un bug d'affichage. L'administrateur peut choisir dans son profil quel est son campus principal, et cela est utile entre autres dans la partie communication de son dashboard. C'est à cet endroit qu'il peut choisir de rendre publique la page de son université (ie. la vitrine). A cet endroit, la vitrine est renseignée par un lien (&lt;code&gt;http://localhost/app/campus/?u=UGA&lt;/code&gt;), contenant le nom du campus au bout (UGA). Le bug faisait que ce nom n'était pas affiché et donc l'URL était incomplet. Le soucis venait du backend, ou la requête du campus à la base ne demandait pas le champ nom.<br /> * Correction des projets affichés en vitrine<br /> ** Affichage des projets fils et indépendants seulement (pas les portefeuilles)<br /> ** Explicitation du nom des projets fils (Si ''Equipe A'' appartient au portefeuille ''Défi 3'', son nom affiché sera ''Défi 3 &gt; Equipe A''<br /> * Ajout d'un texte de remplacement lorsqu'une section est vide (plus élégant qu'un grand espace vide)<br /> <br /> === 12/03/19 ===<br /> * Création d'une page vitrine de projet<br /> ** Ecriture de cette page comme un composant AngularJS, pour coller à la nouvelle méthode<br /> ** Création des sections principales (titre, description, membres)<br /> * Harmonisation du visuel<br /> ** Beaucoup de CSS<br /> <br /> === 13/03/19 ===<br /> * Ajout de nouvelles sections<br /> ** Modification des requêtes et des droits pour rendre public les informations souhaitées<br /> ** Sections dates, thèmes, mots-clés, organisations<br /> * Réunion/démonstration avec Gérard<br /> <br /> === 14/03/19 ===<br /> * Création de la section livrables<br /> ** Nombreux ajustements sur les requêtes<br /> * Implémentation des url externes comme livrable<br /> ** Section url externe à la remise des livrables<br /> ** Gestion des url en base<br /> <br /> === 15/03/19 ===<br /> * Gestion des droits de téléchargement des livrables depuis la vitrine<br /> * Gestion des url externes de vidéo comme vidéo embarquées<br /> ** Youtube<br /> * Réunion/démonstration avec l'équipe Disrupt campus<br /> * Gestion des url externes de vidéo comme vidéo embarquées<br /> ** Vimeo<br /> ** Dailymotion<br /> * Gestion du renommage des url<br /> ** Ajout d'un champ de renommage à la remise des livrables<br /> ** Prise en compte de ce nom dans l'affichage de la vitrine</div>

Zoran.Chanet https://air.imag.fr/index.php?title=PROJET-INFO5_1819_EDCampus&diff=45253 2019-03-11T13:18:30Z

<p>Zoran.Chanet: /* Le projet en quelques mots */</p> <hr /> <div>[[File:Logo_EDCampus.png|thumb|right| Logo EDCampus]]<br /> = Le projet en quelques mots =<br /> La plateforme [[Contributions open-source au projet Eclipse EdCampus | EDCampus]] est une plateforme de gestion de projet développée par Disrupt Campus Grenoble. La plateforme est actuellement en train d’être soumise à la fondation Eclipse afin d’être mise en open source sous licence Eclipse. Dans le cadre du projet Disrupt Campus, les étudiants sont invités à contribuer à la plateforme. Dans le cadre de vos formations c’est une vraie plus value de contribuer à de réels projets plutôt qu’à des projets one-shot qui seront mis à la poubelle sitôt votre soutenance terminée. EDCampus est donc une opportunité de contribuer au logiciel libre et à la fondation Eclipse (et de s'assurer une jolie ligne sur son CV plutôt qu'un projet qui sera aussi vite oublié que l'ECOM !).<br /> <br /> = L'équipe et leurs rôles =<br /> <br /> * GEOURJON Anthony - Chef de projet (EXT)<br /> * [[User:Servan.Charlot | CHARLOT Servan]] - Chef de groupe<br /> * [[User:Zoran.Chanet | CHANET Zoran]] - Responsable DevOps<br /> <br /> = Roadmap =<br /> * '''20-22 février 2019 :''' Hack Ton Campus, la plateforme EDCampus sera utilisée pour la gestion des défis.<br /> * '''Avril 2019 :''' Projet pilote, un projet mêlant une entreprise, l'UGA et des étudiants servira de test à la plateforme.<br /> * '''Septembre 2019 :''' Mise en production globale.<br /> <br /> = Carnet de bord =<br /> <br /> == Semaine 1 ==<br /> <br /> === 28/01/19 ===<br /> <br /> Assignation du sujet [[Contributions open-source au projet Eclipse EdCampus | EDCampus]].<br /> <br /> === 29/01/19 ===<br /> <br /> * Rencontre avec Anthony au [http://fabmstic.liglab.fr/ Fablab], presentation du sujet, des enjeux, et de la roadmap<br /> * Installation du projet<br /> ** Difficultés dues au DNS des réseaux universitaires (impossible de télécharger le contenu nécessaire depuis les containers)<br /> <br /> === 30/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $scope._getProjectParent()&lt;/code&gt; qui ne marchait pas du tout. Il y avait une faute dans la plupart des variables qui s'appelaient &lt;code&gt;currentParentProject&lt;/code&gt; au lieu de &lt;code&gt;currentProjectParent&lt;/code&gt;.<br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $rootScope._checkProject()&lt;/code&gt; qui oubliait un paramètre dans son appel à &lt;code&gt;$scope._setProject()&lt;/code&gt;.<br /> <br /> ==== Zoran ====<br /> * Assignation d'une première tâche : réparer la création d'un projet indépendant<br /> * Découverte du code du projet<br /> * Poursuite de l'arborescence des appels depuis le bouton jusqu'à l'appel à la base de données<br /> <br /> === 01/02/19 ===<br /> ==== Servan ====<br /> <br /> * Assignation de la tâche consistant à réparer le système de fichier.<br /> * Exploration du systeme de fichier et son implementation.<br /> <br /> ==== Zoran ====<br /> * Production d'une méthode permettant des logs personnalisés<br /> * Recherches sur le rewriting d'URL<br /> * Correction du problème (lié au rewriting)<br /> * Production d'une fiche explicative de la solution<br /> <br /> == Semaine 2 ==<br /> <br /> === 04/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction des bugs suivants :<br /> <br /> * Affichage des fichiers du portefeuille père ssi il y a au moins un fichier présent dans le projet fils.<br /> ** Dans le backend, la fonction qui get les fichiers exécutait un &lt;code&gt;return false&lt;/code&gt; avant de get les fichiers parents dans le cas ou il n'y avait pas de fichier à la base.<br /> * N'actualise pas la liste des fichiers si on supprime le dernier fichier.<br /> * Tous les dossiers sont affichés comme des fichiers. Lors de la première sélection à la souris, si on sélectionne le fichier-dossier, il se transforme en dossier et on peut y accéder. Rien ne se passe pour les sélections suivantes.<br /> ** Dans le backend, un paramètre était traité comme chaîne de caractère alors qu'il représentait un booléen. Le résultat de ça est que l'on entrait dans la mauvaise partie d'un if, qui exécutait la mauvaise requête SQL nous privant de l'information concernant le type de fichier lu (un dossier est un type de fichier).<br /> * Le bouton qui permet de revenir en arrière, sortir du dossier ne fonctionne pas.<br /> * On ne peut pas entrer dans un dossier hérité.<br /> <br /> ==== Zoran ====<br /> * Assignation de la mise en place de techniques DevOps<br /> * Recherches sur la mise en place de pipeline dans GitLab : voir [[GitLab CI/CD | compte-rendu]]<br /> * Mise en place d'un pipeline à chaque push<br /> * Production d'un tutoriel de création de runner GitLab : voir [[GitLab Runners | tutoriel]]<br /> * Recherches sur SonarQube et les tests unitaires<br /> ** Priorisation de SonarQube<br /> <br /> === 05/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug qui faisait que lors de la suppression d'un dossier, les fichiers à l'intérieur ne sont pas supprimés (le champ statut dans le BDD ne passe pas à 0).<br /> ** La fonctionnalité de suppression récursive n'était pas implémentée dans &lt;code&gt;File.php&lt;/code&gt;.<br /> * Début de l'analyse du système de droit des utilisateurs (Administrateur/Tuteur/Elève) sur les fichiers et dossiers (hérités ou non).<br /> <br /> ==== Zoran ====<br /> * Compréhension des scanners sonar : voir [[SonarQube Scanner | compte-rendu]]<br /> * Mise en place d'un scan dans le pipeline<br /> ** Nécessité d'un serveur sonar exposé<br /> ** Décision d'utiliser SonarCloud<br /> ** Configuration du scanner pour envoyer le rapport dans le bon projet sonarcloud<br /> ** Réussite du premier scan<br /> <br /> === 06/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Suite de la correction du système de droits des fichiers/dossiers.<br /> <br /> * Correction d'un bug qui faisait que les utilisateurs ne peuvent pas entrer dans les dossiers hérites (ou télécharger les fichiers hérites).<br /> ** Le check de droit se fait dans une fonction qui check d'abord le &lt;code&gt;ownerId&lt;/code&gt;, puis le &lt;code&gt;projectId&lt;/code&gt; et puis enfin si le fichier appartient à un parent. Pour cela elle fait appel à la base pour récupérer la relation d’héritage. IL y avait une erreur de comparaison entre le résultat de la requête et les information fichier (erreur de type parce que PHP).<br /> * Analyse complète du système de droit création d'un tableau explicatif de l'état actuel et l'état voulu.<br /> [[File:EDCampus_2019_Tableau_de_droits.png|center]]<br /> * Suite au tableau, mise en place de la protection des fichiers hérités.<br /> ** Ajout d'une vérification sur le &lt;code&gt;projectId&lt;/code&gt;, empêchant les utilisateurs non propriétaires du fichier de le supprimer, renommer ou déplacer.<br /> <br /> ==== Zoran ====<br /> * Extension du scan sonar dans le pipeline à toutes les sections du projet<br /> * Affichage de badges d'état du pipeline sur la page de présentation de chaque section du projet<br /> * Reprise des recherches concernant les tests unitaires<br /> * Tentative de systématisation des tests dans le pipeline<br /> ** Difficulté : les tests nécessitent des fichiers de configurations qui ne sont pas présents sur le repository git<br /> * Recherche de contournement pour ne pas exposer des configurations privées dans le projet public<br /> <br /> === 08/02/19 ===<br /> <br /> ==== Servan ====<br /> Suppression de la vue pour les non membres et correction partielle du système de droits.<br /> * Lorsque qu'une commande est envoyée par le front-end vers le back-end, elle passe dans une fonction qui vérifie les droits (&lt;code&gt;Right.php checkRights($command)&lt;/code&gt;). La fonction compare la commande utilisée par l'utilisateur aux commandes que cet utilisateur a en général le droit d'utiliser. Le problème était que le tableau de commandes au sein de la fonction (permettant la comparaison) contenait des commandes mal formatées. J'ai donc corrigé celle qui m'intéressais pour empêcher les non membres d'un projet à consulter les fichiers, et j'en ai profiter pour corriger toutes les autres.<br /> <br /> ==== Zoran ====<br /> * Configuration des scanners sonar dans le pipeline (redirection vers une branche du projet sonarcloud nommée selon la branche GitLab sur laquelle le pipeline est lancé)<br /> * Aide à la correction du système de droits<br /> * Réalisation de tâches mineures importantes pour le Hackaton<br /> ** Retirer la vidéo Waza de l'accueil de la plateforme<br /> ** Redirection de l'utilisateur vers la plateforme lorsqu'il accède à l'url du dossier : [[Apache mod_rewrite]]<br /> ** Correction de l'url donné lors de l'appel au service de mails pour la validation de compte<br /> <br /> == Semaine 3 ==<br /> <br /> === 12/02/19 ===<br /> <br /> ==== Servan ====<br /> * Systeme de droits entierement corrigé pour le cas des fichiers.<br /> ** Privilèges administrateurs.<br /> *** Dans la fonction qui verifie les droits &lt;code&gt;Right.php checkRights($command)&lt;/code&gt;, le cas de l'administrateur n'était pas vraiment traité. Il y avait un verification pour empecher tout utilisateur non administrateur d'executer une commande administrateur, mais sinon l'administrateur était traité comme un utilisateur lambda. J'ai donc ajouté un test permettant de donner les pleins pouvoirs. Presque. Il fallait aussi ajouter un test dans la fonction &lt;code&gt;File.php _checkFileAccess(...)&lt;/code&gt; qui pour certaines actions sur les fichiers, agit comme une surcouche à la fonction &lt;code&gt;checkRights&lt;/code&gt; (ce qui permet entre autres des actions sur les fichiers hérités pour le tuteur et les membres).<br /> ** Cas du déplacement de fichier hérités.<br /> *** Avec l'accord d'Anthony, on a conclu que le déplacement de fichier hérité était une mauvaise idée, donc cela reste non autorisé, même pour les admins.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être supprimés.<br /> ** Les appels à la base effectuait une comparaison avec un &lt;code&gt;LIKE&lt;/code&gt; au lieu d'un &lt;code&gt;=&lt;/code&gt; dans la requête SQL, ce qui ne marchait pas dans le cas présent.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être renommés.<br /> ** Le nom du fichier est traité et enregistré par le fichier JS, qui est non typé donc il decide que si le nom n'est que des numeros, alors ce ne sera pas une string. Or pour renommer le fichier, on veux modifer la partie du nom qui est avant le point (de l'extension), donc on fait un appel à &lt;code&gt;name.lastIndexOf(&quot;.&quot;);&lt;/code&gt;, qui s'execute eclusivement sur une string. J'ai donc realisé un &lt;code&gt;.toString()&lt;/code&gt; sur le nom à chaque fois que necessaire.<br /> * Correction du fait que lorsque l'on supprimait un fichier dans un dossier, on était renvoyé à la racine du projet plutot que dans le dossier.<br /> ** Il manquait un paramètre (le dossier) à la fonction &lt;code&gt;getFiles(...)&lt;/code&gt; appalée après la suppréssion.<br /> * Transformation du bouton &quot;Ajouter&quot; en deux boutons, un pour les dossiers, un pour les fichiers.<br /> <br /> ==== Zoran ====<br /> * Mise à Jour de templates de mail (&gt;100 templates)<br /> ** Remplacement des références à Waza Education par EDCampus<br /> ** Production d'une banière et remplacement de l'ancienne<br /> * Tests des fichiers de configuration des tests unitaires<br /> * Recherches sur le passage de l'HTTP vers HTTPS avec [https://letsencrypt.org/ Let's Encrypt] : voir le [[Let's Encrypt | résumé rapide]]<br /> ** Choix d'utilisation de [https://certbot.eff.org/ Certbot]<br /> <br /> === 13/02/19 ===<br /> <br /> ==== Servan ====<br /> Nouvelle tâche assignée : Améliorer les tâches, faire en sorte que si un nom est placé sur un label d'une couleur au sein d'un projet, tous les labels de cette couleur auront ce même nom.<br /> <br /> ==== Zoran ====<br /> * Sauvegarde de la base de données de l'ancienne plateforme<br /> * Passage de l'ancienne plateforme de l'HTTP à l'HTTPS<br /> ** Réparation de la configuration d'Apache<br /> ** Génération des certificats<br /> ** Configuration d'Apache pour l'HTTPS<br /> <br /> === 14/02/19 ===<br /> <br /> ==== Servan ====<br /> * Backend corrigé, on ne peux plus créer une tache d'un nom au choix si il y a deja une tache de cette couleur avec un nom dans le projet.<br /> * Etude approfondie du front-end et du systeme evenementiel pour corriger les defauts de mise à jour.<br /> <br /> ==== Zoran ====<br /> * Recherches sur l'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Découverte et compréhension d'une [https://github.com/BirgerK/docker-apache-letsencrypt image existante]<br /> * Tentative de passage de l'HTTP à l'HTTPS dans un Docker<br /> ** Sur la VM de l'ancienne plateforme (pour ne pas briser la version en prod)<br /> ** Fusion du Dockerfile existant et du Dockerfile de l'image trouvée<br /> <br /> === 15/02/19 ===<br /> <br /> ==== Servan ====<br /> * Correction superficielle des problemes des mise a jour a de la vue du systeme de tache. Le soucis etant que les taches et le petit menu qui indique les details ne sont pas le même module et n'interagissent pas vraiment entre eux, donc on ne peux pas actualier l'un depuis l'autre.<br /> * Correction du fait que dans le systeme de fichier, on ne pouvait pas délacer un fichier/dossier vers le dossier parent en le glissant sur la flèche retour. <br /> ** Le soucis venait du fichier html, qui avait l'air correct mais la variable qu'il etait censé recuppérer renvoyait undefined au lieu de l'identifiant du dossier parent.<br /> <br /> ==== Zoran ====<br /> * Poursuite de la tentative d'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Succès de la création de certificat<br /> ** L'HTTPS ne fonctionne toujours pas (sans doute à cause de la configuration d'Apache)<br /> <br /> == Semaine 4 ==<br /> <br /> Hack ton campus.<br /> <br /> == Semaine 5 ==<br /> <br /> === 05/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug trouvé lors que hackaton qui empêchait les étudiants de télécharger un fichier hérité appartenant à un tuteur. <br /> * Début d'un travail sur les tests unitaires du backend. Le but est de vérifier les tests existants, essayer de les faire fonctionner, et s'en inspirer pour en créer d'autres et à terme, couvrir tout le code.<br /> <br /> ==== Zoran ====<br /> * Succès de la mise en place d'HTTPS dans un docker<br /> ** Modification de &lt;code&gt;docker-compose.yml&lt;/code&gt; pour lier les ports 443 de l'hôte et du conteneur<br /> ** Finalisation de la configuration d'Apache dans le conteneur<br /> <br /> === 06/03/19 ===<br /> <br /> ==== Servan et Zoran ====<br /> <br /> * Lecture de la [https://phpunit.readthedocs.io/en/8.0/ documentation de PHPUNit.]<br /> Après un travail de recherche, nous nous sommes rendu compte que PHPUnit allait être difficile à mettre en place sur le backend du projet. En effet, toutes les fonctions sont en ''static'' et il est impossible de mocker les fonctions statiques avec PHPUnit. Il faudrait donc revoir l'architecture du code pour mocker le statique, et donc remplacer les appels à la base de données par des appels simulés. Cela éviterait d'avoir à créer une base externe accessible ou construire une base dans le runner du pipeline. Cependant cela est trop long a mettre en place sachant que l'on arrive sur la fin du projet, donc nous avons donné priorité à la vitrine, suite à une réunion avec les membres de Disrupt campus. <br /> <br /> La vitrine est un endroit où le public (étudiants/professeurs/entreprises) peut consulter les projets réalisés ou en cours. Cette vitrine se décompose en un endroit ou l'on peut consulter la liste des projets d'une université, et des pages de projet individuelles avec une image, une description et les livrables.<br /> <br /> === 07/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction d'un bug en rapport avec les accents dans les noms. Lorsque qu'un utilisateur possède un accent dans son nom (ex: Amélie), au moment de la création du login la chaîne de caractère est mal interprétée et le login est tronqué au niveau de l'accent (ex: amY). L'architecture fait que lors du transfert du nom du front vers le back, l'accent est codé avec des caractères classiques, qui sont ensuite interprétés correctement lors de l'ajout en base. Mais cela veux dire que pendant tout le passage en backend on travaille avec des accents codés. Le login était créé à partir du nom et du prénom de l'utilisateur, qui peuvent donc être temporairement corrompus par des accents codés. La correction à se soucis est donc détecter la présence d'accents dans les noms, et si il y en a, créer le login à partir de la première partie de l'adresse mail de l'utilisateur (avant le @), sinon, on fait comme avant avec les noms.<br /> <br /> ==== Zoran ====<br /> * Correction d'un bug empêchant l'envoi d'e-mail lors de l'ajout d'un utilisateur à un projet<br /> * Prospection dans le code et la base de donnée pour permettre l'affichage ou non des évaluations dans le menu des projets. La section des évaluations étant gérée différemment des autres sections, ce travail nécessitera plus de temps que prévu et a donc été reporté au profit de la vitrine<br /> <br /> === 08/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Archéologie sur le prototype de vitrine.<br /> * Rédaction de documentation générale sur l'architecture End-To-End du projet (ci-dessous).<br /> <br /> [[File:EDCampus 2019 EndToEnd.png|border]]<br /> <br /> Détails de la fonction &lt;code&gt;checkRights&lt;/code&gt; :<br /> <br /> * La commande en cours est envoyée à &lt;code&gt;checkRights&lt;/code&gt; sous forme de string.<br /> * On vérifie d'abord si elle fait partie des commandes publiques, que l'on peux exécuter lorsque l'on a pas de session. (Via une comparaison avec un tableau contenant toutes les commandes publiques.)<br /> * Si ce n'est pas la cas, on récupère ensuite les informations de session et l'identifiant utilisateur.<br /> * Si on ne trouve pas d'utilisateur, on regarde si on essai d’accéder a une page publique, sinon on bloque l'accès.<br /> * On a maintenant un utilisateur avec une session, qui essaie d'agir sur une page non publique.<br /> * On vérifie si l'utilisateur est super-administrateur.<br /> * On vérifie si l'utilisateur essai d’exécuter une commande administrateur, en tant qu'administrateur.<br /> * Puisque la page est non-publique et que l'on est pas administrateur, il s'agit forcement d'une page de projet. <br /> * On vérifie si l'utilisateur est propriétaire du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est propriétaire du projet courant et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet courant et que cette commande est autorisée.<br /> * Si aucun des tests ci dessus n'a raté (ou n'a déjà accordé l'accès), on accorde l'accès.<br /> <br /> ==== Zoran ====<br /> * Archéologie sur le prototype de vitrine<br /> * Réparation des appels au serveur opérés par le prototype de vitrine existant<br /> ** La vitrine étant écrite en php et non en utilisant AngularJS comme le reste du front-end, la gestion des appels est différente<br /> ** Correction du lien par lequel le serveur est appelé<br /> ** Correction des arguments et de la commande donnés lors de l'appel au serveur<br /> * Correction du nombre de projets affichés avant extension<br /> * Prospection pour l'utilisation future de la vitrine<br /> <br /> == Semaine 6 ==<br /> <br /> === 11/03/19 ===<br /> <br /> * Correction d'un bug d'affichage. L'administrateur peut choisir dans son profil quel est son campus principal, et cela est utile entre autres dans la partie communication de son dashboard. C'est à cet endroit qu'il peut choisir de rendre publique la page de son université (ie. la vitrine). A cet endroit, la vitrine est renseignée par un lien (&lt;code&gt;http://localhost/app/campus/?u=UGA&lt;/code&gt;), contenant le nom du campus au bout (UGA). Le bug faisait que ce nom n'était pas affiché et donc l'URL était incomplet. Le soucis venait du backend, ou la requête du campus à la base ne demandait pas le champ nom.<br /> * Correction des projets affichés en vitrine<br /> ** Affichage des projets fils et indépendants seulement (pas les portefeuilles)<br /> ** Explicitation du nom des projets fils (Si ''Equipe A'' appartient au portefeuille ''Défi 3'', son nom affiché sera ''Défi 3 &gt; Equipe A''<br /> * Ajout d'un texte de remplacement lorsqu'une section est vide (plus élégant qu'un grand espace vide)<br /> <br /> === 12/03/19 ===<br /> <br /> <br /> === 13/03/19 ===<br /> <br /> <br /> === 14/03/19 ===<br /> <br /> <br /> === 15/03/19 ===</div>

Zoran.Chanet https://air.imag.fr/index.php?title=PROJET-INFO5_1819_EDCampus&diff=45252 2019-03-11T12:28:21Z

<p>Zoran.Chanet: /* 11/03/19 */</p> <hr /> <div>[[File:Logo_EDCampus.png|thumb|right| Logo EDCampus]]<br /> = Le projet en quelques mots =<br /> La plateforme [[Contributions open-source au projet Eclipse EdCampus | EDCampus]] est une plateforme de gestion de projet développé par Disrupt Campus Grenoble. La plateforme est actuellement en train d’être soumis à la fondation Eclipse afin d’être mise en open source sous licence Eclipse. Dans le cadre du projet Disrupt Campus, les étudiants sont invités à contribuer à la plateforme. Dans le cadre de vos formations c’est une vraie plus value de contribuer à de réels projets plutôt qu’à des projets one-shot qui seront mis à la poubelle sitôt votre soutenance terminée. EDCampus est donc une opportunité de contribuer au logiciel libre et à la fondation Eclipse (et de s'assurer une jolie ligne sur son CV plutôt qu'un projet qui sera aussi vite oublié que l'ECOM !). <br /> <br /> = L'équipe et leurs rôles =<br /> <br /> * GEOURJON Anthony - Chef de projet (EXT)<br /> * [[User:Servan.Charlot | CHARLOT Servan]] - Chef de groupe<br /> * [[User:Zoran.Chanet | CHANET Zoran]] - Responsable DevOps<br /> <br /> = Roadmap =<br /> * '''20-22 février 2019 :''' Hack Ton Campus, la plateforme EDCampus sera utilisée pour la gestion des défis.<br /> * '''Avril 2019 :''' Projet pilote, un projet mêlant une entreprise, l'UGA et des étudiants servira de test à la plateforme.<br /> * '''Septembre 2019 :''' Mise en production globale.<br /> <br /> = Carnet de bord =<br /> <br /> == Semaine 1 ==<br /> <br /> === 28/01/19 ===<br /> <br /> Assignation du sujet [[Contributions open-source au projet Eclipse EdCampus | EDCampus]].<br /> <br /> === 29/01/19 ===<br /> <br /> * Rencontre avec Anthony au [http://fabmstic.liglab.fr/ Fablab], presentation du sujet, des enjeux, et de la roadmap<br /> * Installation du projet<br /> ** Difficultés dues au DNS des réseaux universitaires (impossible de télécharger le contenu nécessaire depuis les containers)<br /> <br /> === 30/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $scope._getProjectParent()&lt;/code&gt; qui ne marchait pas du tout. Il y avait une faute dans la plupart des variables qui s'appelaient &lt;code&gt;currentParentProject&lt;/code&gt; au lieu de &lt;code&gt;currentProjectParent&lt;/code&gt;.<br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $rootScope._checkProject()&lt;/code&gt; qui oubliait un paramètre dans son appel à &lt;code&gt;$scope._setProject()&lt;/code&gt;.<br /> <br /> ==== Zoran ====<br /> * Assignation d'une première tâche : réparer la création d'un projet indépendant<br /> * Découverte du code du projet<br /> * Poursuite de l'arborescence des appels depuis le bouton jusqu'à l'appel à la base de données<br /> <br /> === 01/02/19 ===<br /> ==== Servan ====<br /> <br /> * Assignation de la tâche consistant à réparer le système de fichier.<br /> * Exploration du systeme de fichier et son implementation.<br /> <br /> ==== Zoran ====<br /> * Production d'une méthode permettant des logs personnalisés<br /> * Recherches sur le rewriting d'URL<br /> * Correction du problème (lié au rewriting)<br /> * Production d'une fiche explicative de la solution<br /> <br /> == Semaine 2 ==<br /> <br /> === 04/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction des bugs suivants :<br /> <br /> * Affichage des fichiers du portefeuille père ssi il y a au moins un fichier présent dans le projet fils.<br /> ** Dans le backend, la fonction qui get les fichiers exécutait un &lt;code&gt;return false&lt;/code&gt; avant de get les fichiers parents dans le cas ou il n'y avait pas de fichier à la base.<br /> * N'actualise pas la liste des fichiers si on supprime le dernier fichier.<br /> * Tous les dossiers sont affichés comme des fichiers. Lors de la première sélection à la souris, si on sélectionne le fichier-dossier, il se transforme en dossier et on peut y accéder. Rien ne se passe pour les sélections suivantes.<br /> ** Dans le backend, un paramètre était traité comme chaîne de caractère alors qu'il représentait un booléen. Le résultat de ça est que l'on entrait dans la mauvaise partie d'un if, qui exécutait la mauvaise requête SQL nous privant de l'information concernant le type de fichier lu (un dossier est un type de fichier).<br /> * Le bouton qui permet de revenir en arrière, sortir du dossier ne fonctionne pas.<br /> * On ne peut pas entrer dans un dossier hérité.<br /> <br /> ==== Zoran ====<br /> * Assignation de la mise en place de techniques DevOps<br /> * Recherches sur la mise en place de pipeline dans GitLab : voir [[GitLab CI/CD | compte-rendu]]<br /> * Mise en place d'un pipeline à chaque push<br /> * Production d'un tutoriel de création de runner GitLab : voir [[GitLab Runners | tutoriel]]<br /> * Recherches sur SonarQube et les tests unitaires<br /> ** Priorisation de SonarQube<br /> <br /> === 05/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug qui faisait que lors de la suppression d'un dossier, les fichiers à l'intérieur ne sont pas supprimés (le champ statut dans le BDD ne passe pas à 0).<br /> ** La fonctionnalité de suppression récursive n'était pas implémentée dans &lt;code&gt;File.php&lt;/code&gt;.<br /> * Début de l'analyse du système de droit des utilisateurs (Administrateur/Tuteur/Elève) sur les fichiers et dossiers (hérités ou non).<br /> <br /> ==== Zoran ====<br /> * Compréhension des scanners sonar : voir [[SonarQube Scanner | compte-rendu]]<br /> * Mise en place d'un scan dans le pipeline<br /> ** Nécessité d'un serveur sonar exposé<br /> ** Décision d'utiliser SonarCloud<br /> ** Configuration du scanner pour envoyer le rapport dans le bon projet sonarcloud<br /> ** Réussite du premier scan<br /> <br /> === 06/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Suite de la correction du système de droits des fichiers/dossiers.<br /> <br /> * Correction d'un bug qui faisait que les utilisateurs ne peuvent pas entrer dans les dossiers hérites (ou télécharger les fichiers hérites).<br /> ** Le check de droit se fait dans une fonction qui check d'abord le &lt;code&gt;ownerId&lt;/code&gt;, puis le &lt;code&gt;projectId&lt;/code&gt; et puis enfin si le fichier appartient à un parent. Pour cela elle fait appel à la base pour récupérer la relation d’héritage. IL y avait une erreur de comparaison entre le résultat de la requête et les information fichier (erreur de type parce que PHP).<br /> * Analyse complète du système de droit création d'un tableau explicatif de l'état actuel et l'état voulu.<br /> [[File:EDCampus_2019_Tableau_de_droits.png|center]]<br /> * Suite au tableau, mise en place de la protection des fichiers hérités.<br /> ** Ajout d'une vérification sur le &lt;code&gt;projectId&lt;/code&gt;, empêchant les utilisateurs non propriétaires du fichier de le supprimer, renommer ou déplacer.<br /> <br /> ==== Zoran ====<br /> * Extension du scan sonar dans le pipeline à toutes les sections du projet<br /> * Affichage de badges d'état du pipeline sur la page de présentation de chaque section du projet<br /> * Reprise des recherches concernant les tests unitaires<br /> * Tentative de systématisation des tests dans le pipeline<br /> ** Difficulté : les tests nécessitent des fichiers de configurations qui ne sont pas présents sur le repository git<br /> * Recherche de contournement pour ne pas exposer des configurations privées dans le projet public<br /> <br /> === 08/02/19 ===<br /> <br /> ==== Servan ====<br /> Suppression de la vue pour les non membres et correction partielle du système de droits.<br /> * Lorsque qu'une commande est envoyée par le front-end vers le back-end, elle passe dans une fonction qui vérifie les droits (&lt;code&gt;Right.php checkRights($command)&lt;/code&gt;). La fonction compare la commande utilisée par l'utilisateur aux commandes que cet utilisateur a en général le droit d'utiliser. Le problème était que le tableau de commandes au sein de la fonction (permettant la comparaison) contenait des commandes mal formatées. J'ai donc corrigé celle qui m'intéressais pour empêcher les non membres d'un projet à consulter les fichiers, et j'en ai profiter pour corriger toutes les autres.<br /> <br /> ==== Zoran ====<br /> * Configuration des scanners sonar dans le pipeline (redirection vers une branche du projet sonarcloud nommée selon la branche GitLab sur laquelle le pipeline est lancé)<br /> * Aide à la correction du système de droits<br /> * Réalisation de tâches mineures importantes pour le Hackaton<br /> ** Retirer la vidéo Waza de l'accueil de la plateforme<br /> ** Redirection de l'utilisateur vers la plateforme lorsqu'il accède à l'url du dossier : [[Apache mod_rewrite]]<br /> ** Correction de l'url donné lors de l'appel au service de mails pour la validation de compte<br /> <br /> == Semaine 3 ==<br /> <br /> === 12/02/19 ===<br /> <br /> ==== Servan ====<br /> * Systeme de droits entierement corrigé pour le cas des fichiers.<br /> ** Privilèges administrateurs.<br /> *** Dans la fonction qui verifie les droits &lt;code&gt;Right.php checkRights($command)&lt;/code&gt;, le cas de l'administrateur n'était pas vraiment traité. Il y avait un verification pour empecher tout utilisateur non administrateur d'executer une commande administrateur, mais sinon l'administrateur était traité comme un utilisateur lambda. J'ai donc ajouté un test permettant de donner les pleins pouvoirs. Presque. Il fallait aussi ajouter un test dans la fonction &lt;code&gt;File.php _checkFileAccess(...)&lt;/code&gt; qui pour certaines actions sur les fichiers, agit comme une surcouche à la fonction &lt;code&gt;checkRights&lt;/code&gt; (ce qui permet entre autres des actions sur les fichiers hérités pour le tuteur et les membres).<br /> ** Cas du déplacement de fichier hérités.<br /> *** Avec l'accord d'Anthony, on a conclu que le déplacement de fichier hérité était une mauvaise idée, donc cela reste non autorisé, même pour les admins.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être supprimés.<br /> ** Les appels à la base effectuait une comparaison avec un &lt;code&gt;LIKE&lt;/code&gt; au lieu d'un &lt;code&gt;=&lt;/code&gt; dans la requête SQL, ce qui ne marchait pas dans le cas présent.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être renommés.<br /> ** Le nom du fichier est traité et enregistré par le fichier JS, qui est non typé donc il decide que si le nom n'est que des numeros, alors ce ne sera pas une string. Or pour renommer le fichier, on veux modifer la partie du nom qui est avant le point (de l'extension), donc on fait un appel à &lt;code&gt;name.lastIndexOf(&quot;.&quot;);&lt;/code&gt;, qui s'execute eclusivement sur une string. J'ai donc realisé un &lt;code&gt;.toString()&lt;/code&gt; sur le nom à chaque fois que necessaire.<br /> * Correction du fait que lorsque l'on supprimait un fichier dans un dossier, on était renvoyé à la racine du projet plutot que dans le dossier.<br /> ** Il manquait un paramètre (le dossier) à la fonction &lt;code&gt;getFiles(...)&lt;/code&gt; appalée après la suppréssion.<br /> * Transformation du bouton &quot;Ajouter&quot; en deux boutons, un pour les dossiers, un pour les fichiers.<br /> <br /> ==== Zoran ====<br /> * Mise à Jour de templates de mail (&gt;100 templates)<br /> ** Remplacement des références à Waza Education par EDCampus<br /> ** Production d'une banière et remplacement de l'ancienne<br /> * Tests des fichiers de configuration des tests unitaires<br /> * Recherches sur le passage de l'HTTP vers HTTPS avec [https://letsencrypt.org/ Let's Encrypt] : voir le [[Let's Encrypt | résumé rapide]]<br /> ** Choix d'utilisation de [https://certbot.eff.org/ Certbot]<br /> <br /> === 13/02/19 ===<br /> <br /> ==== Servan ====<br /> Nouvelle tâche assignée : Améliorer les tâches, faire en sorte que si un nom est placé sur un label d'une couleur au sein d'un projet, tous les labels de cette couleur auront ce même nom.<br /> <br /> ==== Zoran ====<br /> * Sauvegarde de la base de données de l'ancienne plateforme<br /> * Passage de l'ancienne plateforme de l'HTTP à l'HTTPS<br /> ** Réparation de la configuration d'Apache<br /> ** Génération des certificats<br /> ** Configuration d'Apache pour l'HTTPS<br /> <br /> === 14/02/19 ===<br /> <br /> ==== Servan ====<br /> * Backend corrigé, on ne peux plus créer une tache d'un nom au choix si il y a deja une tache de cette couleur avec un nom dans le projet.<br /> * Etude approfondie du front-end et du systeme evenementiel pour corriger les defauts de mise à jour.<br /> <br /> ==== Zoran ====<br /> * Recherches sur l'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Découverte et compréhension d'une [https://github.com/BirgerK/docker-apache-letsencrypt image existante]<br /> * Tentative de passage de l'HTTP à l'HTTPS dans un Docker<br /> ** Sur la VM de l'ancienne plateforme (pour ne pas briser la version en prod)<br /> ** Fusion du Dockerfile existant et du Dockerfile de l'image trouvée<br /> <br /> === 15/02/19 ===<br /> <br /> ==== Servan ====<br /> * Correction superficielle des problemes des mise a jour a de la vue du systeme de tache. Le soucis etant que les taches et le petit menu qui indique les details ne sont pas le même module et n'interagissent pas vraiment entre eux, donc on ne peux pas actualier l'un depuis l'autre.<br /> * Correction du fait que dans le systeme de fichier, on ne pouvait pas délacer un fichier/dossier vers le dossier parent en le glissant sur la flèche retour. <br /> ** Le soucis venait du fichier html, qui avait l'air correct mais la variable qu'il etait censé recuppérer renvoyait undefined au lieu de l'identifiant du dossier parent.<br /> <br /> ==== Zoran ====<br /> * Poursuite de la tentative d'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Succès de la création de certificat<br /> ** L'HTTPS ne fonctionne toujours pas (sans doute à cause de la configuration d'Apache)<br /> <br /> == Semaine 4 ==<br /> <br /> Hack ton campus.<br /> <br /> == Semaine 5 ==<br /> <br /> === 05/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug trouvé lors que hackaton qui empêchait les étudiants de télécharger un fichier hérité appartenant à un tuteur. <br /> * Début d'un travail sur les tests unitaires du backend. Le but est de vérifier les tests existants, essayer de les faire fonctionner, et s'en inspirer pour en créer d'autres et à terme, couvrir tout le code.<br /> <br /> ==== Zoran ====<br /> * Succès de la mise en place d'HTTPS dans un docker<br /> ** Modification de &lt;code&gt;docker-compose.yml&lt;/code&gt; pour lier les ports 443 de l'hôte et du conteneur<br /> ** Finalisation de la configuration d'Apache dans le conteneur<br /> <br /> === 06/03/19 ===<br /> <br /> ==== Servan et Zoran ====<br /> <br /> * Lecture de la [https://phpunit.readthedocs.io/en/8.0/ documentation de PHPUNit.]<br /> Après un travail de recherche, nous nous sommes rendu compte que PHPUnit allait être difficile à mettre en place sur le backend du projet. En effet, toutes les fonctions sont en ''static'' et il est impossible de mocker les fonctions statiques avec PHPUnit. Il faudrait donc revoir l'architecture du code pour mocker le statique, et donc remplacer les appels à la base de données par des appels simulés. Cela éviterait d'avoir à créer une base externe accessible ou construire une base dans le runner du pipeline. Cependant cela est trop long a mettre en place sachant que l'on arrive sur la fin du projet, donc nous avons donné priorité à la vitrine, suite à une réunion avec les membres de Disrupt campus. <br /> <br /> La vitrine est un endroit où le public (étudiants/professeurs/entreprises) peut consulter les projets réalisés ou en cours. Cette vitrine se décompose en un endroit ou l'on peut consulter la liste des projets d'une université, et des pages de projet individuelles avec une image, une description et les livrables.<br /> <br /> === 07/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction d'un bug en rapport avec les accents dans les noms. Lorsque qu'un utilisateur possède un accent dans son nom (ex: Amélie), au moment de la création du login la chaîne de caractère est mal interprétée et le login est tronqué au niveau de l'accent (ex: amY). L'architecture fait que lors du transfert du nom du front vers le back, l'accent est codé avec des caractères classiques, qui sont ensuite interprétés correctement lors de l'ajout en base. Mais cela veux dire que pendant tout le passage en backend on travaille avec des accents codés. Le login était créé à partir du nom et du prénom de l'utilisateur, qui peuvent donc être temporairement corrompus par des accents codés. La correction à se soucis est donc détecter la présence d'accents dans les noms, et si il y en a, créer le login à partir de la première partie de l'adresse mail de l'utilisateur (avant le @), sinon, on fait comme avant avec les noms.<br /> <br /> ==== Zoran ====<br /> * Correction d'un bug empêchant l'envoi d'e-mail lors de l'ajout d'un utilisateur à un projet<br /> * Prospection dans le code et la base de donnée pour permettre l'affichage ou non des évaluations dans le menu des projets. La section des évaluations étant gérée différemment des autres sections, ce travail nécessitera plus de temps que prévu et a donc été reporté au profit de la vitrine<br /> <br /> === 08/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Archéologie sur le prototype de vitrine.<br /> * Rédaction de documentation générale sur l'architecture End-To-End du projet (ci-dessous).<br /> <br /> [[File:EDCampus 2019 EndToEnd.png|border]]<br /> <br /> Détails de la fonction &lt;code&gt;checkRights&lt;/code&gt; :<br /> <br /> * La commande en cours est envoyée à &lt;code&gt;checkRights&lt;/code&gt; sous forme de string.<br /> * On vérifie d'abord si elle fait partie des commandes publiques, que l'on peux exécuter lorsque l'on a pas de session. (Via une comparaison avec un tableau contenant toutes les commandes publiques.)<br /> * Si ce n'est pas la cas, on récupère ensuite les informations de session et l'identifiant utilisateur.<br /> * Si on ne trouve pas d'utilisateur, on regarde si on essai d’accéder a une page publique, sinon on bloque l'accès.<br /> * On a maintenant un utilisateur avec une session, qui essaie d'agir sur une page non publique.<br /> * On vérifie si l'utilisateur est super-administrateur.<br /> * On vérifie si l'utilisateur essai d’exécuter une commande administrateur, en tant qu'administrateur.<br /> * Puisque la page est non-publique et que l'on est pas administrateur, il s'agit forcement d'une page de projet. <br /> * On vérifie si l'utilisateur est propriétaire du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est propriétaire du projet courant et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet courant et que cette commande est autorisée.<br /> * Si aucun des tests ci dessus n'a raté (ou n'a déjà accordé l'accès), on accorde l'accès.<br /> <br /> ==== Zoran ====<br /> * Archéologie sur le prototype de vitrine<br /> * Réparation des appels au serveur opérés par le prototype de vitrine existant<br /> ** La vitrine étant écrite en php et non en utilisant AngularJS comme le reste du front-end, la gestion des appels est différente<br /> ** Correction du lien par lequel le serveur est appelé<br /> ** Correction des arguments et de la commande donnés lors de l'appel au serveur<br /> * Correction du nombre de projets affichés avant extension<br /> * Prospection pour l'utilisation future de la vitrine<br /> <br /> == Semaine 6 ==<br /> <br /> === 11/03/19 ===<br /> <br /> * Correction d'un bug d'affichage. L'administrateur peut choisir dans son profil quel est son campus principal, et cela est utile entre autres dans la partie communication de son dashboard. C'est à cet endroit qu'il peut choisir de rendre publique la page de son université (ie. la vitrine). A cet endroit, la vitrine est renseignée par un lien (&lt;code&gt;http://localhost/app/campus/?u=UGA&lt;/code&gt;), contenant le nom du campus au bout (UGA). Le bug faisait que ce nom n'était pas affiché et donc l'URL était incomplet. Le soucis venait du backend, ou la requête du campus à la base ne demandait pas le champ nom.<br /> * Correction des projets affichés en vitrine<br /> ** Affichage des projets fils et indépendants seulement (pas les portefeuilles)<br /> ** Explicitation du nom des projets fils (Si ''Equipe A'' appartient au portefeuille ''Défi 3'', son nom affiché sera ''Défi 3 &gt; Equipe A''<br /> * Ajout d'un texte de remplacement lorsqu'une section est vide (plus élégant qu'un grand espace vide)<br /> <br /> === 12/03/19 ===<br /> <br /> <br /> === 13/03/19 ===<br /> <br /> <br /> === 14/03/19 ===<br /> <br /> <br /> === 15/03/19 ===</div>

Zoran.Chanet https://air.imag.fr/index.php?title=PROJET-INFO5_1819_EDCampus&diff=45250 2019-03-11T12:21:31Z

<p>Zoran.Chanet: /* Zoran */</p> <hr /> <div>[[File:Logo_EDCampus.png|thumb|right| Logo EDCampus]]<br /> = Le projet en quelques mots =<br /> La plateforme [[Contributions open-source au projet Eclipse EdCampus | EDCampus]] est une plateforme de gestion de projet développé par Disrupt Campus Grenoble. La plateforme est actuellement en train d’être soumis à la fondation Eclipse afin d’être mise en open source sous licence Eclipse. Dans le cadre du projet Disrupt Campus, les étudiants sont invités à contribuer à la plateforme. Dans le cadre de vos formations c’est une vraie plus value de contribuer à de réels projets plutôt qu’à des projets one-shot qui seront mis à la poubelle sitôt votre soutenance terminée. EDCampus est donc une opportunité de contribuer au logiciel libre et à la fondation Eclipse (et de s'assurer une jolie ligne sur son CV plutôt qu'un projet qui sera aussi vite oublié que l'ECOM !). <br /> <br /> = L'équipe et leurs rôles =<br /> <br /> * GEOURJON Anthony - Chef de projet (EXT)<br /> * [[User:Servan.Charlot | CHARLOT Servan]] - Chef de groupe<br /> * [[User:Zoran.Chanet | CHANET Zoran]] - Responsable DevOps<br /> <br /> = Roadmap =<br /> * '''20-22 février 2019 :''' Hack Ton Campus, la plateforme EDCampus sera utilisée pour la gestion des défis.<br /> * '''Avril 2019 :''' Projet pilote, un projet mêlant une entreprise, l'UGA et des étudiants servira de test à la plateforme.<br /> * '''Septembre 2019 :''' Mise en production globale.<br /> <br /> = Carnet de bord =<br /> <br /> == Semaine 1 ==<br /> <br /> === 28/01/19 ===<br /> <br /> Assignation du sujet [[Contributions open-source au projet Eclipse EdCampus | EDCampus]].<br /> <br /> === 29/01/19 ===<br /> <br /> * Rencontre avec Anthony au [http://fabmstic.liglab.fr/ Fablab], presentation du sujet, des enjeux, et de la roadmap<br /> * Installation du projet<br /> ** Difficultés dues au DNS des réseaux universitaires (impossible de télécharger le contenu nécessaire depuis les containers)<br /> <br /> === 30/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $scope._getProjectParent()&lt;/code&gt; qui ne marchait pas du tout. Il y avait une faute dans la plupart des variables qui s'appelaient &lt;code&gt;currentParentProject&lt;/code&gt; au lieu de &lt;code&gt;currentProjectParent&lt;/code&gt;.<br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $rootScope._checkProject()&lt;/code&gt; qui oubliait un paramètre dans son appel à &lt;code&gt;$scope._setProject()&lt;/code&gt;.<br /> <br /> ==== Zoran ====<br /> * Assignation d'une première tâche : réparer la création d'un projet indépendant<br /> * Découverte du code du projet<br /> * Poursuite de l'arborescence des appels depuis le bouton jusqu'à l'appel à la base de données<br /> <br /> === 01/02/19 ===<br /> ==== Servan ====<br /> <br /> * Assignation de la tâche consistant à réparer le système de fichier.<br /> * Exploration du systeme de fichier et son implementation.<br /> <br /> ==== Zoran ====<br /> * Production d'une méthode permettant des logs personnalisés<br /> * Recherches sur le rewriting d'URL<br /> * Correction du problème (lié au rewriting)<br /> * Production d'une fiche explicative de la solution<br /> <br /> == Semaine 2 ==<br /> <br /> === 04/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction des bugs suivants :<br /> <br /> * Affichage des fichiers du portefeuille père ssi il y a au moins un fichier présent dans le projet fils.<br /> ** Dans le backend, la fonction qui get les fichiers exécutait un &lt;code&gt;return false&lt;/code&gt; avant de get les fichiers parents dans le cas ou il n'y avait pas de fichier à la base.<br /> * N'actualise pas la liste des fichiers si on supprime le dernier fichier.<br /> * Tous les dossiers sont affichés comme des fichiers. Lors de la première sélection à la souris, si on sélectionne le fichier-dossier, il se transforme en dossier et on peut y accéder. Rien ne se passe pour les sélections suivantes.<br /> ** Dans le backend, un paramètre était traité comme chaîne de caractère alors qu'il représentait un booléen. Le résultat de ça est que l'on entrait dans la mauvaise partie d'un if, qui exécutait la mauvaise requête SQL nous privant de l'information concernant le type de fichier lu (un dossier est un type de fichier).<br /> * Le bouton qui permet de revenir en arrière, sortir du dossier ne fonctionne pas.<br /> * On ne peut pas entrer dans un dossier hérité.<br /> <br /> ==== Zoran ====<br /> * Assignation de la mise en place de techniques DevOps<br /> * Recherches sur la mise en place de pipeline dans GitLab : voir [[GitLab CI/CD | compte-rendu]]<br /> * Mise en place d'un pipeline à chaque push<br /> * Production d'un tutoriel de création de runner GitLab : voir [[GitLab Runners | tutoriel]]<br /> * Recherches sur SonarQube et les tests unitaires<br /> ** Priorisation de SonarQube<br /> <br /> === 05/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug qui faisait que lors de la suppression d'un dossier, les fichiers à l'intérieur ne sont pas supprimés (le champ statut dans le BDD ne passe pas à 0).<br /> ** La fonctionnalité de suppression récursive n'était pas implémentée dans &lt;code&gt;File.php&lt;/code&gt;.<br /> * Début de l'analyse du système de droit des utilisateurs (Administrateur/Tuteur/Elève) sur les fichiers et dossiers (hérités ou non).<br /> <br /> ==== Zoran ====<br /> * Compréhension des scanners sonar : voir [[SonarQube Scanner | compte-rendu]]<br /> * Mise en place d'un scan dans le pipeline<br /> ** Nécessité d'un serveur sonar exposé<br /> ** Décision d'utiliser SonarCloud<br /> ** Configuration du scanner pour envoyer le rapport dans le bon projet sonarcloud<br /> ** Réussite du premier scan<br /> <br /> === 06/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Suite de la correction du système de droits des fichiers/dossiers.<br /> <br /> * Correction d'un bug qui faisait que les utilisateurs ne peuvent pas entrer dans les dossiers hérites (ou télécharger les fichiers hérites).<br /> ** Le check de droit se fait dans une fonction qui check d'abord le &lt;code&gt;ownerId&lt;/code&gt;, puis le &lt;code&gt;projectId&lt;/code&gt; et puis enfin si le fichier appartient à un parent. Pour cela elle fait appel à la base pour récupérer la relation d’héritage. IL y avait une erreur de comparaison entre le résultat de la requête et les information fichier (erreur de type parce que PHP).<br /> * Analyse complète du système de droit création d'un tableau explicatif de l'état actuel et l'état voulu.<br /> [[File:EDCampus_2019_Tableau_de_droits.png|center]]<br /> * Suite au tableau, mise en place de la protection des fichiers hérités.<br /> ** Ajout d'une vérification sur le &lt;code&gt;projectId&lt;/code&gt;, empêchant les utilisateurs non propriétaires du fichier de le supprimer, renommer ou déplacer.<br /> <br /> ==== Zoran ====<br /> * Extension du scan sonar dans le pipeline à toutes les sections du projet<br /> * Affichage de badges d'état du pipeline sur la page de présentation de chaque section du projet<br /> * Reprise des recherches concernant les tests unitaires<br /> * Tentative de systématisation des tests dans le pipeline<br /> ** Difficulté : les tests nécessitent des fichiers de configurations qui ne sont pas présents sur le repository git<br /> * Recherche de contournement pour ne pas exposer des configurations privées dans le projet public<br /> <br /> === 08/02/19 ===<br /> <br /> ==== Servan ====<br /> Suppression de la vue pour les non membres et correction partielle du système de droits.<br /> * Lorsque qu'une commande est envoyée par le front-end vers le back-end, elle passe dans une fonction qui vérifie les droits (&lt;code&gt;Right.php checkRights($command)&lt;/code&gt;). La fonction compare la commande utilisée par l'utilisateur aux commandes que cet utilisateur a en général le droit d'utiliser. Le problème était que le tableau de commandes au sein de la fonction (permettant la comparaison) contenait des commandes mal formatées. J'ai donc corrigé celle qui m'intéressais pour empêcher les non membres d'un projet à consulter les fichiers, et j'en ai profiter pour corriger toutes les autres.<br /> <br /> ==== Zoran ====<br /> * Configuration des scanners sonar dans le pipeline (redirection vers une branche du projet sonarcloud nommée selon la branche GitLab sur laquelle le pipeline est lancé)<br /> * Aide à la correction du système de droits<br /> * Réalisation de tâches mineures importantes pour le Hackaton<br /> ** Retirer la vidéo Waza de l'accueil de la plateforme<br /> ** Redirection de l'utilisateur vers la plateforme lorsqu'il accède à l'url du dossier : [[Apache mod_rewrite]]<br /> ** Correction de l'url donné lors de l'appel au service de mails pour la validation de compte<br /> <br /> == Semaine 3 ==<br /> <br /> === 12/02/19 ===<br /> <br /> ==== Servan ====<br /> * Systeme de droits entierement corrigé pour le cas des fichiers.<br /> ** Privilèges administrateurs.<br /> *** Dans la fonction qui verifie les droits &lt;code&gt;Right.php checkRights($command)&lt;/code&gt;, le cas de l'administrateur n'était pas vraiment traité. Il y avait un verification pour empecher tout utilisateur non administrateur d'executer une commande administrateur, mais sinon l'administrateur était traité comme un utilisateur lambda. J'ai donc ajouté un test permettant de donner les pleins pouvoirs. Presque. Il fallait aussi ajouter un test dans la fonction &lt;code&gt;File.php _checkFileAccess(...)&lt;/code&gt; qui pour certaines actions sur les fichiers, agit comme une surcouche à la fonction &lt;code&gt;checkRights&lt;/code&gt; (ce qui permet entre autres des actions sur les fichiers hérités pour le tuteur et les membres).<br /> ** Cas du déplacement de fichier hérités.<br /> *** Avec l'accord d'Anthony, on a conclu que le déplacement de fichier hérité était une mauvaise idée, donc cela reste non autorisé, même pour les admins.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être supprimés.<br /> ** Les appels à la base effectuait une comparaison avec un &lt;code&gt;LIKE&lt;/code&gt; au lieu d'un &lt;code&gt;=&lt;/code&gt; dans la requête SQL, ce qui ne marchait pas dans le cas présent.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être renommés.<br /> ** Le nom du fichier est traité et enregistré par le fichier JS, qui est non typé donc il decide que si le nom n'est que des numeros, alors ce ne sera pas une string. Or pour renommer le fichier, on veux modifer la partie du nom qui est avant le point (de l'extension), donc on fait un appel à &lt;code&gt;name.lastIndexOf(&quot;.&quot;);&lt;/code&gt;, qui s'execute eclusivement sur une string. J'ai donc realisé un &lt;code&gt;.toString()&lt;/code&gt; sur le nom à chaque fois que necessaire.<br /> * Correction du fait que lorsque l'on supprimait un fichier dans un dossier, on était renvoyé à la racine du projet plutot que dans le dossier.<br /> ** Il manquait un paramètre (le dossier) à la fonction &lt;code&gt;getFiles(...)&lt;/code&gt; appalée après la suppréssion.<br /> * Transformation du bouton &quot;Ajouter&quot; en deux boutons, un pour les dossiers, un pour les fichiers.<br /> <br /> ==== Zoran ====<br /> * Mise à Jour de templates de mail (&gt;100 templates)<br /> ** Remplacement des références à Waza Education par EDCampus<br /> ** Production d'une banière et remplacement de l'ancienne<br /> * Tests des fichiers de configuration des tests unitaires<br /> * Recherches sur le passage de l'HTTP vers HTTPS avec [https://letsencrypt.org/ Let's Encrypt] : voir le [[Let's Encrypt | résumé rapide]]<br /> ** Choix d'utilisation de [https://certbot.eff.org/ Certbot]<br /> <br /> === 13/02/19 ===<br /> <br /> ==== Servan ====<br /> Nouvelle tâche assignée : Améliorer les tâches, faire en sorte que si un nom est placé sur un label d'une couleur au sein d'un projet, tous les labels de cette couleur auront ce même nom.<br /> <br /> ==== Zoran ====<br /> * Sauvegarde de la base de données de l'ancienne plateforme<br /> * Passage de l'ancienne plateforme de l'HTTP à l'HTTPS<br /> ** Réparation de la configuration d'Apache<br /> ** Génération des certificats<br /> ** Configuration d'Apache pour l'HTTPS<br /> <br /> === 14/02/19 ===<br /> <br /> ==== Servan ====<br /> * Backend corrigé, on ne peux plus créer une tache d'un nom au choix si il y a deja une tache de cette couleur avec un nom dans le projet.<br /> * Etude approfondie du front-end et du systeme evenementiel pour corriger les defauts de mise à jour.<br /> <br /> ==== Zoran ====<br /> * Recherches sur l'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Découverte et compréhension d'une [https://github.com/BirgerK/docker-apache-letsencrypt image existante]<br /> * Tentative de passage de l'HTTP à l'HTTPS dans un Docker<br /> ** Sur la VM de l'ancienne plateforme (pour ne pas briser la version en prod)<br /> ** Fusion du Dockerfile existant et du Dockerfile de l'image trouvée<br /> <br /> === 15/02/19 ===<br /> <br /> ==== Servan ====<br /> * Correction superficielle des problemes des mise a jour a de la vue du systeme de tache. Le soucis etant que les taches et le petit menu qui indique les details ne sont pas le même module et n'interagissent pas vraiment entre eux, donc on ne peux pas actualier l'un depuis l'autre.<br /> * Correction du fait que dans le systeme de fichier, on ne pouvait pas délacer un fichier/dossier vers le dossier parent en le glissant sur la flèche retour. <br /> ** Le soucis venait du fichier html, qui avait l'air correct mais la variable qu'il etait censé recuppérer renvoyait undefined au lieu de l'identifiant du dossier parent.<br /> <br /> ==== Zoran ====<br /> * Poursuite de la tentative d'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Succès de la création de certificat<br /> ** L'HTTPS ne fonctionne toujours pas (sans doute à cause de la configuration d'Apache)<br /> <br /> == Semaine 4 ==<br /> <br /> Hack ton campus.<br /> <br /> == Semaine 5 ==<br /> <br /> === 05/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug trouvé lors que hackaton qui empêchait les étudiants de télécharger un fichier hérité appartenant à un tuteur. <br /> * Début d'un travail sur les tests unitaires du backend. Le but est de vérifier les tests existants, essayer de les faire fonctionner, et s'en inspirer pour en créer d'autres et à terme, couvrir tout le code.<br /> <br /> ==== Zoran ====<br /> * Succès de la mise en place d'HTTPS dans un docker<br /> ** Modification de &lt;code&gt;docker-compose.yml&lt;/code&gt; pour lier les ports 443 de l'hôte et du conteneur<br /> ** Finalisation de la configuration d'Apache dans le conteneur<br /> <br /> === 06/03/19 ===<br /> <br /> ==== Servan et Zoran ====<br /> <br /> * Lecture de la [https://phpunit.readthedocs.io/en/8.0/ documentation de PHPUNit.]<br /> Après un travail de recherche, nous nous sommes rendu compte que PHPUnit allait être difficile à mettre en place sur le backend du projet. En effet, toutes les fonctions sont en ''static'' et il est impossible de mocker les fonctions statiques avec PHPUnit. Il faudrait donc revoir l'architecture du code pour mocker le statique, et donc remplacer les appels à la base de données par des appels simulés. Cela éviterait d'avoir à créer une base externe accessible ou construire une base dans le runner du pipeline. Cependant cela est trop long a mettre en place sachant que l'on arrive sur la fin du projet, donc nous avons donné priorité à la vitrine, suite à une réunion avec les membres de Disrupt campus. <br /> <br /> La vitrine est un endroit où le public (étudiants/professeurs/entreprises) peut consulter les projets réalisés ou en cours. Cette vitrine se décompose en un endroit ou l'on peut consulter la liste des projets d'une université, et des pages de projet individuelles avec une image, une description et les livrables.<br /> <br /> === 07/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction d'un bug en rapport avec les accents dans les noms. Lorsque qu'un utilisateur possède un accent dans son nom (ex: Amélie), au moment de la création du login la chaîne de caractère est mal interprétée et le login est tronqué au niveau de l'accent (ex: amY). L'architecture fait que lors du transfert du nom du front vers le back, l'accent est codé avec des caractères classiques, qui sont ensuite interprétés correctement lors de l'ajout en base. Mais cela veux dire que pendant tout le passage en backend on travaille avec des accents codés. Le login était créé à partir du nom et du prénom de l'utilisateur, qui peuvent donc être temporairement corrompus par des accents codés. La correction à se soucis est donc détecter la présence d'accents dans les noms, et si il y en a, créer le login à partir de la première partie de l'adresse mail de l'utilisateur (avant le @), sinon, on fait comme avant avec les noms.<br /> <br /> ==== Zoran ====<br /> * Correction d'un bug empêchant l'envoi d'e-mail lors de l'ajout d'un utilisateur à un projet<br /> * Prospection dans le code et la base de donnée pour permettre l'affichage ou non des évaluations dans le menu des projets. La section des évaluations étant gérée différemment des autres sections, ce travail nécessitera plus de temps que prévu et a donc été reporté au profit de la vitrine<br /> <br /> === 08/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Archéologie sur le prototype de vitrine.<br /> * Rédaction de documentation générale sur l'architecture End-To-End du projet (ci-dessous).<br /> <br /> [[File:EDCampus 2019 EndToEnd.png|border]]<br /> <br /> Détails de la fonction &lt;code&gt;checkRights&lt;/code&gt; :<br /> <br /> * La commande en cours est envoyée à &lt;code&gt;checkRights&lt;/code&gt; sous forme de string.<br /> * On vérifie d'abord si elle fait partie des commandes publiques, que l'on peux exécuter lorsque l'on a pas de session. (Via une comparaison avec un tableau contenant toutes les commandes publiques.)<br /> * Si ce n'est pas la cas, on récupère ensuite les informations de session et l'identifiant utilisateur.<br /> * Si on ne trouve pas d'utilisateur, on regarde si on essai d’accéder a une page publique, sinon on bloque l'accès.<br /> * On a maintenant un utilisateur avec une session, qui essaie d'agir sur une page non publique.<br /> * On vérifie si l'utilisateur est super-administrateur.<br /> * On vérifie si l'utilisateur essai d’exécuter une commande administrateur, en tant qu'administrateur.<br /> * Puisque la page est non-publique et que l'on est pas administrateur, il s'agit forcement d'une page de projet. <br /> * On vérifie si l'utilisateur est propriétaire du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est propriétaire du projet courant et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet courant et que cette commande est autorisée.<br /> * Si aucun des tests ci dessus n'a raté (ou n'a déjà accordé l'accès), on accorde l'accès.<br /> <br /> ==== Zoran ====<br /> * Archéologie sur le prototype de vitrine<br /> * Réparation des appels au serveur opérés par le prototype de vitrine existant<br /> ** La vitrine étant écrite en php et non en utilisant AngularJS comme le reste du front-end, la gestion des appels est différente<br /> ** Correction du lien par lequel le serveur est appelé<br /> ** Correction des arguments et de la commande donnés lors de l'appel au serveur<br /> * Correction du nombre de projets affichés avant extension<br /> * Prospection pour l'utilisation future de la vitrine<br /> <br /> == Semaine 6 ==<br /> <br /> === 11/03/19 ===<br /> <br /> * Correction d'un bug d'affichage. <br /> <br /> === 12/03/19 ===<br /> <br /> <br /> === 13/03/19 ===<br /> <br /> <br /> === 14/03/19 ===<br /> <br /> <br /> === 15/03/19 ===</div>

Zoran.Chanet https://air.imag.fr/index.php?title=PROJET-INFO5_1819_EDCampus&diff=45248 2019-03-11T12:17:12Z

<p>Zoran.Chanet: /* Zoran */</p> <hr /> <div>[[File:Logo_EDCampus.png|thumb|right| Logo EDCampus]]<br /> = Le projet en quelques mots =<br /> La plateforme [[Contributions open-source au projet Eclipse EdCampus | EDCampus]] est une plateforme de gestion de projet développé par Disrupt Campus Grenoble. La plateforme est actuellement en train d’être soumis à la fondation Eclipse afin d’être mise en open source sous licence Eclipse. Dans le cadre du projet Disrupt Campus, les étudiants sont invités à contribuer à la plateforme. Dans le cadre de vos formations c’est une vraie plus value de contribuer à de réels projets plutôt qu’à des projets one-shot qui seront mis à la poubelle sitôt votre soutenance terminée. EDCampus est donc une opportunité de contribuer au logiciel libre et à la fondation Eclipse (et de s'assurer une jolie ligne sur son CV plutôt qu'un projet qui sera aussi vite oublié que l'ECOM !). <br /> <br /> = L'équipe et leurs rôles =<br /> <br /> * GEOURJON Anthony - Chef de projet (EXT)<br /> * [[User:Servan.Charlot | CHARLOT Servan]] - Chef de groupe<br /> * [[User:Zoran.Chanet | CHANET Zoran]] - Responsable DevOps<br /> <br /> = Roadmap =<br /> * '''20-22 février 2019 :''' Hack Ton Campus, la plateforme EDCampus sera utilisée pour la gestion des défis.<br /> * '''Avril 2019 :''' Projet pilote, un projet mêlant une entreprise, l'UGA et des étudiants servira de test à la plateforme.<br /> * '''Septembre 2019 :''' Mise en production globale.<br /> <br /> = Carnet de bord =<br /> <br /> == Semaine 1 ==<br /> <br /> === 28/01/19 ===<br /> <br /> Assignation du sujet [[Contributions open-source au projet Eclipse EdCampus | EDCampus]].<br /> <br /> === 29/01/19 ===<br /> <br /> * Rencontre avec Anthony au [http://fabmstic.liglab.fr/ Fablab], presentation du sujet, des enjeux, et de la roadmap<br /> * Installation du projet<br /> ** Difficultés dues au DNS des réseaux universitaires (impossible de télécharger le contenu nécessaire depuis les containers)<br /> <br /> === 30/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $scope._getProjectParent()&lt;/code&gt; qui ne marchait pas du tout. Il y avait une faute dans la plupart des variables qui s'appelaient &lt;code&gt;currentParentProject&lt;/code&gt; au lieu de &lt;code&gt;currentProjectParent&lt;/code&gt;.<br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $rootScope._checkProject()&lt;/code&gt; qui oubliait un paramètre dans son appel à &lt;code&gt;$scope._setProject()&lt;/code&gt;.<br /> <br /> ==== Zoran ====<br /> * Assignation d'une première tâche : réparer la création d'un projet indépendant<br /> * Découverte du code du projet<br /> * Poursuite de l'arborescence des appels depuis le bouton jusqu'à l'appel à la base de données<br /> <br /> === 01/02/19 ===<br /> ==== Servan ====<br /> <br /> * Assignation de la tâche consistant à réparer le système de fichier.<br /> * Exploration du systeme de fichier et son implementation.<br /> <br /> ==== Zoran ====<br /> * Production d'une méthode permettant des logs personnalisés<br /> * Recherches sur le rewriting d'URL<br /> * Correction du problème (lié au rewriting)<br /> * Production d'une fiche explicative de la solution<br /> <br /> == Semaine 2 ==<br /> <br /> === 04/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction des bugs suivants :<br /> <br /> * Affichage des fichiers du portefeuille père ssi il y a au moins un fichier présent dans le projet fils.<br /> ** Dans le backend, la fonction qui get les fichiers exécutait un &lt;code&gt;return false&lt;/code&gt; avant de get les fichiers parents dans le cas ou il n'y avait pas de fichier à la base.<br /> * N'actualise pas la liste des fichiers si on supprime le dernier fichier.<br /> * Tous les dossiers sont affichés comme des fichiers. Lors de la première sélection à la souris, si on sélectionne le fichier-dossier, il se transforme en dossier et on peut y accéder. Rien ne se passe pour les sélections suivantes.<br /> ** Dans le backend, un paramètre était traité comme chaîne de caractère alors qu'il représentait un booléen. Le résultat de ça est que l'on entrait dans la mauvaise partie d'un if, qui exécutait la mauvaise requête SQL nous privant de l'information concernant le type de fichier lu (un dossier est un type de fichier).<br /> * Le bouton qui permet de revenir en arrière, sortir du dossier ne fonctionne pas.<br /> * On ne peut pas entrer dans un dossier hérité.<br /> <br /> ==== Zoran ====<br /> * Assignation de la mise en place de techniques DevOps<br /> * Recherches sur la mise en place de pipeline dans GitLab : voir [[GitLab CI/CD | compte-rendu]]<br /> * Mise en place d'un pipeline à chaque push<br /> * Production d'un tutoriel de création de runner GitLab : voir [[GitLab Runners | tutoriel]]<br /> * Recherches sur SonarQube et les tests unitaires<br /> ** Priorisation de SonarQube<br /> <br /> === 05/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug qui faisait que lors de la suppression d'un dossier, les fichiers à l'intérieur ne sont pas supprimés (le champ statut dans le BDD ne passe pas à 0).<br /> ** La fonctionnalité de suppression récursive n'était pas implémentée dans &lt;code&gt;File.php&lt;/code&gt;.<br /> * Début de l'analyse du système de droit des utilisateurs (Administrateur/Tuteur/Elève) sur les fichiers et dossiers (hérités ou non).<br /> <br /> ==== Zoran ====<br /> * Compréhension des scanners sonar : voir [[SonarQube Scanner | compte-rendu]]<br /> * Mise en place d'un scan dans le pipeline<br /> ** Nécessité d'un serveur sonar exposé<br /> ** Décision d'utiliser SonarCloud<br /> ** Configuration du scanner pour envoyer le rapport dans le bon projet sonarcloud<br /> ** Réussite du premier scan<br /> <br /> === 06/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Suite de la correction du système de droits des fichiers/dossiers.<br /> <br /> * Correction d'un bug qui faisait que les utilisateurs ne peuvent pas entrer dans les dossiers hérites (ou télécharger les fichiers hérites).<br /> ** Le check de droit se fait dans une fonction qui check d'abord le &lt;code&gt;ownerId&lt;/code&gt;, puis le &lt;code&gt;projectId&lt;/code&gt; et puis enfin si le fichier appartient à un parent. Pour cela elle fait appel à la base pour récupérer la relation d’héritage. IL y avait une erreur de comparaison entre le résultat de la requête et les information fichier (erreur de type parce que PHP).<br /> * Analyse complète du système de droit création d'un tableau explicatif de l'état actuel et l'état voulu.<br /> [[File:EDCampus_2019_Tableau_de_droits.png|center]]<br /> * Suite au tableau, mise en place de la protection des fichiers hérités.<br /> ** Ajout d'une vérification sur le &lt;code&gt;projectId&lt;/code&gt;, empêchant les utilisateurs non propriétaires du fichier de le supprimer, renommer ou déplacer.<br /> <br /> ==== Zoran ====<br /> * Extension du scan sonar dans le pipeline à toutes les sections du projet<br /> * Affichage de badges d'état du pipeline sur la page de présentation de chaque section du projet<br /> * Reprise des recherches concernant les tests unitaires<br /> * Tentative de systématisation des tests dans le pipeline<br /> ** Difficulté : les tests nécessitent des fichiers de configurations qui ne sont pas présents sur le repository git<br /> * Recherche de contournement pour ne pas exposer des configurations privées dans le projet public<br /> <br /> === 08/02/19 ===<br /> <br /> ==== Servan ====<br /> Suppression de la vue pour les non membres et correction partielle du système de droits.<br /> * Lorsque qu'une commande est envoyée par le front-end vers le back-end, elle passe dans une fonction qui vérifie les droits (&lt;code&gt;Right.php checkRights($command)&lt;/code&gt;). La fonction compare la commande utilisée par l'utilisateur aux commandes que cet utilisateur a en général le droit d'utiliser. Le problème était que le tableau de commandes au sein de la fonction (permettant la comparaison) contenait des commandes mal formatées. J'ai donc corrigé celle qui m'intéressais pour empêcher les non membres d'un projet à consulter les fichiers, et j'en ai profiter pour corriger toutes les autres.<br /> <br /> ==== Zoran ====<br /> * Configuration des scanners sonar dans le pipeline (redirection vers une branche du projet sonarcloud nommée selon la branche GitLab sur laquelle le pipeline est lancé)<br /> * Aide à la correction du système de droits<br /> * Réalisation de tâches mineures importantes pour le Hackaton<br /> ** Retirer la vidéo Waza de l'accueil de la plateforme<br /> ** Redirection de l'utilisateur vers la plateforme lorsqu'il accède à l'url du dossier : [[Apache mod_rewrite]]<br /> ** Correction de l'url donné lors de l'appel au service de mails pour la validation de compte<br /> <br /> == Semaine 3 ==<br /> <br /> === 12/02/19 ===<br /> <br /> ==== Servan ====<br /> * Systeme de droits entierement corrigé pour le cas des fichiers.<br /> ** Privilèges administrateurs.<br /> *** Dans la fonction qui verifie les droits &lt;code&gt;Right.php checkRights($command)&lt;/code&gt;, le cas de l'administrateur n'était pas vraiment traité. Il y avait un verification pour empecher tout utilisateur non administrateur d'executer une commande administrateur, mais sinon l'administrateur était traité comme un utilisateur lambda. J'ai donc ajouté un test permettant de donner les pleins pouvoirs. Presque. Il fallait aussi ajouter un test dans la fonction &lt;code&gt;File.php _checkFileAccess(...)&lt;/code&gt; qui pour certaines actions sur les fichiers, agit comme une surcouche à la fonction &lt;code&gt;checkRights&lt;/code&gt; (ce qui permet entre autres des actions sur les fichiers hérités pour le tuteur et les membres).<br /> ** Cas du déplacement de fichier hérités.<br /> *** Avec l'accord d'Anthony, on a conclu que le déplacement de fichier hérité était une mauvaise idée, donc cela reste non autorisé, même pour les admins.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être supprimés.<br /> ** Les appels à la base effectuait une comparaison avec un &lt;code&gt;LIKE&lt;/code&gt; au lieu d'un &lt;code&gt;=&lt;/code&gt; dans la requête SQL, ce qui ne marchait pas dans le cas présent.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être renommés.<br /> ** Le nom du fichier est traité et enregistré par le fichier JS, qui est non typé donc il decide que si le nom n'est que des numeros, alors ce ne sera pas une string. Or pour renommer le fichier, on veux modifer la partie du nom qui est avant le point (de l'extension), donc on fait un appel à &lt;code&gt;name.lastIndexOf(&quot;.&quot;);&lt;/code&gt;, qui s'execute eclusivement sur une string. J'ai donc realisé un &lt;code&gt;.toString()&lt;/code&gt; sur le nom à chaque fois que necessaire.<br /> * Correction du fait que lorsque l'on supprimait un fichier dans un dossier, on était renvoyé à la racine du projet plutot que dans le dossier.<br /> ** Il manquait un paramètre (le dossier) à la fonction &lt;code&gt;getFiles(...)&lt;/code&gt; appalée après la suppréssion.<br /> * Transformation du bouton &quot;Ajouter&quot; en deux boutons, un pour les dossiers, un pour les fichiers.<br /> <br /> ==== Zoran ====<br /> * Mise à Jour de templates de mail (&gt;100 templates)<br /> ** Remplacement des références à Waza Education par EDCampus<br /> ** Production d'une banière et remplacement de l'ancienne<br /> * Tests des fichiers de configuration des tests unitaires<br /> * Recherches sur le passage de l'HTTP vers HTTPS avec [https://letsencrypt.org/ Let's Encrypt] : voir le [[Let's Encrypt | résumé rapide]]<br /> ** Choix d'utilisation de [https://certbot.eff.org/ Certbot]<br /> <br /> === 13/02/19 ===<br /> <br /> ==== Servan ====<br /> Nouvelle tâche assignée : Améliorer les tâches, faire en sorte que si un nom est placé sur un label d'une couleur au sein d'un projet, tous les labels de cette couleur auront ce même nom.<br /> <br /> ==== Zoran ====<br /> * Sauvegarde de la base de données de l'ancienne plateforme<br /> * Passage de l'ancienne plateforme de l'HTTP à l'HTTPS<br /> ** Réparation de la configuration d'Apache<br /> ** Génération des certificats<br /> ** Configuration d'Apache pour l'HTTPS<br /> <br /> === 14/02/19 ===<br /> <br /> ==== Servan ====<br /> * Backend corrigé, on ne peux plus créer une tache d'un nom au choix si il y a deja une tache de cette couleur avec un nom dans le projet.<br /> * Etude approfondie du front-end et du systeme evenementiel pour corriger les defauts de mise à jour.<br /> <br /> ==== Zoran ====<br /> * Recherches sur l'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Découverte et compréhension d'une [https://github.com/BirgerK/docker-apache-letsencrypt image existante]<br /> * Tentative de passage de l'HTTP à l'HTTPS dans un Docker<br /> ** Sur la VM de l'ancienne plateforme (pour ne pas briser la version en prod)<br /> ** Fusion du Dockerfile existant et du Dockerfile de l'image trouvée<br /> <br /> === 15/02/19 ===<br /> <br /> ==== Servan ====<br /> * Correction superficielle des problemes des mise a jour a de la vue du systeme de tache. Le soucis etant que les taches et le petit menu qui indique les details ne sont pas le même module et n'interagissent pas vraiment entre eux, donc on ne peux pas actualier l'un depuis l'autre.<br /> * Correction du fait que dans le systeme de fichier, on ne pouvait pas délacer un fichier/dossier vers le dossier parent en le glissant sur la flèche retour. <br /> ** Le soucis venait du fichier html, qui avait l'air correct mais la variable qu'il etait censé recuppérer renvoyait undefined au lieu de l'identifiant du dossier parent.<br /> <br /> ==== Zoran ====<br /> * Poursuite de la tentative d'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Succès de la création de certificat<br /> ** L'HTTPS ne fonctionne toujours pas (sans doute à cause de la configuration d'Apache)<br /> <br /> == Semaine 4 ==<br /> <br /> Hack ton campus.<br /> <br /> == Semaine 5 ==<br /> <br /> === 05/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug trouvé lors que hackaton qui empêchait les étudiants de télécharger un fichier hérité appartenant à un tuteur. <br /> * Début d'un travail sur les tests unitaires du backend. Le but est de vérifier les tests existants, essayer de les faire fonctionner, et s'en inspirer pour en créer d'autres et à terme, couvrir tout le code.<br /> <br /> ==== Zoran ====<br /> * Succès de la mise en place d'HTTPS dans un docker<br /> ** Modification de &lt;code&gt;docker-compose.yml&lt;/code&gt; pour lier les ports 443 de l'hôte et du conteneur<br /> ** Finalisation de la configuration d'Apache dans le conteneur<br /> <br /> === 06/03/19 ===<br /> <br /> ==== Servan et Zoran ====<br /> <br /> * Lecture de la [https://phpunit.readthedocs.io/en/8.0/ documentation de PHPUNit.]<br /> Après un travail de recherche, nous nous sommes rendu compte que PHPUnit allait être difficile à mettre en place sur le backend du projet. En effet, toutes les fonctions sont en ''static'' et il est impossible de mocker les fonctions statiques avec PHPUnit. Il faudrait donc revoir l'architecture du code pour mocker le statique, et donc remplacer les appels à la base de données par des appels simulés. Cela éviterait d'avoir à créer une base externe accessible ou construire une base dans le runner du pipeline. Cependant cela est trop long a mettre en place sachant que l'on arrive sur la fin du projet, donc nous avons donné priorité à la vitrine, suite à une réunion avec les membres de Disrupt campus. <br /> <br /> La vitrine est un endroit où le public (étudiants/professeurs/entreprises) peut consulter les projets réalisés ou en cours. Cette vitrine se décompose en un endroit ou l'on peut consulter la liste des projets d'une université, et des pages de projet individuelles avec une image, une description et les livrables.<br /> <br /> === 07/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction d'un bug en rapport avec les accents dans les noms. Lorsque qu'un utilisateur possède un accent dans son nom (ex: Amélie), au moment de la création du login la chaîne de caractère est mal interprétée et le login est tronqué au niveau de l'accent (ex: amY). L'architecture fait que lors du transfert du nom du front vers le back, l'accent est codé avec des caractères classiques, qui sont ensuite interprétés correctement lors de l'ajout en base. Mais cela veux dire que pendant tout le passage en backend on travaille avec des accents codés. Le login était créé à partir du nom et du prénom de l'utilisateur, qui peuvent donc être temporairement corrompus par des accents codés. La correction à se soucis est donc détecter la présence d'accents dans les noms, et si il y en a, créer le login à partir de la première partie de l'adresse mail de l'utilisateur (avant le @), sinon, on fait comme avant avec les noms.<br /> <br /> ==== Zoran ====<br /> * Correction d'un bug empêchant l'envoi d'e-mail lors de l'ajout d'un utilisateur à un projet<br /> * Prospection dans le code et la base de donnée pour permettre l'affichage ou non des évaluations dans le menu des projets. La section des évaluations étant gérée différemment des autres sections, ce travail nécessitera plus de temps que prévu et a donc été reporté au profit de la vitrine<br /> <br /> === 08/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Archéologie sur le prototype de vitrine.<br /> * Rédaction de documentation générale sur l'architecture End-To-End du projet (ci-dessous).<br /> <br /> [[File:EDCampus 2019 EndToEnd.png|border]]<br /> <br /> Détails de la fonction &lt;code&gt;checkRights&lt;/code&gt; :<br /> <br /> * La commande en cours est envoyée à &lt;code&gt;checkRights&lt;/code&gt; sous forme de string.<br /> * On vérifie d'abord si elle fait partie des commandes publiques, que l'on peux exécuter lorsque l'on a pas de session. (Via une comparaison avec un tableau contenant toutes les commandes publiques.)<br /> * Si ce n'est pas la cas, on récupère ensuite les informations de session et l'identifiant utilisateur.<br /> * Si on ne trouve pas d'utilisateur, on regarde si on essai d’accéder a une page publique, sinon on bloque l'accès.<br /> * On a maintenant un utilisateur avec une session, qui essaie d'agir sur une page non publique.<br /> * On vérifie si l'utilisateur est super-administrateur.<br /> * On vérifie si l'utilisateur essai d’exécuter une commande administrateur, en tant qu'administrateur.<br /> * Puisque la page est non-publique et que l'on est pas administrateur, il s'agit forcement d'une page de projet. <br /> * On vérifie si l'utilisateur est propriétaire du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est propriétaire du projet courant et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet courant et que cette commande est autorisée.<br /> * Si aucun des tests ci dessus n'a raté (ou n'a déjà accordé l'accès), on accorde l'accès.<br /> <br /> ==== Zoran ====</div>

Zoran.Chanet https://air.imag.fr/index.php?title=PROJET-INFO5_1819_EDCampus&diff=45247 2019-03-11T12:16:35Z

<p>Zoran.Chanet: /* Zoran */</p> <hr /> <div>[[File:Logo_EDCampus.png|thumb|right| Logo EDCampus]]<br /> = Le projet en quelques mots =<br /> La plateforme [[Contributions open-source au projet Eclipse EdCampus | EDCampus]] est une plateforme de gestion de projet développé par Disrupt Campus Grenoble. La plateforme est actuellement en train d’être soumis à la fondation Eclipse afin d’être mise en open source sous licence Eclipse. Dans le cadre du projet Disrupt Campus, les étudiants sont invités à contribuer à la plateforme. Dans le cadre de vos formations c’est une vraie plus value de contribuer à de réels projets plutôt qu’à des projets one-shot qui seront mis à la poubelle sitôt votre soutenance terminée. EDCampus est donc une opportunité de contribuer au logiciel libre et à la fondation Eclipse (et de s'assurer une jolie ligne sur son CV plutôt qu'un projet qui sera aussi vite oublié que l'ECOM !). <br /> <br /> = L'équipe et leurs rôles =<br /> <br /> * GEOURJON Anthony - Chef de projet (EXT)<br /> * [[User:Servan.Charlot | CHARLOT Servan]] - Chef de groupe<br /> * [[User:Zoran.Chanet | CHANET Zoran]] - Responsable DevOps<br /> <br /> = Roadmap =<br /> * '''20-22 février 2019 :''' Hack Ton Campus, la plateforme EDCampus sera utilisée pour la gestion des défis.<br /> * '''Avril 2019 :''' Projet pilote, un projet mêlant une entreprise, l'UGA et des étudiants servira de test à la plateforme.<br /> * '''Septembre 2019 :''' Mise en production globale.<br /> <br /> = Carnet de bord =<br /> <br /> == Semaine 1 ==<br /> <br /> === 28/01/19 ===<br /> <br /> Assignation du sujet [[Contributions open-source au projet Eclipse EdCampus | EDCampus]].<br /> <br /> === 29/01/19 ===<br /> <br /> * Rencontre avec Anthony au [http://fabmstic.liglab.fr/ Fablab], presentation du sujet, des enjeux, et de la roadmap<br /> * Installation du projet<br /> ** Difficultés dues au DNS des réseaux universitaires (impossible de télécharger le contenu nécessaire depuis les containers)<br /> <br /> === 30/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $scope._getProjectParent()&lt;/code&gt; qui ne marchait pas du tout. Il y avait une faute dans la plupart des variables qui s'appelaient &lt;code&gt;currentParentProject&lt;/code&gt; au lieu de &lt;code&gt;currentProjectParent&lt;/code&gt;.<br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $rootScope._checkProject()&lt;/code&gt; qui oubliait un paramètre dans son appel à &lt;code&gt;$scope._setProject()&lt;/code&gt;.<br /> <br /> ==== Zoran ====<br /> * Assignation d'une première tâche : réparer la création d'un projet indépendant<br /> * Découverte du code du projet<br /> * Poursuite de l'arborescence des appels depuis le bouton jusqu'à l'appel à la base de données<br /> <br /> === 01/02/19 ===<br /> ==== Servan ====<br /> <br /> * Assignation de la tâche consistant à réparer le système de fichier.<br /> * Exploration du systeme de fichier et son implementation.<br /> <br /> ==== Zoran ====<br /> * Production d'une méthode permettant des logs personnalisés<br /> * Recherches sur le rewriting d'URL<br /> * Correction du problème (lié au rewriting)<br /> * Production d'une fiche explicative de la solution<br /> <br /> == Semaine 2 ==<br /> <br /> === 04/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction des bugs suivants :<br /> <br /> * Affichage des fichiers du portefeuille père ssi il y a au moins un fichier présent dans le projet fils.<br /> ** Dans le backend, la fonction qui get les fichiers exécutait un &lt;code&gt;return false&lt;/code&gt; avant de get les fichiers parents dans le cas ou il n'y avait pas de fichier à la base.<br /> * N'actualise pas la liste des fichiers si on supprime le dernier fichier.<br /> * Tous les dossiers sont affichés comme des fichiers. Lors de la première sélection à la souris, si on sélectionne le fichier-dossier, il se transforme en dossier et on peut y accéder. Rien ne se passe pour les sélections suivantes.<br /> ** Dans le backend, un paramètre était traité comme chaîne de caractère alors qu'il représentait un booléen. Le résultat de ça est que l'on entrait dans la mauvaise partie d'un if, qui exécutait la mauvaise requête SQL nous privant de l'information concernant le type de fichier lu (un dossier est un type de fichier).<br /> * Le bouton qui permet de revenir en arrière, sortir du dossier ne fonctionne pas.<br /> * On ne peut pas entrer dans un dossier hérité.<br /> <br /> ==== Zoran ====<br /> * Assignation de la mise en place de techniques DevOps<br /> * Recherches sur la mise en place de pipeline dans GitLab : voir [[GitLab CI/CD | compte-rendu]]<br /> * Mise en place d'un pipeline à chaque push<br /> * Production d'un tutoriel de création de runner GitLab : voir [[GitLab Runners | tutoriel]]<br /> * Recherches sur SonarQube et les tests unitaires<br /> ** Priorisation de SonarQube<br /> <br /> === 05/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug qui faisait que lors de la suppression d'un dossier, les fichiers à l'intérieur ne sont pas supprimés (le champ statut dans le BDD ne passe pas à 0).<br /> ** La fonctionnalité de suppression récursive n'était pas implémentée dans &lt;code&gt;File.php&lt;/code&gt;.<br /> * Début de l'analyse du système de droit des utilisateurs (Administrateur/Tuteur/Elève) sur les fichiers et dossiers (hérités ou non).<br /> <br /> ==== Zoran ====<br /> * Compréhension des scanners sonar : voir [[SonarQube Scanner | compte-rendu]]<br /> * Mise en place d'un scan dans le pipeline<br /> ** Nécessité d'un serveur sonar exposé<br /> ** Décision d'utiliser SonarCloud<br /> ** Configuration du scanner pour envoyer le rapport dans le bon projet sonarcloud<br /> ** Réussite du premier scan<br /> <br /> === 06/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Suite de la correction du système de droits des fichiers/dossiers.<br /> <br /> * Correction d'un bug qui faisait que les utilisateurs ne peuvent pas entrer dans les dossiers hérites (ou télécharger les fichiers hérites).<br /> ** Le check de droit se fait dans une fonction qui check d'abord le &lt;code&gt;ownerId&lt;/code&gt;, puis le &lt;code&gt;projectId&lt;/code&gt; et puis enfin si le fichier appartient à un parent. Pour cela elle fait appel à la base pour récupérer la relation d’héritage. IL y avait une erreur de comparaison entre le résultat de la requête et les information fichier (erreur de type parce que PHP).<br /> * Analyse complète du système de droit création d'un tableau explicatif de l'état actuel et l'état voulu.<br /> [[File:EDCampus_2019_Tableau_de_droits.png|center]]<br /> * Suite au tableau, mise en place de la protection des fichiers hérités.<br /> ** Ajout d'une vérification sur le &lt;code&gt;projectId&lt;/code&gt;, empêchant les utilisateurs non propriétaires du fichier de le supprimer, renommer ou déplacer.<br /> <br /> ==== Zoran ====<br /> * Extension du scan sonar dans le pipeline à toutes les sections du projet<br /> * Affichage de badges d'état du pipeline sur la page de présentation de chaque section du projet<br /> * Reprise des recherches concernant les tests unitaires<br /> * Tentative de systématisation des tests dans le pipeline<br /> ** Difficulté : les tests nécessitent des fichiers de configurations qui ne sont pas présents sur le repository git<br /> * Recherche de contournement pour ne pas exposer des configurations privées dans le projet public<br /> <br /> === 08/02/19 ===<br /> <br /> ==== Servan ====<br /> Suppression de la vue pour les non membres et correction partielle du système de droits.<br /> * Lorsque qu'une commande est envoyée par le front-end vers le back-end, elle passe dans une fonction qui vérifie les droits (&lt;code&gt;Right.php checkRights($command)&lt;/code&gt;). La fonction compare la commande utilisée par l'utilisateur aux commandes que cet utilisateur a en général le droit d'utiliser. Le problème était que le tableau de commandes au sein de la fonction (permettant la comparaison) contenait des commandes mal formatées. J'ai donc corrigé celle qui m'intéressais pour empêcher les non membres d'un projet à consulter les fichiers, et j'en ai profiter pour corriger toutes les autres.<br /> <br /> ==== Zoran ====<br /> * Configuration des scanners sonar dans le pipeline (redirection vers une branche du projet sonarcloud nommée selon la branche GitLab sur laquelle le pipeline est lancé)<br /> * Aide à la correction du système de droits<br /> * Réalisation de tâches mineures importantes pour le Hackaton<br /> ** Retirer la vidéo Waza de l'accueil de la plateforme<br /> ** Redirection de l'utilisateur vers la plateforme lorsqu'il accède à l'url du dossier : [[Apache mod_rewrite]]<br /> ** Correction de l'url donné lors de l'appel au service de mails pour la validation de compte<br /> <br /> == Semaine 3 ==<br /> <br /> === 12/02/19 ===<br /> <br /> ==== Servan ====<br /> * Systeme de droits entierement corrigé pour le cas des fichiers.<br /> ** Privilèges administrateurs.<br /> *** Dans la fonction qui verifie les droits &lt;code&gt;Right.php checkRights($command)&lt;/code&gt;, le cas de l'administrateur n'était pas vraiment traité. Il y avait un verification pour empecher tout utilisateur non administrateur d'executer une commande administrateur, mais sinon l'administrateur était traité comme un utilisateur lambda. J'ai donc ajouté un test permettant de donner les pleins pouvoirs. Presque. Il fallait aussi ajouter un test dans la fonction &lt;code&gt;File.php _checkFileAccess(...)&lt;/code&gt; qui pour certaines actions sur les fichiers, agit comme une surcouche à la fonction &lt;code&gt;checkRights&lt;/code&gt; (ce qui permet entre autres des actions sur les fichiers hérités pour le tuteur et les membres).<br /> ** Cas du déplacement de fichier hérités.<br /> *** Avec l'accord d'Anthony, on a conclu que le déplacement de fichier hérité était une mauvaise idée, donc cela reste non autorisé, même pour les admins.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être supprimés.<br /> ** Les appels à la base effectuait une comparaison avec un &lt;code&gt;LIKE&lt;/code&gt; au lieu d'un &lt;code&gt;=&lt;/code&gt; dans la requête SQL, ce qui ne marchait pas dans le cas présent.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être renommés.<br /> ** Le nom du fichier est traité et enregistré par le fichier JS, qui est non typé donc il decide que si le nom n'est que des numeros, alors ce ne sera pas une string. Or pour renommer le fichier, on veux modifer la partie du nom qui est avant le point (de l'extension), donc on fait un appel à &lt;code&gt;name.lastIndexOf(&quot;.&quot;);&lt;/code&gt;, qui s'execute eclusivement sur une string. J'ai donc realisé un &lt;code&gt;.toString()&lt;/code&gt; sur le nom à chaque fois que necessaire.<br /> * Correction du fait que lorsque l'on supprimait un fichier dans un dossier, on était renvoyé à la racine du projet plutot que dans le dossier.<br /> ** Il manquait un paramètre (le dossier) à la fonction &lt;code&gt;getFiles(...)&lt;/code&gt; appalée après la suppréssion.<br /> * Transformation du bouton &quot;Ajouter&quot; en deux boutons, un pour les dossiers, un pour les fichiers.<br /> <br /> ==== Zoran ====<br /> * Mise à Jour de templates de mail (&gt;100 templates)<br /> ** Remplacement des références à Waza Education par EDCampus<br /> ** Production d'une banière et remplacement de l'ancienne<br /> * Tests des fichiers de configuration des tests unitaires<br /> * Recherches sur le passage de l'HTTP vers HTTPS avec [https://letsencrypt.org/ Let's Encrypt] : voir le [[Let's Encrypt | résumé rapide]]<br /> ** Choix d'utilisation de [https://certbot.eff.org/ Certbot]<br /> <br /> === 13/02/19 ===<br /> <br /> ==== Servan ====<br /> Nouvelle tâche assignée : Améliorer les tâches, faire en sorte que si un nom est placé sur un label d'une couleur au sein d'un projet, tous les labels de cette couleur auront ce même nom.<br /> <br /> ==== Zoran ====<br /> * Sauvegarde de la base de données de l'ancienne plateforme<br /> * Passage de l'ancienne plateforme de l'HTTP à l'HTTPS<br /> ** Réparation de la configuration d'Apache<br /> ** Génération des certificats<br /> ** Configuration d'Apache pour l'HTTPS<br /> <br /> === 14/02/19 ===<br /> <br /> ==== Servan ====<br /> * Backend corrigé, on ne peux plus créer une tache d'un nom au choix si il y a deja une tache de cette couleur avec un nom dans le projet.<br /> * Etude approfondie du front-end et du systeme evenementiel pour corriger les defauts de mise à jour.<br /> <br /> ==== Zoran ====<br /> * Recherches sur l'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Découverte et compréhension d'une [https://github.com/BirgerK/docker-apache-letsencrypt image existante]<br /> * Tentative de passage de l'HTTP à l'HTTPS dans un Docker<br /> ** Sur la VM de l'ancienne plateforme (pour ne pas briser la version en prod)<br /> ** Fusion du Dockerfile existant et du Dockerfile de l'image trouvée<br /> <br /> === 15/02/19 ===<br /> <br /> ==== Servan ====<br /> * Correction superficielle des problemes des mise a jour a de la vue du systeme de tache. Le soucis etant que les taches et le petit menu qui indique les details ne sont pas le même module et n'interagissent pas vraiment entre eux, donc on ne peux pas actualier l'un depuis l'autre.<br /> * Correction du fait que dans le systeme de fichier, on ne pouvait pas délacer un fichier/dossier vers le dossier parent en le glissant sur la flèche retour. <br /> ** Le soucis venait du fichier html, qui avait l'air correct mais la variable qu'il etait censé recuppérer renvoyait undefined au lieu de l'identifiant du dossier parent.<br /> <br /> ==== Zoran ====<br /> * Poursuite de la tentative d'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Succès de la création de certificat<br /> ** L'HTTPS ne fonctionne toujours pas (sans doute à cause de la configuration d'Apache)<br /> <br /> == Semaine 4 ==<br /> <br /> Hack ton campus.<br /> <br /> == Semaine 5 ==<br /> <br /> === 05/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug trouvé lors que hackaton qui empêchait les étudiants de télécharger un fichier hérité appartenant à un tuteur. <br /> * Début d'un travail sur les tests unitaires du backend. Le but est de vérifier les tests existants, essayer de les faire fonctionner, et s'en inspirer pour en créer d'autres et à terme, couvrir tout le code.<br /> <br /> ==== Zoran ====<br /> * Succès de la mise en place d'HTTPS dans un docker<br /> ** Modification de &lt;code&gt;docker-compose.yml&lt;/code&gt; pour lier les ports 443 de l'hôte et du conteneur<br /> ** Finalisation de la configuration d'Apache dans le conteneur<br /> <br /> === 06/03/19 ===<br /> <br /> ==== Servan et Zoran ====<br /> <br /> * Lecture de la [https://phpunit.readthedocs.io/en/8.0/ documentation de PHPUNit.]<br /> Après un travail de recherche, nous nous sommes rendu compte que PHPUnit allait être difficile à mettre en place sur le backend du projet. En effet, toutes les fonctions sont en ''static'' et il est impossible de mocker les fonctions statiques avec PHPUnit. Il faudrait donc revoir l'architecture du code pour mocker le statique, et donc remplacer les appels à la base de données par des appels simulés. Cela éviterait d'avoir à créer une base externe accessible ou construire une base dans le runner du pipeline. Cependant cela est trop long a mettre en place sachant que l'on arrive sur la fin du projet, donc nous avons donné priorité à la vitrine, suite à une réunion avec les membres de Disrupt campus. <br /> <br /> La vitrine est un endroit où le public (étudiants/professeurs/entreprises) peut consulter les projets réalisés ou en cours. Cette vitrine se décompose en un endroit ou l'on peut consulter la liste des projets d'une université, et des pages de projet individuelles avec une image, une description et les livrables.<br /> <br /> === 07/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction d'un bug en rapport avec les accents dans les noms. Lorsque qu'un utilisateur possède un accent dans son nom (ex: Amélie), au moment de la création du login la chaîne de caractère est mal interprétée et le login est tronqué au niveau de l'accent (ex: amY). L'architecture fait que lors du transfert du nom du front vers le back, l'accent est codé avec des caractères classiques, qui sont ensuite interprétés correctement lors de l'ajout en base. Mais cela veux dire que pendant tout le passage en backend on travaille avec des accents codés. Le login était créé à partir du nom et du prénom de l'utilisateur, qui peuvent donc être temporairement corrompus par des accents codés. La correction à se soucis est donc détecter la présence d'accents dans les noms, et si il y en a, créer le login à partir de la première partie de l'adresse mail de l'utilisateur (avant le @), sinon, on fait comme avant avec les noms.<br /> <br /> ==== Zoran ====<br /> * Correction d'un bug empêchant l'envoi d'e-mail lors de l'ajout d'un utilisateur à un projet.<br /> * Prospection dans le code et la base de donnée pour permettre l'affichage ou non des évaluations dans le menu des projets. La section des évaluations étant gérée différemment des autres sections, ce travail nécessitera plus de temps que prévu et a donc été reporté au profit de la vitrine.<br /> <br /> === 08/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Archéologie sur le prototype de vitrine.<br /> * Rédaction de documentation générale sur l'architecture End-To-End du projet (ci-dessous).<br /> <br /> [[File:EDCampus 2019 EndToEnd.png|border]]<br /> <br /> Détails de la fonction &lt;code&gt;checkRights&lt;/code&gt; :<br /> <br /> * La commande en cours est envoyée à &lt;code&gt;checkRights&lt;/code&gt; sous forme de string.<br /> * On vérifie d'abord si elle fait partie des commandes publiques, que l'on peux exécuter lorsque l'on a pas de session. (Via une comparaison avec un tableau contenant toutes les commandes publiques.)<br /> * Si ce n'est pas la cas, on récupère ensuite les informations de session et l'identifiant utilisateur.<br /> * Si on ne trouve pas d'utilisateur, on regarde si on essai d’accéder a une page publique, sinon on bloque l'accès.<br /> * On a maintenant un utilisateur avec une session, qui essaie d'agir sur une page non publique.<br /> * On vérifie si l'utilisateur est super-administrateur.<br /> * On vérifie si l'utilisateur essai d’exécuter une commande administrateur, en tant qu'administrateur.<br /> * Puisque la page est non-publique et que l'on est pas administrateur, il s'agit forcement d'une page de projet. <br /> * On vérifie si l'utilisateur est propriétaire du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est propriétaire du projet courant et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet courant et que cette commande est autorisée.<br /> * Si aucun des tests ci dessus n'a raté (ou n'a déjà accordé l'accès), on accorde l'accès.<br /> <br /> ==== Zoran ====</div>

Zoran.Chanet https://air.imag.fr/index.php?title=PROJET-INFO5_1819_EDCampus&diff=45245 2019-03-11T12:12:43Z

<p>Zoran.Chanet: /* Servan et Zoran */</p> <hr /> <div>[[File:Logo_EDCampus.png|thumb|right| Logo EDCampus]]<br /> = Le projet en quelques mots =<br /> La plateforme [[Contributions open-source au projet Eclipse EdCampus | EDCampus]] est une plateforme de gestion de projet développé par Disrupt Campus Grenoble. La plateforme est actuellement en train d’être soumis à la fondation Eclipse afin d’être mise en open source sous licence Eclipse. Dans le cadre du projet Disrupt Campus, les étudiants sont invités à contribuer à la plateforme. Dans le cadre de vos formations c’est une vraie plus value de contribuer à de réels projets plutôt qu’à des projets one-shot qui seront mis à la poubelle sitôt votre soutenance terminée. EDCampus est donc une opportunité de contribuer au logiciel libre et à la fondation Eclipse (et de s'assurer une jolie ligne sur son CV plutôt qu'un projet qui sera aussi vite oublié que l'ECOM !). <br /> <br /> = L'équipe et leurs rôles =<br /> <br /> * GEOURJON Anthony - Chef de projet (EXT)<br /> * [[User:Servan.Charlot | CHARLOT Servan]] - Chef de groupe<br /> * [[User:Zoran.Chanet | CHANET Zoran]] - Responsable DevOps<br /> <br /> = Roadmap =<br /> * '''20-22 février 2019 :''' Hack Ton Campus, la plateforme EDCampus sera utilisée pour la gestion des défis.<br /> * '''Avril 2019 :''' Projet pilote, un projet mêlant une entreprise, l'UGA et des étudiants servira de test à la plateforme.<br /> * '''Septembre 2019 :''' Mise en production globale.<br /> <br /> = Carnet de bord =<br /> <br /> == Semaine 1 ==<br /> <br /> === 28/01/19 ===<br /> <br /> Assignation du sujet [[Contributions open-source au projet Eclipse EdCampus | EDCampus]].<br /> <br /> === 29/01/19 ===<br /> <br /> * Rencontre avec Anthony au [http://fabmstic.liglab.fr/ Fablab], presentation du sujet, des enjeux, et de la roadmap<br /> * Installation du projet<br /> ** Difficultés dues au DNS des réseaux universitaires (impossible de télécharger le contenu nécessaire depuis les containers)<br /> <br /> === 30/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $scope._getProjectParent()&lt;/code&gt; qui ne marchait pas du tout. Il y avait une faute dans la plupart des variables qui s'appelaient &lt;code&gt;currentParentProject&lt;/code&gt; au lieu de &lt;code&gt;currentProjectParent&lt;/code&gt;.<br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $rootScope._checkProject()&lt;/code&gt; qui oubliait un paramètre dans son appel à &lt;code&gt;$scope._setProject()&lt;/code&gt;.<br /> <br /> ==== Zoran ====<br /> * Assignation d'une première tâche : réparer la création d'un projet indépendant<br /> * Découverte du code du projet<br /> * Poursuite de l'arborescence des appels depuis le bouton jusqu'à l'appel à la base de données<br /> <br /> === 01/02/19 ===<br /> ==== Servan ====<br /> <br /> * Assignation de la tâche consistant à réparer le système de fichier.<br /> * Exploration du systeme de fichier et son implementation.<br /> <br /> ==== Zoran ====<br /> * Production d'une méthode permettant des logs personnalisés<br /> * Recherches sur le rewriting d'URL<br /> * Correction du problème (lié au rewriting)<br /> * Production d'une fiche explicative de la solution<br /> <br /> == Semaine 2 ==<br /> <br /> === 04/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction des bugs suivants :<br /> <br /> * Affichage des fichiers du portefeuille père ssi il y a au moins un fichier présent dans le projet fils.<br /> ** Dans le backend, la fonction qui get les fichiers exécutait un &lt;code&gt;return false&lt;/code&gt; avant de get les fichiers parents dans le cas ou il n'y avait pas de fichier à la base.<br /> * N'actualise pas la liste des fichiers si on supprime le dernier fichier.<br /> * Tous les dossiers sont affichés comme des fichiers. Lors de la première sélection à la souris, si on sélectionne le fichier-dossier, il se transforme en dossier et on peut y accéder. Rien ne se passe pour les sélections suivantes.<br /> ** Dans le backend, un paramètre était traité comme chaîne de caractère alors qu'il représentait un booléen. Le résultat de ça est que l'on entrait dans la mauvaise partie d'un if, qui exécutait la mauvaise requête SQL nous privant de l'information concernant le type de fichier lu (un dossier est un type de fichier).<br /> * Le bouton qui permet de revenir en arrière, sortir du dossier ne fonctionne pas.<br /> * On ne peut pas entrer dans un dossier hérité.<br /> <br /> ==== Zoran ====<br /> * Assignation de la mise en place de techniques DevOps<br /> * Recherches sur la mise en place de pipeline dans GitLab : voir [[GitLab CI/CD | compte-rendu]]<br /> * Mise en place d'un pipeline à chaque push<br /> * Production d'un tutoriel de création de runner GitLab : voir [[GitLab Runners | tutoriel]]<br /> * Recherches sur SonarQube et les tests unitaires<br /> ** Priorisation de SonarQube<br /> <br /> === 05/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug qui faisait que lors de la suppression d'un dossier, les fichiers à l'intérieur ne sont pas supprimés (le champ statut dans le BDD ne passe pas à 0).<br /> ** La fonctionnalité de suppression récursive n'était pas implémentée dans &lt;code&gt;File.php&lt;/code&gt;.<br /> * Début de l'analyse du système de droit des utilisateurs (Administrateur/Tuteur/Elève) sur les fichiers et dossiers (hérités ou non).<br /> <br /> ==== Zoran ====<br /> * Compréhension des scanners sonar : voir [[SonarQube Scanner | compte-rendu]]<br /> * Mise en place d'un scan dans le pipeline<br /> ** Nécessité d'un serveur sonar exposé<br /> ** Décision d'utiliser SonarCloud<br /> ** Configuration du scanner pour envoyer le rapport dans le bon projet sonarcloud<br /> ** Réussite du premier scan<br /> <br /> === 06/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Suite de la correction du système de droits des fichiers/dossiers.<br /> <br /> * Correction d'un bug qui faisait que les utilisateurs ne peuvent pas entrer dans les dossiers hérites (ou télécharger les fichiers hérites).<br /> ** Le check de droit se fait dans une fonction qui check d'abord le &lt;code&gt;ownerId&lt;/code&gt;, puis le &lt;code&gt;projectId&lt;/code&gt; et puis enfin si le fichier appartient à un parent. Pour cela elle fait appel à la base pour récupérer la relation d’héritage. IL y avait une erreur de comparaison entre le résultat de la requête et les information fichier (erreur de type parce que PHP).<br /> * Analyse complète du système de droit création d'un tableau explicatif de l'état actuel et l'état voulu.<br /> [[File:EDCampus_2019_Tableau_de_droits.png|center]]<br /> * Suite au tableau, mise en place de la protection des fichiers hérités.<br /> ** Ajout d'une vérification sur le &lt;code&gt;projectId&lt;/code&gt;, empêchant les utilisateurs non propriétaires du fichier de le supprimer, renommer ou déplacer.<br /> <br /> ==== Zoran ====<br /> * Extension du scan sonar dans le pipeline à toutes les sections du projet<br /> * Affichage de badges d'état du pipeline sur la page de présentation de chaque section du projet<br /> * Reprise des recherches concernant les tests unitaires<br /> * Tentative de systématisation des tests dans le pipeline<br /> ** Difficulté : les tests nécessitent des fichiers de configurations qui ne sont pas présents sur le repository git<br /> * Recherche de contournement pour ne pas exposer des configurations privées dans le projet public<br /> <br /> === 08/02/19 ===<br /> <br /> ==== Servan ====<br /> Suppression de la vue pour les non membres et correction partielle du système de droits.<br /> * Lorsque qu'une commande est envoyée par le front-end vers le back-end, elle passe dans une fonction qui vérifie les droits (&lt;code&gt;Right.php checkRights($command)&lt;/code&gt;). La fonction compare la commande utilisée par l'utilisateur aux commandes que cet utilisateur a en général le droit d'utiliser. Le problème était que le tableau de commandes au sein de la fonction (permettant la comparaison) contenait des commandes mal formatées. J'ai donc corrigé celle qui m'intéressais pour empêcher les non membres d'un projet à consulter les fichiers, et j'en ai profiter pour corriger toutes les autres.<br /> <br /> ==== Zoran ====<br /> * Configuration des scanners sonar dans le pipeline (redirection vers une branche du projet sonarcloud nommée selon la branche GitLab sur laquelle le pipeline est lancé)<br /> * Aide à la correction du système de droits<br /> * Réalisation de tâches mineures importantes pour le Hackaton<br /> ** Retirer la vidéo Waza de l'accueil de la plateforme<br /> ** Redirection de l'utilisateur vers la plateforme lorsqu'il accède à l'url du dossier : [[Apache mod_rewrite]]<br /> ** Correction de l'url donné lors de l'appel au service de mails pour la validation de compte<br /> <br /> == Semaine 3 ==<br /> <br /> === 12/02/19 ===<br /> <br /> ==== Servan ====<br /> * Systeme de droits entierement corrigé pour le cas des fichiers.<br /> ** Privilèges administrateurs.<br /> *** Dans la fonction qui verifie les droits &lt;code&gt;Right.php checkRights($command)&lt;/code&gt;, le cas de l'administrateur n'était pas vraiment traité. Il y avait un verification pour empecher tout utilisateur non administrateur d'executer une commande administrateur, mais sinon l'administrateur était traité comme un utilisateur lambda. J'ai donc ajouté un test permettant de donner les pleins pouvoirs. Presque. Il fallait aussi ajouter un test dans la fonction &lt;code&gt;File.php _checkFileAccess(...)&lt;/code&gt; qui pour certaines actions sur les fichiers, agit comme une surcouche à la fonction &lt;code&gt;checkRights&lt;/code&gt; (ce qui permet entre autres des actions sur les fichiers hérités pour le tuteur et les membres).<br /> ** Cas du déplacement de fichier hérités.<br /> *** Avec l'accord d'Anthony, on a conclu que le déplacement de fichier hérité était une mauvaise idée, donc cela reste non autorisé, même pour les admins.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être supprimés.<br /> ** Les appels à la base effectuait une comparaison avec un &lt;code&gt;LIKE&lt;/code&gt; au lieu d'un &lt;code&gt;=&lt;/code&gt; dans la requête SQL, ce qui ne marchait pas dans le cas présent.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être renommés.<br /> ** Le nom du fichier est traité et enregistré par le fichier JS, qui est non typé donc il decide que si le nom n'est que des numeros, alors ce ne sera pas une string. Or pour renommer le fichier, on veux modifer la partie du nom qui est avant le point (de l'extension), donc on fait un appel à &lt;code&gt;name.lastIndexOf(&quot;.&quot;);&lt;/code&gt;, qui s'execute eclusivement sur une string. J'ai donc realisé un &lt;code&gt;.toString()&lt;/code&gt; sur le nom à chaque fois que necessaire.<br /> * Correction du fait que lorsque l'on supprimait un fichier dans un dossier, on était renvoyé à la racine du projet plutot que dans le dossier.<br /> ** Il manquait un paramètre (le dossier) à la fonction &lt;code&gt;getFiles(...)&lt;/code&gt; appalée après la suppréssion.<br /> * Transformation du bouton &quot;Ajouter&quot; en deux boutons, un pour les dossiers, un pour les fichiers.<br /> <br /> ==== Zoran ====<br /> * Mise à Jour de templates de mail (&gt;100 templates)<br /> ** Remplacement des références à Waza Education par EDCampus<br /> ** Production d'une banière et remplacement de l'ancienne<br /> * Tests des fichiers de configuration des tests unitaires<br /> * Recherches sur le passage de l'HTTP vers HTTPS avec [https://letsencrypt.org/ Let's Encrypt] : voir le [[Let's Encrypt | résumé rapide]]<br /> ** Choix d'utilisation de [https://certbot.eff.org/ Certbot]<br /> <br /> === 13/02/19 ===<br /> <br /> ==== Servan ====<br /> Nouvelle tâche assignée : Améliorer les tâches, faire en sorte que si un nom est placé sur un label d'une couleur au sein d'un projet, tous les labels de cette couleur auront ce même nom.<br /> <br /> ==== Zoran ====<br /> * Sauvegarde de la base de données de l'ancienne plateforme<br /> * Passage de l'ancienne plateforme de l'HTTP à l'HTTPS<br /> ** Réparation de la configuration d'Apache<br /> ** Génération des certificats<br /> ** Configuration d'Apache pour l'HTTPS<br /> <br /> === 14/02/19 ===<br /> <br /> ==== Servan ====<br /> * Backend corrigé, on ne peux plus créer une tache d'un nom au choix si il y a deja une tache de cette couleur avec un nom dans le projet.<br /> * Etude approfondie du front-end et du systeme evenementiel pour corriger les defauts de mise à jour.<br /> <br /> ==== Zoran ====<br /> * Recherches sur l'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Découverte et compréhension d'une [https://github.com/BirgerK/docker-apache-letsencrypt image existante]<br /> * Tentative de passage de l'HTTP à l'HTTPS dans un Docker<br /> ** Sur la VM de l'ancienne plateforme (pour ne pas briser la version en prod)<br /> ** Fusion du Dockerfile existant et du Dockerfile de l'image trouvée<br /> <br /> === 15/02/19 ===<br /> <br /> ==== Servan ====<br /> * Correction superficielle des problemes des mise a jour a de la vue du systeme de tache. Le soucis etant que les taches et le petit menu qui indique les details ne sont pas le même module et n'interagissent pas vraiment entre eux, donc on ne peux pas actualier l'un depuis l'autre.<br /> * Correction du fait que dans le systeme de fichier, on ne pouvait pas délacer un fichier/dossier vers le dossier parent en le glissant sur la flèche retour. <br /> ** Le soucis venait du fichier html, qui avait l'air correct mais la variable qu'il etait censé recuppérer renvoyait undefined au lieu de l'identifiant du dossier parent.<br /> <br /> ==== Zoran ====<br /> * Poursuite de la tentative d'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Succès de la création de certificat<br /> ** L'HTTPS ne fonctionne toujours pas (sans doute à cause de la configuration d'Apache)<br /> <br /> == Semaine 4 ==<br /> <br /> Hack ton campus.<br /> <br /> == Semaine 5 ==<br /> <br /> === 05/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug trouvé lors que hackaton qui empêchait les étudiants de télécharger un fichier hérité appartenant à un tuteur. <br /> * Début d'un travail sur les tests unitaires du backend. Le but est de vérifier les tests existants, essayer de les faire fonctionner, et s'en inspirer pour en créer d'autres et à terme, couvrir tout le code.<br /> <br /> ==== Zoran ====<br /> * Succès de la mise en place d'HTTPS dans un docker<br /> ** Modification de &lt;code&gt;docker-compose.yml&lt;/code&gt; pour lier les ports 443 de l'hôte et du conteneur<br /> ** Finalisation de la configuration d'Apache dans le conteneur<br /> <br /> === 06/03/19 ===<br /> <br /> ==== Servan et Zoran ====<br /> <br /> * Lecture de la [https://phpunit.readthedocs.io/en/8.0/ documentation de PHPUNit.]<br /> Après un travail de recherche, nous nous sommes rendu compte que PHPUnit allait être difficile à mettre en place sur le backend du projet. En effet, toutes les fonctions sont en ''static'' et il est impossible de mocker les fonctions statiques avec PHPUnit. Il faudrait donc revoir l'architecture du code pour mocker le statique, et donc remplacer les appels à la base de données par des appels simulés. Cela éviterait d'avoir à créer une base externe accessible ou construire une base dans le runner du pipeline. Cependant cela est trop long a mettre en place sachant que l'on arrive sur la fin du projet, donc nous avons donné priorité à la vitrine, suite à une réunion avec les membres de Disrupt campus. <br /> <br /> La vitrine est un endroit où le public (étudiants/professeurs/entreprises) peut consulter les projets réalisés ou en cours. Cette vitrine se décompose en un endroit ou l'on peut consulter la liste des projets d'une université, et des pages de projet individuelles avec une image, une description et les livrables.<br /> <br /> === 07/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====<br /> <br /> === 08/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Archéologie sur le prototype de vitrine.<br /> * Rédaction de documentation générale sur l'architecture End-To-End du projet (ci-dessous).<br /> <br /> [[File:EDCampus 2019 EndToEnd.png|border]]<br /> <br /> Détails de la fonction &lt;code&gt;checkRights&lt;/code&gt; :<br /> <br /> * La commande en cours est envoyée à &lt;code&gt;checkRights&lt;/code&gt; sous forme de string.<br /> * On vérifie d'abord si elle fait partie des commandes publiques, que l'on peux exécuter lorsque l'on a pas de session. (Via une comparaison avec un tableau contenant toutes les commandes publiques.)<br /> * Si ce n'est pas la cas, on récupère ensuite les informations de session et l'identifiant utilisateur.<br /> * Si on ne trouve pas d'utilisateur, on regarde si on essai d’accéder a une page publique, sinon on bloque l'accès.<br /> * On a maintenant un utilisateur avec une session, qui essaie d'agir sur une page non publique.<br /> * On vérifie si l'utilisateur est super-administrateur.<br /> * On vérifie si l'utilisateur essai d’exécuter une commande administrateur, en tant qu'administrateur.<br /> * Puisque la page est non-publique et que l'on est pas administrateur, il s'agit forcement d'une page de projet. <br /> * On vérifie si l'utilisateur est propriétaire du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est propriétaire du projet courant et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet courant et que cette commande est autorisée.<br /> * Si aucun des tests ci dessus n'a raté (ou n'a déjà accordé l'accès), on accorde l'accès.<br /> <br /> ==== Zoran ====</div>

Zoran.Chanet https://air.imag.fr/index.php?title=PROJET-INFO5_1819_EDCampus&diff=45244 2019-03-11T12:09:07Z

<p>Zoran.Chanet: /* Zoran */</p> <hr /> <div>[[File:Logo_EDCampus.png|thumb|right| Logo EDCampus]]<br /> = Le projet en quelques mots =<br /> La plateforme [[Contributions open-source au projet Eclipse EdCampus | EDCampus]] est une plateforme de gestion de projet développé par Disrupt Campus Grenoble. La plateforme est actuellement en train d’être soumis à la fondation Eclipse afin d’être mise en open source sous licence Eclipse. Dans le cadre du projet Disrupt Campus, les étudiants sont invités à contribuer à la plateforme. Dans le cadre de vos formations c’est une vraie plus value de contribuer à de réels projets plutôt qu’à des projets one-shot qui seront mis à la poubelle sitôt votre soutenance terminée. EDCampus est donc une opportunité de contribuer au logiciel libre et à la fondation Eclipse (et de s'assurer une jolie ligne sur son CV plutôt qu'un projet qui sera aussi vite oublié que l'ECOM !). <br /> <br /> = L'équipe et leurs rôles =<br /> <br /> * GEOURJON Anthony - Chef de projet (EXT)<br /> * [[User:Servan.Charlot | CHARLOT Servan]] - Chef de groupe<br /> * [[User:Zoran.Chanet | CHANET Zoran]] - Responsable DevOps<br /> <br /> = Roadmap =<br /> * '''20-22 février 2019 :''' Hack Ton Campus, la plateforme EDCampus sera utilisée pour la gestion des défis.<br /> * '''Avril 2019 :''' Projet pilote, un projet mêlant une entreprise, l'UGA et des étudiants servira de test à la plateforme.<br /> * '''Septembre 2019 :''' Mise en production globale.<br /> <br /> = Carnet de bord =<br /> <br /> == Semaine 1 ==<br /> <br /> === 28/01/19 ===<br /> <br /> Assignation du sujet [[Contributions open-source au projet Eclipse EdCampus | EDCampus]].<br /> <br /> === 29/01/19 ===<br /> <br /> * Rencontre avec Anthony au [http://fabmstic.liglab.fr/ Fablab], presentation du sujet, des enjeux, et de la roadmap<br /> * Installation du projet<br /> ** Difficultés dues au DNS des réseaux universitaires (impossible de télécharger le contenu nécessaire depuis les containers)<br /> <br /> === 30/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $scope._getProjectParent()&lt;/code&gt; qui ne marchait pas du tout. Il y avait une faute dans la plupart des variables qui s'appelaient &lt;code&gt;currentParentProject&lt;/code&gt; au lieu de &lt;code&gt;currentProjectParent&lt;/code&gt;.<br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $rootScope._checkProject()&lt;/code&gt; qui oubliait un paramètre dans son appel à &lt;code&gt;$scope._setProject()&lt;/code&gt;.<br /> <br /> ==== Zoran ====<br /> * Assignation d'une première tâche : réparer la création d'un projet indépendant<br /> * Découverte du code du projet<br /> * Poursuite de l'arborescence des appels depuis le bouton jusqu'à l'appel à la base de données<br /> <br /> === 01/02/19 ===<br /> ==== Servan ====<br /> <br /> * Assignation de la tâche consistant à réparer le système de fichier.<br /> * Exploration du systeme de fichier et son implementation.<br /> <br /> ==== Zoran ====<br /> * Production d'une méthode permettant des logs personnalisés<br /> * Recherches sur le rewriting d'URL<br /> * Correction du problème (lié au rewriting)<br /> * Production d'une fiche explicative de la solution<br /> <br /> == Semaine 2 ==<br /> <br /> === 04/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction des bugs suivants :<br /> <br /> * Affichage des fichiers du portefeuille père ssi il y a au moins un fichier présent dans le projet fils.<br /> ** Dans le backend, la fonction qui get les fichiers exécutait un &lt;code&gt;return false&lt;/code&gt; avant de get les fichiers parents dans le cas ou il n'y avait pas de fichier à la base.<br /> * N'actualise pas la liste des fichiers si on supprime le dernier fichier.<br /> * Tous les dossiers sont affichés comme des fichiers. Lors de la première sélection à la souris, si on sélectionne le fichier-dossier, il se transforme en dossier et on peut y accéder. Rien ne se passe pour les sélections suivantes.<br /> ** Dans le backend, un paramètre était traité comme chaîne de caractère alors qu'il représentait un booléen. Le résultat de ça est que l'on entrait dans la mauvaise partie d'un if, qui exécutait la mauvaise requête SQL nous privant de l'information concernant le type de fichier lu (un dossier est un type de fichier).<br /> * Le bouton qui permet de revenir en arrière, sortir du dossier ne fonctionne pas.<br /> * On ne peut pas entrer dans un dossier hérité.<br /> <br /> ==== Zoran ====<br /> * Assignation de la mise en place de techniques DevOps<br /> * Recherches sur la mise en place de pipeline dans GitLab : voir [[GitLab CI/CD | compte-rendu]]<br /> * Mise en place d'un pipeline à chaque push<br /> * Production d'un tutoriel de création de runner GitLab : voir [[GitLab Runners | tutoriel]]<br /> * Recherches sur SonarQube et les tests unitaires<br /> ** Priorisation de SonarQube<br /> <br /> === 05/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug qui faisait que lors de la suppression d'un dossier, les fichiers à l'intérieur ne sont pas supprimés (le champ statut dans le BDD ne passe pas à 0).<br /> ** La fonctionnalité de suppression récursive n'était pas implémentée dans &lt;code&gt;File.php&lt;/code&gt;.<br /> * Début de l'analyse du système de droit des utilisateurs (Administrateur/Tuteur/Elève) sur les fichiers et dossiers (hérités ou non).<br /> <br /> ==== Zoran ====<br /> * Compréhension des scanners sonar : voir [[SonarQube Scanner | compte-rendu]]<br /> * Mise en place d'un scan dans le pipeline<br /> ** Nécessité d'un serveur sonar exposé<br /> ** Décision d'utiliser SonarCloud<br /> ** Configuration du scanner pour envoyer le rapport dans le bon projet sonarcloud<br /> ** Réussite du premier scan<br /> <br /> === 06/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Suite de la correction du système de droits des fichiers/dossiers.<br /> <br /> * Correction d'un bug qui faisait que les utilisateurs ne peuvent pas entrer dans les dossiers hérites (ou télécharger les fichiers hérites).<br /> ** Le check de droit se fait dans une fonction qui check d'abord le &lt;code&gt;ownerId&lt;/code&gt;, puis le &lt;code&gt;projectId&lt;/code&gt; et puis enfin si le fichier appartient à un parent. Pour cela elle fait appel à la base pour récupérer la relation d’héritage. IL y avait une erreur de comparaison entre le résultat de la requête et les information fichier (erreur de type parce que PHP).<br /> * Analyse complète du système de droit création d'un tableau explicatif de l'état actuel et l'état voulu.<br /> [[File:EDCampus_2019_Tableau_de_droits.png|center]]<br /> * Suite au tableau, mise en place de la protection des fichiers hérités.<br /> ** Ajout d'une vérification sur le &lt;code&gt;projectId&lt;/code&gt;, empêchant les utilisateurs non propriétaires du fichier de le supprimer, renommer ou déplacer.<br /> <br /> ==== Zoran ====<br /> * Extension du scan sonar dans le pipeline à toutes les sections du projet<br /> * Affichage de badges d'état du pipeline sur la page de présentation de chaque section du projet<br /> * Reprise des recherches concernant les tests unitaires<br /> * Tentative de systématisation des tests dans le pipeline<br /> ** Difficulté : les tests nécessitent des fichiers de configurations qui ne sont pas présents sur le repository git<br /> * Recherche de contournement pour ne pas exposer des configurations privées dans le projet public<br /> <br /> === 08/02/19 ===<br /> <br /> ==== Servan ====<br /> Suppression de la vue pour les non membres et correction partielle du système de droits.<br /> * Lorsque qu'une commande est envoyée par le front-end vers le back-end, elle passe dans une fonction qui vérifie les droits (&lt;code&gt;Right.php checkRights($command)&lt;/code&gt;). La fonction compare la commande utilisée par l'utilisateur aux commandes que cet utilisateur a en général le droit d'utiliser. Le problème était que le tableau de commandes au sein de la fonction (permettant la comparaison) contenait des commandes mal formatées. J'ai donc corrigé celle qui m'intéressais pour empêcher les non membres d'un projet à consulter les fichiers, et j'en ai profiter pour corriger toutes les autres.<br /> <br /> ==== Zoran ====<br /> * Configuration des scanners sonar dans le pipeline (redirection vers une branche du projet sonarcloud nommée selon la branche GitLab sur laquelle le pipeline est lancé)<br /> * Aide à la correction du système de droits<br /> * Réalisation de tâches mineures importantes pour le Hackaton<br /> ** Retirer la vidéo Waza de l'accueil de la plateforme<br /> ** Redirection de l'utilisateur vers la plateforme lorsqu'il accède à l'url du dossier : [[Apache mod_rewrite]]<br /> ** Correction de l'url donné lors de l'appel au service de mails pour la validation de compte<br /> <br /> == Semaine 3 ==<br /> <br /> === 12/02/19 ===<br /> <br /> ==== Servan ====<br /> * Systeme de droits entierement corrigé pour le cas des fichiers.<br /> ** Privilèges administrateurs.<br /> *** Dans la fonction qui verifie les droits &lt;code&gt;Right.php checkRights($command)&lt;/code&gt;, le cas de l'administrateur n'était pas vraiment traité. Il y avait un verification pour empecher tout utilisateur non administrateur d'executer une commande administrateur, mais sinon l'administrateur était traité comme un utilisateur lambda. J'ai donc ajouté un test permettant de donner les pleins pouvoirs. Presque. Il fallait aussi ajouter un test dans la fonction &lt;code&gt;File.php _checkFileAccess(...)&lt;/code&gt; qui pour certaines actions sur les fichiers, agit comme une surcouche à la fonction &lt;code&gt;checkRights&lt;/code&gt; (ce qui permet entre autres des actions sur les fichiers hérités pour le tuteur et les membres).<br /> ** Cas du déplacement de fichier hérités.<br /> *** Avec l'accord d'Anthony, on a conclu que le déplacement de fichier hérité était une mauvaise idée, donc cela reste non autorisé, même pour les admins.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être supprimés.<br /> ** Les appels à la base effectuait une comparaison avec un &lt;code&gt;LIKE&lt;/code&gt; au lieu d'un &lt;code&gt;=&lt;/code&gt; dans la requête SQL, ce qui ne marchait pas dans le cas présent.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être renommés.<br /> ** Le nom du fichier est traité et enregistré par le fichier JS, qui est non typé donc il decide que si le nom n'est que des numeros, alors ce ne sera pas une string. Or pour renommer le fichier, on veux modifer la partie du nom qui est avant le point (de l'extension), donc on fait un appel à &lt;code&gt;name.lastIndexOf(&quot;.&quot;);&lt;/code&gt;, qui s'execute eclusivement sur une string. J'ai donc realisé un &lt;code&gt;.toString()&lt;/code&gt; sur le nom à chaque fois que necessaire.<br /> * Correction du fait que lorsque l'on supprimait un fichier dans un dossier, on était renvoyé à la racine du projet plutot que dans le dossier.<br /> ** Il manquait un paramètre (le dossier) à la fonction &lt;code&gt;getFiles(...)&lt;/code&gt; appalée après la suppréssion.<br /> * Transformation du bouton &quot;Ajouter&quot; en deux boutons, un pour les dossiers, un pour les fichiers.<br /> <br /> ==== Zoran ====<br /> * Mise à Jour de templates de mail (&gt;100 templates)<br /> ** Remplacement des références à Waza Education par EDCampus<br /> ** Production d'une banière et remplacement de l'ancienne<br /> * Tests des fichiers de configuration des tests unitaires<br /> * Recherches sur le passage de l'HTTP vers HTTPS avec [https://letsencrypt.org/ Let's Encrypt] : voir le [[Let's Encrypt | résumé rapide]]<br /> ** Choix d'utilisation de [https://certbot.eff.org/ Certbot]<br /> <br /> === 13/02/19 ===<br /> <br /> ==== Servan ====<br /> Nouvelle tâche assignée : Améliorer les tâches, faire en sorte que si un nom est placé sur un label d'une couleur au sein d'un projet, tous les labels de cette couleur auront ce même nom.<br /> <br /> ==== Zoran ====<br /> * Sauvegarde de la base de données de l'ancienne plateforme<br /> * Passage de l'ancienne plateforme de l'HTTP à l'HTTPS<br /> ** Réparation de la configuration d'Apache<br /> ** Génération des certificats<br /> ** Configuration d'Apache pour l'HTTPS<br /> <br /> === 14/02/19 ===<br /> <br /> ==== Servan ====<br /> * Backend corrigé, on ne peux plus créer une tache d'un nom au choix si il y a deja une tache de cette couleur avec un nom dans le projet.<br /> * Etude approfondie du front-end et du systeme evenementiel pour corriger les defauts de mise à jour.<br /> <br /> ==== Zoran ====<br /> * Recherches sur l'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Découverte et compréhension d'une [https://github.com/BirgerK/docker-apache-letsencrypt image existante]<br /> * Tentative de passage de l'HTTP à l'HTTPS dans un Docker<br /> ** Sur la VM de l'ancienne plateforme (pour ne pas briser la version en prod)<br /> ** Fusion du Dockerfile existant et du Dockerfile de l'image trouvée<br /> <br /> === 15/02/19 ===<br /> <br /> ==== Servan ====<br /> * Correction superficielle des problemes des mise a jour a de la vue du systeme de tache. Le soucis etant que les taches et le petit menu qui indique les details ne sont pas le même module et n'interagissent pas vraiment entre eux, donc on ne peux pas actualier l'un depuis l'autre.<br /> * Correction du fait que dans le systeme de fichier, on ne pouvait pas délacer un fichier/dossier vers le dossier parent en le glissant sur la flèche retour. <br /> ** Le soucis venait du fichier html, qui avait l'air correct mais la variable qu'il etait censé recuppérer renvoyait undefined au lieu de l'identifiant du dossier parent.<br /> <br /> ==== Zoran ====<br /> * Poursuite de la tentative d'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Succès de la création de certificat<br /> ** L'HTTPS ne fonctionne toujours pas (sans doute à cause de la configuration d'Apache)<br /> <br /> == Semaine 4 ==<br /> <br /> Hack ton campus.<br /> <br /> == Semaine 5 ==<br /> <br /> === 05/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug trouvé lors que hackaton qui empêchait les étudiants de télécharger un fichier hérité appartenant à un tuteur. <br /> * Début d'un travail sur les tests unitaires du backend. Le but est de vérifier les tests existants, essayer de les faire fonctionner, et s'en inspirer pour en créer d'autres et à terme, couvrir tout le code.<br /> <br /> ==== Zoran ====<br /> * Succès de la mise en place d'HTTPS dans un docker<br /> ** Modification de &lt;code&gt;docker-compose.yml&lt;/code&gt; pour lier les ports 443 de l'hôte et du conteneur<br /> ** Finalisation de la configuration d'Apache dans le conteneur<br /> <br /> === 06/03/19 ===<br /> <br /> ==== Servan et Zoran ====<br /> <br /> * Lecture de la [https://phpunit.readthedocs.io/en/8.0/ documentation de PHPUNit.]<br /> Après un travail de recherche, nous nous sommes rendu compte que PHPUnit allais être difficile à mettre ne place sur le backend du projet. En effet, toutes les fonctions sont en static et PHPUnit ne marche pas sur le static. Il faudrait donc revoir l'architecture du code pour masquer le statique. Cependant cela est trop long a mettre en place sachant que l'on arrive sur la fin du projet, donc nous avons donner priorité à la vitrine. <br /> <br /> La vitrine est un endroit où le public (étudiants/professeurs/entreprises) peuvent consulter les projets réalisés ou en cours. Cette vitrine se décompose en un endroit ou l'on peux consulter la liste des projets d'une université, et des pages de projets individuelles avec une image, une descriptions et les livrables.<br /> <br /> === 07/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====<br /> <br /> === 08/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Archéologie sur le prototype de vitrine.<br /> * Rédaction de documentation générale sur l'architecture End-To-End du projet (ci-dessous).<br /> <br /> [[File:EDCampus 2019 EndToEnd.png|border]]<br /> <br /> Détails de la fonction &lt;code&gt;checkRights&lt;/code&gt; :<br /> <br /> * La commande en cours est envoyée à &lt;code&gt;checkRights&lt;/code&gt; sous forme de string.<br /> * On vérifie d'abord si elle fait partie des commandes publiques, que l'on peux exécuter lorsque l'on a pas de session. (Via une comparaison avec un tableau contenant toutes les commandes publiques.)<br /> * Si ce n'est pas la cas, on récupère ensuite les informations de session et l'identifiant utilisateur.<br /> * Si on ne trouve pas d'utilisateur, on regarde si on essai d’accéder a une page publique, sinon on bloque l'accès.<br /> * On a maintenant un utilisateur avec une session, qui essaie d'agir sur une page non publique.<br /> * On vérifie si l'utilisateur est super-administrateur.<br /> * On vérifie si l'utilisateur essai d’exécuter une commande administrateur, en tant qu'administrateur.<br /> * Puisque la page est non-publique et que l'on est pas administrateur, il s'agit forcement d'une page de projet. <br /> * On vérifie si l'utilisateur est propriétaire du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est propriétaire du projet courant et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet courant et que cette commande est autorisée.<br /> * Si aucun des tests ci dessus n'a raté (ou n'a déjà accordé l'accès), on accorde l'accès.<br /> <br /> ==== Zoran ====</div>

Zoran.Chanet https://air.imag.fr/index.php?title=PROJET-INFO5_1819_EDCampus&diff=45243 2019-03-11T12:07:18Z

<p>Zoran.Chanet: /* Zoran */</p> <hr /> <div>[[File:Logo_EDCampus.png|thumb|right| Logo EDCampus]]<br /> = Le projet en quelques mots =<br /> La plateforme [[Contributions open-source au projet Eclipse EdCampus | EDCampus]] est une plateforme de gestion de projet développé par Disrupt Campus Grenoble. La plateforme est actuellement en train d’être soumis à la fondation Eclipse afin d’être mise en open source sous licence Eclipse. Dans le cadre du projet Disrupt Campus, les étudiants sont invités à contribuer à la plateforme. Dans le cadre de vos formations c’est une vraie plus value de contribuer à de réels projets plutôt qu’à des projets one-shot qui seront mis à la poubelle sitôt votre soutenance terminée. EDCampus est donc une opportunité de contribuer au logiciel libre et à la fondation Eclipse (et de s'assurer une jolie ligne sur son CV plutôt qu'un projet qui sera aussi vite oublié que l'ECOM !). <br /> <br /> = L'équipe et leurs rôles =<br /> <br /> * GEOURJON Anthony - Chef de projet (EXT)<br /> * [[User:Servan.Charlot | CHARLOT Servan]] - Chef de groupe<br /> * [[User:Zoran.Chanet | CHANET Zoran]] - Responsable DevOps<br /> <br /> = Roadmap =<br /> * '''20-22 février 2019 :''' Hack Ton Campus, la plateforme EDCampus sera utilisée pour la gestion des défis.<br /> * '''Avril 2019 :''' Projet pilote, un projet mêlant une entreprise, l'UGA et des étudiants servira de test à la plateforme.<br /> * '''Septembre 2019 :''' Mise en production globale.<br /> <br /> = Carnet de bord =<br /> <br /> == Semaine 1 ==<br /> <br /> === 28/01/19 ===<br /> <br /> Assignation du sujet [[Contributions open-source au projet Eclipse EdCampus | EDCampus]].<br /> <br /> === 29/01/19 ===<br /> <br /> * Rencontre avec Anthony au [http://fabmstic.liglab.fr/ Fablab], presentation du sujet, des enjeux, et de la roadmap<br /> * Installation du projet<br /> ** Difficultés dues au DNS des réseaux universitaires (impossible de télécharger le contenu nécessaire depuis les containers)<br /> <br /> === 30/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $scope._getProjectParent()&lt;/code&gt; qui ne marchait pas du tout. Il y avait une faute dans la plupart des variables qui s'appelaient &lt;code&gt;currentParentProject&lt;/code&gt; au lieu de &lt;code&gt;currentProjectParent&lt;/code&gt;.<br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $rootScope._checkProject()&lt;/code&gt; qui oubliait un paramètre dans son appel à &lt;code&gt;$scope._setProject()&lt;/code&gt;.<br /> <br /> ==== Zoran ====<br /> * Assignation d'une première tâche : réparer la création d'un projet indépendant<br /> * Découverte du code du projet<br /> * Poursuite de l'arborescence des appels depuis le bouton jusqu'à l'appel à la base de données<br /> <br /> === 01/02/19 ===<br /> ==== Servan ====<br /> <br /> * Assignation de la tâche consistant à réparer le système de fichier.<br /> * Exploration du systeme de fichier et son implementation.<br /> <br /> ==== Zoran ====<br /> * Production d'une méthode permettant des logs personnalisés<br /> * Recherches sur le rewriting d'URL<br /> * Correction du problème (lié au rewriting)<br /> * Production d'une fiche explicative de la solution<br /> <br /> == Semaine 2 ==<br /> <br /> === 04/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction des bugs suivants :<br /> <br /> * Affichage des fichiers du portefeuille père ssi il y a au moins un fichier présent dans le projet fils.<br /> ** Dans le backend, la fonction qui get les fichiers exécutait un &lt;code&gt;return false&lt;/code&gt; avant de get les fichiers parents dans le cas ou il n'y avait pas de fichier à la base.<br /> * N'actualise pas la liste des fichiers si on supprime le dernier fichier.<br /> * Tous les dossiers sont affichés comme des fichiers. Lors de la première sélection à la souris, si on sélectionne le fichier-dossier, il se transforme en dossier et on peut y accéder. Rien ne se passe pour les sélections suivantes.<br /> ** Dans le backend, un paramètre était traité comme chaîne de caractère alors qu'il représentait un booléen. Le résultat de ça est que l'on entrait dans la mauvaise partie d'un if, qui exécutait la mauvaise requête SQL nous privant de l'information concernant le type de fichier lu (un dossier est un type de fichier).<br /> * Le bouton qui permet de revenir en arrière, sortir du dossier ne fonctionne pas.<br /> * On ne peut pas entrer dans un dossier hérité.<br /> <br /> ==== Zoran ====<br /> * Assignation de la mise en place de techniques DevOps<br /> * Recherches sur la mise en place de pipeline dans GitLab : voir [[GitLab CI/CD | compte-rendu]]<br /> * Mise en place d'un pipeline à chaque push<br /> * Production d'un tutoriel de création de runner GitLab : voir [[GitLab Runners | tutoriel]]<br /> * Recherches sur SonarQube et les tests unitaires<br /> ** Priorisation de SonarQube<br /> <br /> === 05/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug qui faisait que lors de la suppression d'un dossier, les fichiers à l'intérieur ne sont pas supprimés (le champ statut dans le BDD ne passe pas à 0).<br /> ** La fonctionnalité de suppression récursive n'était pas implémentée dans &lt;code&gt;File.php&lt;/code&gt;.<br /> * Début de l'analyse du système de droit des utilisateurs (Administrateur/Tuteur/Elève) sur les fichiers et dossiers (hérités ou non).<br /> <br /> ==== Zoran ====<br /> * Compréhension des scanners sonar : voir [[SonarQube Scanner | compte-rendu]]<br /> * Mise en place d'un scan dans le pipeline<br /> ** Nécessité d'un serveur sonar exposé<br /> ** Décision d'utiliser SonarCloud<br /> ** Configuration du scanner pour envoyer le rapport dans le bon projet sonarcloud<br /> ** Réussite du premier scan<br /> <br /> === 06/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Suite de la correction du système de droits des fichiers/dossiers.<br /> <br /> * Correction d'un bug qui faisait que les utilisateurs ne peuvent pas entrer dans les dossiers hérites (ou télécharger les fichiers hérites).<br /> ** Le check de droit se fait dans une fonction qui check d'abord le &lt;code&gt;ownerId&lt;/code&gt;, puis le &lt;code&gt;projectId&lt;/code&gt; et puis enfin si le fichier appartient à un parent. Pour cela elle fait appel à la base pour récupérer la relation d’héritage. IL y avait une erreur de comparaison entre le résultat de la requête et les information fichier (erreur de type parce que PHP).<br /> * Analyse complète du système de droit création d'un tableau explicatif de l'état actuel et l'état voulu.<br /> [[File:EDCampus_2019_Tableau_de_droits.png|center]]<br /> * Suite au tableau, mise en place de la protection des fichiers hérités.<br /> ** Ajout d'une vérification sur le &lt;code&gt;projectId&lt;/code&gt;, empêchant les utilisateurs non propriétaires du fichier de le supprimer, renommer ou déplacer.<br /> <br /> ==== Zoran ====<br /> * Extension du scan sonar dans le pipeline à toutes les sections du projet<br /> * Affichage de badges d'état du pipeline sur la page de présentation de chaque section du projet<br /> * Reprise des recherches concernant les tests unitaires<br /> * Tentative de systématisation des tests dans le pipeline<br /> ** Difficulté : les tests nécessitent des fichiers de configurations qui ne sont pas présents sur le repository git<br /> * Recherche de contournement pour ne pas exposer des configurations privées dans le projet public<br /> <br /> === 08/02/19 ===<br /> <br /> ==== Servan ====<br /> Suppression de la vue pour les non membres et correction partielle du système de droits.<br /> * Lorsque qu'une commande est envoyée par le front-end vers le back-end, elle passe dans une fonction qui vérifie les droits (&lt;code&gt;Right.php checkRights($command)&lt;/code&gt;). La fonction compare la commande utilisée par l'utilisateur aux commandes que cet utilisateur a en général le droit d'utiliser. Le problème était que le tableau de commandes au sein de la fonction (permettant la comparaison) contenait des commandes mal formatées. J'ai donc corrigé celle qui m'intéressais pour empêcher les non membres d'un projet à consulter les fichiers, et j'en ai profiter pour corriger toutes les autres.<br /> <br /> ==== Zoran ====<br /> * Configuration des scanners sonar dans le pipeline (redirection vers une branche du projet sonarcloud nommée selon la branche GitLab sur laquelle le pipeline est lancé)<br /> * Aide à la correction du système de droits<br /> * Réalisation de tâches mineures importantes pour le Hackaton<br /> ** Retirer la vidéo Waza de l'accueil de la plateforme<br /> ** Redirection de l'utilisateur vers la plateforme lorsqu'il accède à l'url du dossier : [[Apache mod_rewrite]]<br /> ** Correction de l'url donné lors de l'appel au service de mails pour la validation de compte<br /> <br /> == Semaine 3 ==<br /> <br /> === 12/02/19 ===<br /> <br /> ==== Servan ====<br /> * Systeme de droits entierement corrigé pour le cas des fichiers.<br /> ** Privilèges administrateurs.<br /> *** Dans la fonction qui verifie les droits &lt;code&gt;Right.php checkRights($command)&lt;/code&gt;, le cas de l'administrateur n'était pas vraiment traité. Il y avait un verification pour empecher tout utilisateur non administrateur d'executer une commande administrateur, mais sinon l'administrateur était traité comme un utilisateur lambda. J'ai donc ajouté un test permettant de donner les pleins pouvoirs. Presque. Il fallait aussi ajouter un test dans la fonction &lt;code&gt;File.php _checkFileAccess(...)&lt;/code&gt; qui pour certaines actions sur les fichiers, agit comme une surcouche à la fonction &lt;code&gt;checkRights&lt;/code&gt; (ce qui permet entre autres des actions sur les fichiers hérités pour le tuteur et les membres).<br /> ** Cas du déplacement de fichier hérités.<br /> *** Avec l'accord d'Anthony, on a conclu que le déplacement de fichier hérité était une mauvaise idée, donc cela reste non autorisé, même pour les admins.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être supprimés.<br /> ** Les appels à la base effectuait une comparaison avec un &lt;code&gt;LIKE&lt;/code&gt; au lieu d'un &lt;code&gt;=&lt;/code&gt; dans la requête SQL, ce qui ne marchait pas dans le cas présent.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être renommés.<br /> ** Le nom du fichier est traité et enregistré par le fichier JS, qui est non typé donc il decide que si le nom n'est que des numeros, alors ce ne sera pas une string. Or pour renommer le fichier, on veux modifer la partie du nom qui est avant le point (de l'extension), donc on fait un appel à &lt;code&gt;name.lastIndexOf(&quot;.&quot;);&lt;/code&gt;, qui s'execute eclusivement sur une string. J'ai donc realisé un &lt;code&gt;.toString()&lt;/code&gt; sur le nom à chaque fois que necessaire.<br /> * Correction du fait que lorsque l'on supprimait un fichier dans un dossier, on était renvoyé à la racine du projet plutot que dans le dossier.<br /> ** Il manquait un paramètre (le dossier) à la fonction &lt;code&gt;getFiles(...)&lt;/code&gt; appalée après la suppréssion.<br /> * Transformation du bouton &quot;Ajouter&quot; en deux boutons, un pour les dossiers, un pour les fichiers.<br /> <br /> ==== Zoran ====<br /> * Mise à Jour de templates de mail (&gt;100 templates)<br /> ** Remplacement des références à Waza Education par EDCampus<br /> ** Production d'une banière et remplacement de l'ancienne<br /> * Tests des fichiers de configuration des tests unitaires<br /> * Recherches sur le passage de l'HTTP vers HTTPS avec [https://letsencrypt.org/ Let's Encrypt] : voir le [[Let's Encrypt | résumé rapide]]<br /> ** Choix d'utilisation de [https://certbot.eff.org/ Certbot]<br /> <br /> === 13/02/19 ===<br /> <br /> ==== Servan ====<br /> Nouvelle tâche assignée : Améliorer les tâches, faire en sorte que si un nom est placé sur un label d'une couleur au sein d'un projet, tous les labels de cette couleur auront ce même nom.<br /> <br /> ==== Zoran ====<br /> * Sauvegarde de la base de données de l'ancienne plateforme<br /> * Passage de l'ancienne plateforme de l'HTTP à l'HTTPS<br /> ** Réparation de la configuration d'Apache<br /> ** Génération des certificats<br /> ** Configuration d'Apache pour l'HTTPS<br /> <br /> === 14/02/19 ===<br /> <br /> ==== Servan ====<br /> * Backend corrigé, on ne peux plus créer une tache d'un nom au choix si il y a deja une tache de cette couleur avec un nom dans le projet.<br /> * Etude approfondie du front-end et du systeme evenementiel pour corriger les defauts de mise à jour.<br /> <br /> ==== Zoran ====<br /> * Recherches sur l'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Découverte et compréhension d'une [https://github.com/BirgerK/docker-apache-letsencrypt image existante]<br /> * Tentative de passage de l'HTTP à l'HTTPS dans un Docker<br /> ** Sur la VM de l'ancienne plateforme (pour ne pas briser la version en prod)<br /> ** Fusion du Dockerfile existant et du Dockerfile de l'image trouvée<br /> <br /> === 15/02/19 ===<br /> <br /> ==== Servan ====<br /> * Correction superficielle des problemes des mise a jour a de la vue du systeme de tache. Le soucis etant que les taches et le petit menu qui indique les details ne sont pas le même module et n'interagissent pas vraiment entre eux, donc on ne peux pas actualier l'un depuis l'autre.<br /> * Correction du fait que dans le systeme de fichier, on ne pouvait pas délacer un fichier/dossier vers le dossier parent en le glissant sur la flèche retour. <br /> ** Le soucis venait du fichier html, qui avait l'air correct mais la variable qu'il etait censé recuppérer renvoyait undefined au lieu de l'identifiant du dossier parent.<br /> <br /> ==== Zoran ====<br /> * Poursuite de la tentative d'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Succès de la création de certificat<br /> ** L'HTTPS ne fonctionne toujours pas (sans doute à cause de la configuration d'Apache)<br /> <br /> == Semaine 4 ==<br /> <br /> Hack ton campus.<br /> <br /> == Semaine 5 ==<br /> <br /> === 05/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug trouvé lors que hackaton qui empêchait les étudiants de télécharger un fichier hérité appartenant à un tuteur. <br /> * Début d'un travail sur les tests unitaires du backend. Le but est de vérifier les tests existants, essayer de les faire fonctionner, et s'en inspirer pour en créer d'autres et à terme, couvrir tout le code.<br /> <br /> ==== Zoran ====<br /> * Succès de la mise en place d'HTTPS dans un docker<br /> ** Correction de la configuration d'Apache à l'intérieur du conteneur<br /> <br /> === 06/03/19 ===<br /> <br /> ==== Servan et Zoran ====<br /> <br /> * Lecture de la [https://phpunit.readthedocs.io/en/8.0/ documentation de PHPUNit.]<br /> Après un travail de recherche, nous nous sommes rendu compte que PHPUnit allais être difficile à mettre ne place sur le backend du projet. En effet, toutes les fonctions sont en static et PHPUnit ne marche pas sur le static. Il faudrait donc revoir l'architecture du code pour masquer le statique. Cependant cela est trop long a mettre en place sachant que l'on arrive sur la fin du projet, donc nous avons donner priorité à la vitrine. <br /> <br /> La vitrine est un endroit où le public (étudiants/professeurs/entreprises) peuvent consulter les projets réalisés ou en cours. Cette vitrine se décompose en un endroit ou l'on peux consulter la liste des projets d'une université, et des pages de projets individuelles avec une image, une descriptions et les livrables.<br /> <br /> === 07/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====<br /> <br /> === 08/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Archéologie sur le prototype de vitrine.<br /> * Rédaction de documentation générale sur l'architecture End-To-End du projet (ci-dessous).<br /> <br /> [[File:EDCampus 2019 EndToEnd.png|border]]<br /> <br /> Détails de la fonction &lt;code&gt;checkRights&lt;/code&gt; :<br /> <br /> * La commande en cours est envoyée à &lt;code&gt;checkRights&lt;/code&gt; sous forme de string.<br /> * On vérifie d'abord si elle fait partie des commandes publiques, que l'on peux exécuter lorsque l'on a pas de session. (Via une comparaison avec un tableau contenant toutes les commandes publiques.)<br /> * Si ce n'est pas la cas, on récupère ensuite les informations de session et l'identifiant utilisateur.<br /> * Si on ne trouve pas d'utilisateur, on regarde si on essai d’accéder a une page publique, sinon on bloque l'accès.<br /> * On a maintenant un utilisateur avec une session, qui essaie d'agir sur une page non publique.<br /> * On vérifie si l'utilisateur est super-administrateur.<br /> * On vérifie si l'utilisateur essai d’exécuter une commande administrateur, en tant qu'administrateur.<br /> * Puisque la page est non-publique et que l'on est pas administrateur, il s'agit forcement d'une page de projet. <br /> * On vérifie si l'utilisateur est propriétaire du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet parent et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est propriétaire du projet courant et que cette commande est autorisée.<br /> * On vérifie si l'utilisateur est membre du projet courant et que cette commande est autorisée.<br /> * Si aucun des tests ci dessus n'a raté (ou n'a déjà accordé l'accès), on accorde l'accès.<br /> <br /> ==== Zoran ====</div>

Zoran.Chanet https://air.imag.fr/index.php?title=Projets_2018-2019&diff=45141 2019-03-05T08:13:59Z

<p>Zoran.Chanet: /* Affectations */</p> <hr /> <div>&lt;&lt;[[Projets 2017-2018]] | [[Projets]] | [[Projets 2019-2020]]&gt;&gt;<br /> =INFO=<br /> ==INFO3==<br /> <br /> ==INFO4==<br /> ===Projet Semestre S8===<br /> <br /> Enseignants responsables : Olivier Richard, Didier Donsez<br /> <br /> * Dates : Lundi après-midi, Mardi après-midi <br /> * Lancement: '''21/01/19 à 14h30'''<br /> * Soutenance à mi-parcours: A définir<br /> * Soutenance: A définir<br /> <br /> * '''Evaluation à mi-parcours le lundi/mardi ???''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.<br /> <br /> '''Consignes générales:'''<br /> <br /> * '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: creuser la question, contacter l'auteur du code si il y a lieu, écrire un rapport de bug ('''Attention:''' ca se prépare !), soumettre un patch/pull request, contacter l'enseignant ou la personne référente du projet.<br /> <br /> * '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par info4_2018_2019. '''Cette fiche compte pour la note finale'''<br /> <br /> * '''Votre code''' pour doit être hébergé sur le gitlab et à l'URL suivante https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19 , vous utiliserez votre compte UGA.<br /> <br /> * Chaque projet doit avoir '''aux moins 2 dépôts git''':<br /> ** '''Un pour les documents''' demandés rapport, présentation de pré-soutenante, de soutenance, flyer. '''Il sera appelé documents.'''<br /> ** Un ou plusieurs pour le code, les tests, les évaluations, les preuves de concept, la ou les documentations afférentes. <br /> <br /> * Les documents public doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions). Une bonnification sera accordée si le rapport et les transparents sont en anglais (la soutenance sera en francais).<br /> <br /> * '''La note obtenue''' tiendra compte du '''nombre et de la qualité des commits''' observé dans '''vos dépots git et la branche master''' (or depot documents). La qualité comprend l'intitulé du commit et son contenu. Les notes pourront être différentiées dans un groupe, il n'est pas acceptable de pas avoir de commit dans le(s) dépôt(s) du projet (or dépôt documents).<br /> <br /> * Il est fortement conseillé de suivre un '''développement incrémental''' qui permette d'avoir à tout moment un démonstrateur à présenter, un projet peut être constituer d'une succession de '''démonstrateurs présentables séparément'''.<br /> <br /> * Vous devez faire aussi des '''schémas d'architectures générales et/ou spéficiques, des diagrammes de séquence''', et autre documents de spécification si nécessaire. Ces documents vous serviront de base de discussion/brainstorming interne ainsi que dans vos différents documents (rapport, présentations, documentation). Ces schémas sont avant tout conceptuels et techniques.<br /> <br /> ===Propositions de projets===<br /> <br /> * [[LoRaGAN]] : LoRa in the Space, Didier Donsez avec le [https://www.csug.fr/ CSUG] (S)<br /> * [[LoRaRescueBalloon]], Didier Donsez avec le [https://www.csug.fr/ CSUG] et des élèves IESE 3 et 4. (S)<br /> * Agriculture connectée à [[ASAC/AP|Polytech]] et à [[ASAC/SJC|St Cassien]] en partenariat avec les projets collectifs IESE/MAT<br /> *# [[ASAC/AP/AP-2019-1|Serre Polytech - Système embarqué]] - Projet embarqué sur STM32 ou RPi3 + LoRa (S)<br /> *# [[ASAC/AP/AP-2019-2|Serre Polytech - Kiosk]] - Kiosk, App. mobile Android et site web de visualisation des données (M)<br /> *# [[ASAC/SJC/SJC-2019|Serre St Cassien]] - Kiosk, App. mobile Android et site web de visualisation des données (M)<br /> * [[Projet FICHA - tri sélectif connecté]], Sylvain Toru.<br /> * [[Dataviz de la qualité de l'air]], Didier Donsez, avec Atmo AURA et [https://github.com/CampusIoT/campusiot.github.io CampusIoT] (M)<br /> * [[Application mobile Ionic pour Cages à marmotte connectées en LoRaWAN]], Didier Donsez, Franck Delbard, avec le [https://www.jardinalpindulautaret.fr/ Station alpine Joseph Fourier] (M)<br /> * [[Testeur radio LoRaWAN en Ionic pour la plateforme CampusIoT]], Didier Donsez (S&amp;M)<br /> * [[Serious game multi-joueurs pour tables tactiles en réseau]] : Anne-Laure Finkel, Tim Lepage, Didier Donsez. (S&amp;M)<br /> * [[Interface de visualisation mobile du projet e-Tree]]: Anne Delaballe, Didier Donsez. (M)<br /> * [[OpenHAB UPnP DCS 2018]], Didier Donsez (S&amp;M)<br /> * [[Application mobile Ionic pour cabine de biathlon connectée en LoRa]], Didier Donsez et d'autres avec Neoxia<br /> * [[P2P_IPFS | Réseau social pair-à-pair basé sur IPFS]], Olivier Richard (S)<br /> * [[proxy_web_oar | Service de Proxy web pour un gestionnaire de tâches]], Olivier Richard (S)<br /> * [[Colmet_energy | Mesure de consommation d'énergie et de perfomance pour cluster]], Olivier Richard (S)<br /> * [[kanixfs | Diffusion de fichiers pour le gestionnaire de paquets NIX sur supercalculateur]], Olivier Richard (S)<br /> * [[dashboard_sci | Générateur de tableau de bord pour applications scientifiques]], Olivier Richard (S&amp;M)<br /> * [[generate_NIX_expression | Génération d'expression NIX]] (S)<br /> <br /> Non prioritaire<br /> * [[Précarité numérique]], Didier Donsez, avec [https://disrupt-campus.univ-grenoble-alpes.fr/ Disrupt Campus]<br /> * [[Covoiturage Solidaire]], Didier Donsez<br /> * [[CannonBall de voitures autonomes 2018]]<br /> * Intégration de [[Walabot]] à [[RobAIR]]<br /> <br /> ==== Affectation ====<br /> {|class=&quot;wikitable alternance&quot;<br /> |+ Affectation des projets INFO4 2018-2019<br /> |-<br /> |<br /> !scope=&quot;col&quot;| Sujet<br /> !scope=&quot;col&quot;| Etudiants<br /> !scope=&quot;col&quot;| Enseignant(s)<br /> !scope=&quot;col&quot;| Fiche de suivi<br /> !scope=&quot;col&quot;| Dépot git<br /> |-<br /> <br /> !scope=&quot;row&quot;| 1<br /> | [[LoRaGAN]]<br /> | VINCENT Mathieu, SAUTON Tanguy, ANCRENAZ Ariane<br /> | Didier Donsez avec le [https://www.csug.fr/ CSUG]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/1/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 2<br /> | [[LoRaRescueBalloon]]<br /> | Non attribué<br /> | Didier Donsez avec le [https://www.csug.fr/ CSUG]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/2/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 3<br /> | [[ASAC/AP/AP-2019-1|Serre Polytech - Système embarqué]]<br /> | Non attribué<br /> | Nicolas Palix<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/3/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 4<br /> | [[ASAC/AP/AP-2019-2|Serre Polytech]]<br /> | RAKOTOARIMALALA Andriamahatratra, BARDOU Eva, GAUFFIER Léni<br /> | Nicolas Palix<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/4/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 5<br /> | [[ASAC/SJC/SJC-2019|Serre St Cassien]]<br /> | DECAMPS Marceau, LANDI Estelle, BONASPETTI GIULIA<br /> | Nicolas Palix<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/5/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 6<br /> | [[Projet FICHA - tri sélectif connecté]]<br /> | SCHANEN Loïc, VINCENT Maxence, VANDAL Jade<br /> | Sylvain Toru<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/6/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 7<br /> | [[Dataviz de la qualité de l'air]]<br /> | ZARCOS Paul, ZHENG Jian, REYMOND Estelle<br /> | Didier Donsez, avec Atmo AURA et [https://github.com/CampusIoT/campusiot.github.io CampusIoT]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/7/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 8<br /> | [[Application mobile Ionic pour Cages à marmotte connectées en LoRaWAN]]<br /> | SERRE Ancelin, BOUVIER Baptiste, WYKLAND Damien<br /> | Didier Donsez, Franck Delbard, avec le [https://www.jardinalpindulautaret.fr/ Station alpine Joseph Fourier]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/8/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 9<br /> | [[Testeur radio LoRaWAN en Ionic pour la plateforme CampusIoT]]<br /> | THOMAS Antoine, RIVOIRE Antoine, DENIS Guillaume<br /> | Didier Donsez<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/9/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 10<br /> | [[Serious game multi-joueurs pour tables tactiles en réseau]]<br /> | DUMENIL Antoine, BETEND Baptiste, JAN Léo<br /> | Anne-Laure Finkel, Tim Lepage, Didier Donsez<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/10/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 11<br /> | [[Interface de visualisation mobile du projet e-Tree]]<br /> | SOLVERY Tom, SALA Ergi, DUMAX-VORZET Mathieu<br /> | Anne Delaballe, Didier Donsez<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/11/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 12<br /> | [[OpenHAB UPnP DCS 2018]]<br /> | VARENNE Rémi, TRESTOUR Grégory, SOUCHON Loïc<br /> | Didier Donsez<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/12/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 13<br /> | [[Application mobile Ionic pour cabine de biathlon connectée en LoRa]]<br /> | LORDEY Maxime, LATTARD Alexis, GILBERT-COLLET Bertrand<br /> | Didier Donsez et d'autres avec Neoxia<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/13/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 14<br /> | [[P2P_IPFS | Réseau social pair-à-pair basé sur IPFS]]<br /> | REYGROBELLET Lucas, BRES Maxence, PELISSON Antoine<br /> | Olivier Richard<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/14/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 15<br /> | [[proxy_web_oar | Service de Proxy web pour un gestionnaire de tâches]]<br /> | Non attribué<br /> | Olivier Richard<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/15/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 16<br /> | [[Colmet_energy | Mesure de consommation d'énergie et de perfomance pour cluster]]<br /> | DALAINE Nathan, FONTFREYDE Joachim, GAUTIER-PIGNONBLANC Yann<br /> | Olivier Richard, Adrien Faure<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/16/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 17<br /> | [[kanixfs | Diffusion de fichiers pour le gestionnaire de paquets NIX sur supercalculateur]]<br /> | Non attribué<br /> | Olivier Richard<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/17/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 18<br /> | [[dashboard_sci | Générateur de tableau de bord pour applications scientifiques]]<br /> | BADAT Léya, CUAU Victor, MASSON Jérémy<br /> | Olivier Richard<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/18/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 19<br /> | [[generate_NIX_expression | Génération d'expression NIX]]<br /> | CHABRE Manon, DE ARAUJO Bastien, COSCIA Daniel<br /> | Olivier Richard<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/19/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 20<br /> | [[Gestion des Polypoints]]<br /> | CASTANO Nicolas, SIBUE Quentin, LAPLANTE Juliette<br /> | Didier Donsez, Olivier Richard<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/20/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 21<br /> | [[Smart Recruting]]<br /> | GUILLOT Romain, ARNOUX Thibaut, CHASSEGUET Corentin<br /> | Didier Donsez, Olivier Richard<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/21/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 22<br /> | [[Aide aux handicaps]]<br /> | JALMIN Hoël, ALACALI Kadir uraz, MASTOURA Iheb<br /> | Didier Donsez, Olivier Richard<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/22/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> |}<br /> <br /> ==INFO5==<br /> ===Projet IoT S9===<br /> Enseignants responsables : Bernard Tourancheau<br /> <br /> Calendrier: ??? Septembre à ??? Décembre 2017.<br /> <br /> * Projet IoT 3 : [[Ski-locator]] (Bernard Tourancheau)<br /> <br /> <br /> <br /> ===Projet Semestre S10===<br /> <br /> Enseignants responsables : [[user:Donsez | Didier Donsez]]<br /> <br /> Calendrier: Fin Janvier à Fin Mars 2019.<br /> <br /> Séances de Management de projets innovants:<br /> <br /> Réunion de présentation : Salle 249 de 11H30 a 12H30, Mercredi 23 Janvier. Faire couler le café.<br /> <br /> Démarrage : A définir: Salle 251 de 8H30 a 11H00, Lundi 23 Janvier. Faire couler le café.<br /> <br /> Soutenance à mi-parcours : 5 Mars, 9H00-11H30 (15 minutes par équipe).<br /> <br /> Soutenance (puis Pot de la fin) : A définir : à cheval 27 et 28 Mars.<br /> <br /> ==== Affectations ====<br /> {|class=&quot;wikitable alternance&quot;<br /> |+ Affectation des projets INFO5 2018-2019<br /> |-<br /> |<br /> !scope=&quot;col&quot;| Sujet<br /> !scope=&quot;col&quot;| Etudiants<br /> !scope=&quot;col&quot;| Enseignant(s)<br /> !scope=&quot;col&quot;| Fiche de suivi<br /> !scope=&quot;col&quot;| Documents<br /> |-<br /> <br /> !scope=&quot;row&quot;| 1<br /> | [[LoRaGAN/INFO5A/2019|LoRaGAN]]<br /> | Thibaud VEGREVILLE,Aurélien SURIER GAROFALO<br /> | Didier Donsez, Bernard Tourancheau, Mathieu Barthélémy ([https://www.csug.fr/ CSUG])<br /> | TBD<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 2<br /> | [[Contributions open-source au projet Eclipse EdCampus]]<br /> | [[User:Servan.Charlot | CHARLOT Servan]] (chef de projet), [[User:Zoran.Chanet | CHANET Zoran]]<br /> | Anthony Geourjon, Gérard Pollier, Didier Donsez<br /> | [[PROJET-INFO5 1819 EDCampus | Fiche de suivi ]]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:EDCampus_Mi_Parcours_CHARLOT_CHANET.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 3<br /> | [[RICM5 2018 2019 - UGAChain|UGAChain 2019]] : [[Générateur Hyperledger pour JHipster]] : refactoring du projet [[RICM5 2017 2018 - UGAChain|UGAChain 2018]]<br /> | Loris GENTILLON, Jordan JEAN, Enzo MOLION, Léo VALETTE<br /> | Didier Donsez, Anthony Geourjon<br /> | TBD<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 4<br /> | [[Aide aux déficients visuelles]] (deep-learning avec [[Intel Movidius]], [https://greenwaves-technologies.com/product/gapduino/ GAPDunio], [[Lidar]] 1D et 2D, ...)<br /> | Samuel Bamba, Florian Cuzin, Théo Echevet, Raphaël Manger<br /> | Didier Donsez, Marie-Paule Balicco, Nicolas Vuillerme<br /> | TBD<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 5<br /> | [[Plateforme CampusIoT]]<br /> | '''William Weill (CP)''', Guillaume Besnard, Benjamin Besnier, Timothée Depriester, Théo Lévesque<br /> | Didier Donsez<br /> | [[PROJET-1FO5_1819_CampusIoT|Fiche]] - [[PROJET-1FO5_1819_CampusIoT_journal|Journal]]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 6<br /> | [[Rééducation Kiné connecté]]<br /> | '''Sekina Belguendouz (CP)''', Vincent Aubert, Amina Boucherima, Najwa Ez-Zine<br /> | Sylvain Toru, Bernard Tourancheau<br /> | [[PROJET-INFO5_Kiné_Connecté | Fiche]]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 7<br /> | Projet IoT 3 : [[Ski-locator]]<br /> | '''Quentin Fombaron (CP)''', Tim Lepage, Thomas Ozenda, Joffrey Ferreira, Titouan Larnicol<br /> | Bernard Tourancheau<br /> | [[PROJET-1FO5_1819_SkiLocator|Fiche]] - [[PROJET-1FO5_1819_SkiLocator/SRS|SRS]]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 8<br /> | [[Contributions open-source au projet JHipster]]<br /> | '''Hugo GROS-DAILLON (CP)''', Julien COURTIAL, Cédric LAFRASSE, Bastien TERRIER<br /> | Didier Donsez, Anthony Geourjon<br /> | [[ PROJET-INFO5_Contributions_JHipster | Fiche ]]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> |}<br /> <br /> Réserve<br /> * [[Contributions à Software Heritage]] (Didier Donsez and co)<br /> * [[Sécurisation des données IoT avec des blockchains de consortium]] (Didier Donsez) --&gt; commun avec CampusIoT et UGAChain<br /> <br /> = Projets collectifs MAT/IESE =<br /> <br /> == Années 3 et 4 ==<br /> <br /> * [[ASAC/SJC|Serres connectées @ Jardin du coteau]]<br /> * [[ASAC/GEJC|Gestion de l'eau @ Jardin du coteau]]<br /> * [[ASAC/AP|Aquaponie @ Polytech]]<br /> <br /> =[[Projets M2PGI Services Machine-to-Machine et Internet-of-Things]]=<br /> ==[[PM2M/2019/TP|PM2M]]==<br /> <br /> =Réserve (boite à idées)=<br /> # [http://www.opti-solar.com/french/ap_applications.fr.html |Interface contrôleur de charge batterie/PV]<br /> # [[Sonotone à apprentissage profond]]<br /> # [[StartAIR2]] (Nicolas Palix)<br /> # [[Tag et Paint Ball en réalité augmentée]] (Michaël Périn) <br /> # [[Passe moi ton fichier]] (Michaël Périn) <br /> # [[Extensions à Fab Server]] (Jean-Michel Molenaar) sous reserve (CM ou SR)<br /> # [[Table multijeux de café 2.0]]<br /> # [[ GPIO_Qemu_RasPI| Emulation des GPIO dans QEMU pour le carte Raspberry Pi]] (Olivier Richard)<br /> # [[ Qemu et STM32F0-Discovery ]] (Olivier Richard)<br /> # [[Serrure à clé MIDI multifactorielle]] (Didier Donsez)<br /> # [[Table interactive musicale]] (Didier Donsez)<br /> # [[iMailbox]] (Didier Donsez)<br /> # [[AmILight]] (eclairage d'ambience intelligent) (Didier Donsez)<br /> # [[PDAmeetPDA]] (synchronisation d'agenda) (Michaël Périn)<br /> # [[1 000 000 VMs]] (expérimentation d'application distribuée à très grande échelle) (Olivier Richard) (2-3 RICM4)<br /> # [[Multiple Kinect]] (utilisation simultanée de plusieurs Kinect) (Olivier Richard) (RICM ou 3I)<br /> # [[Kinect musicale]] (Didier Donsez) (RICM)<br /> # [[Ktechlab Simavr Arduino | Ktechlab et integration de Simavr(Arduino)]] (Olivier Richard) (2-3 RICM4-SR)<br /> # Ocaml on AVR (Arduino)<br /> # Ocaml on Cortex-M3<br /> # [[Arduino on STM32 Discovery]]<br /> # [[Reverse Geocache Puzzle Box]]<br /> # [[OSGi ME]] (Didier Donsez)<br /> # [[Affichage Etudiant à Polytech]]<br /> # Synthèse 3D + motion capture Kinect<br /> # Logiciel d'[[apprentissage du calcul]] sur tablette Android (reconnaissance de chiffres manuscrits)<br /> # Plancher de verre (saint gobain) à la [http://www.wat.tv/video/mickael-jackson-billie-jean-oewj_2ey2h_.html Mickael Jackson dans Billie Jean] ! woo<br /> # [[Ktechlab Simavr Arduino | Ktechlab et integration de Simavr(Arduino)]] (Olivier Richard) (2-3 RICM4-SR)<br /> # [[CNC]]<br /> # [[Idées en Vrac]]<br /> # Scheme Everywhere (Olivier Richard) (2-3 RICM4-SR)<br /> # [[Projet Station Météo]]<br /> # Ocaml on AVR (Arduino)<br /> # [[Table interactive musicale]] (Didier Donsez)<br /> # [[AmILight]] (eclairage d'amnbience intelligent) (Didier Donsez)<br /> # [[Cube pointeur]] d'activité ingénieur<br /> # [http://www.instructables.com/id/Puppeteer-Motion-Capture-Costume/ Puppeteer Motion-Capture Costume]<br /> # [[Musical Staircase]] @ Polytech (Didier Donsez, 1 RICM4 + 1 3I4)<br /> # [[Total Recall]] (Didier Donsez)<br /> # [[SoundMachine]]<br /> # [[IGN-OSM|Importation de données IGN publiques dans OSM]]<br /> # [[Speed-limit-OSM|Analyse de traces GPX pour déterminer les limitations de vitesse]]<br /> # [[Multi perceptual cameras]] (Didier Donsez)<br /> # [[Photomaton 3D]] (Didier Donsez)<br /> # [[ArduCopter]]<br /> # [[Parking Intelligent]]<br /> # Frontend Web multi-utilisateur pour un jeu sérieux d'entreprise : Didier Donsez, Stéphanie Diligent, Emmanuelle Tréhoust.<br /> # Construction d'un roadbook d'ultratrail (mais aussi trek, randonnée, cyclisme, ...) à partir de traces GPX et des réseaux sociaux (Strava, Trace de Trail, ...): Didier Donsez</div>

Zoran.Chanet https://air.imag.fr/index.php?title=File:EDCampus_Mi_Parcours_CHARLOT_CHANET.pdf&diff=45140 2019-03-05T08:13:27Z

<p>Zoran.Chanet: </p> <hr /> <div>Présentation de mi-parcours du projet EDCampus en INFO 5 par MM. [[User:Servan.Charlot | CHARLOT Servan]] et [[User:Zoran.Chanet | CHANET Zoran]]</div>

Zoran.Chanet https://air.imag.fr/index.php?title=File:EDCampus_Mi_Parcours_CHARLOT_CHANET.pdf&diff=45139 2019-03-05T08:12:17Z

<p>Zoran.Chanet: Présentation de mi-parcours du projet EDCampus en INFO 5 par MM. CHARLOT Servan et CHANET Zoran</p> <hr /> <div>Présentation de mi-parcours du projet EDCampus en INFO 5 par MM. CHARLOT Servan et CHANET Zoran</div>

Zoran.Chanet https://air.imag.fr/index.php?title=PROJET-INFO5_1819_EDCampus&diff=45133 2019-03-04T09:00:07Z

<p>Zoran.Chanet: /* Zoran */</p> <hr /> <div>[[File:Logo_EDCampus.png|thumb|right| Logo EDCampus]]<br /> = Le projet en quelques mots =<br /> La plateforme [[Contributions open-source au projet Eclipse EdCampus | EDCampus]] est une plateforme de gestion de projet développé par Disrupt Campus Grenoble. La plateforme est actuellement en train d’être soumis à la fondation Eclipse afin d’être mise en open source sous licence Eclipse. Dans le cadre du projet Disrupt Campus, les étudiants sont invités à contribuer à la plateforme. Dans le cadre de vos formations c’est une vraie plus value de contribuer à de réels projets plutôt qu’à des projets one-shot qui seront mis à la poubelle sitôt votre soutenance terminée. EDCampus est donc une opportunité de contribuer au logiciel libre et à la fondation Eclipse (et de s'assurer une jolie ligne sur son CV plutôt qu'un projet qui sera aussi vite oublié que l'ECOM !). <br /> <br /> = L'équipe et leurs rôles =<br /> <br /> * GEOURJON Anthony - Chef de projet (EXT)<br /> * [[User:Servan.Charlot | CHARLOT Servan]] - Chef de groupe<br /> * [[User:Zoran.Chanet | CHANET Zoran]] - Responsable DevOps<br /> <br /> = Roadmap =<br /> * '''20-22 février 2019 :''' Hack Ton Campus, la plateforme EDCampus sera utilisée pour la gestion des défis.<br /> * '''Avril 2019 :''' Projet pilote, un projet mêlant une entreprise, l'UGA et des étudiants servira de test à la plateforme.<br /> * '''Septembre 2019 :''' Mise en production globale.<br /> <br /> = Carnet de bord =<br /> <br /> == Semaine 1 ==<br /> <br /> === 28/01/19 ===<br /> <br /> Assignation du sujet [[Contributions open-source au projet Eclipse EdCampus | EDCampus]].<br /> <br /> === 29/01/19 ===<br /> <br /> * Rencontre avec Anthony au [http://fabmstic.liglab.fr/ Fablab], presentation du sujet, des enjeux, et de la roadmap<br /> * Installation du projet<br /> ** Difficultés dues au DNS des réseaux universitaires (impossible de télécharger le contenu nécessaire depuis les containers)<br /> <br /> === 30/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $scope._getProjectParent()&lt;/code&gt; qui ne marchait pas du tout. Il y avait une faute dans la plupart des variables qui s'appelaient &lt;code&gt;currentParentProject&lt;/code&gt; au lieu de &lt;code&gt;currentProjectParent&lt;/code&gt;.<br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $rootScope._checkProject()&lt;/code&gt; qui oubliait un paramètre dans son appel à &lt;code&gt;$scope._setProject()&lt;/code&gt;.<br /> <br /> ==== Zoran ====<br /> * Assignation d'une première tâche : réparer la création d'un projet indépendant<br /> * Découverte du code du projet<br /> * Poursuite de l'arborescence des appels depuis le bouton jusqu'à l'appel à la base de données<br /> <br /> === 01/02/19 ===<br /> ==== Servan ====<br /> <br /> * Assignation de la tâche consistant à réparer le système de fichier.<br /> * Exploration du systeme de fichier et son implementation.<br /> <br /> ==== Zoran ====<br /> * Production d'une méthode permettant des logs personnalisés<br /> * Recherches sur le rewriting d'URL<br /> * Correction du problème (lié au rewriting)<br /> * Production d'une fiche explicative de la solution<br /> <br /> == Semaine 2 ==<br /> <br /> === 04/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction des bugs suivants :<br /> <br /> * Affichage des fichiers du portefeuille père ssi il y a au moins un fichier présent dans le projet fils.<br /> ** Dans le backend, la fonction qui get les fichiers exécutait un &lt;code&gt;return false&lt;/code&gt; avant de get les fichiers parents dans le cas ou il n'y avait pas de fichier à la base.<br /> * N'actualise pas la liste des fichiers si on supprime le dernier fichier.<br /> * Tous les dossiers sont affichés comme des fichiers. Lors de la première sélection à la souris, si on sélectionne le fichier-dossier, il se transforme en dossier et on peut y accéder. Rien ne se passe pour les sélections suivantes.<br /> ** Dans le backend, un paramètre était traité comme chaîne de caractère alors qu'il représentait un booléen. Le résultat de ça est que l'on entrait dans la mauvaise partie d'un if, qui exécutait la mauvaise requête SQL nous privant de l'information concernant le type de fichier lu (un dossier est un type de fichier).<br /> * Le bouton qui permet de revenir en arrière, sortir du dossier ne fonctionne pas.<br /> * On ne peut pas entrer dans un dossier hérité.<br /> <br /> ==== Zoran ====<br /> * Assignation de la mise en place de techniques DevOps<br /> * Recherches sur la mise en place de pipeline dans GitLab : voir [[GitLab CI/CD | compte-rendu]]<br /> * Mise en place d'un pipeline à chaque push<br /> * Production d'un tutoriel de création de runner GitLab : voir [[GitLab Runners | tutoriel]]<br /> * Recherches sur SonarQube et les tests unitaires<br /> ** Priorisation de SonarQube<br /> <br /> === 05/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug qui faisait que lors de la suppression d'un dossier, les fichiers à l'intérieur ne sont pas supprimés (le champ statut dans le BDD ne passe pas à 0).<br /> ** La fonctionnalité de suppression récursive n'était pas implémentée dans &lt;code&gt;File.php&lt;/code&gt;.<br /> * Début de l'analyse du système de droit des utilisateurs (Administrateur/Tuteur/Elève) sur les fichiers et dossiers (hérités ou non).<br /> <br /> ==== Zoran ====<br /> * Compréhension des scanners sonar : voir [[SonarQube Scanner | compte-rendu]]<br /> * Mise en place d'un scan dans le pipeline<br /> ** Nécessité d'un serveur sonar exposé<br /> ** Décision d'utiliser SonarCloud<br /> ** Configuration du scanner pour envoyer le rapport dans le bon projet sonarcloud<br /> ** Réussite du premier scan<br /> <br /> === 06/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Suite de la correction du système de droits des fichiers/dossiers.<br /> <br /> * Correction d'un bug qui faisait que les utilisateurs ne peuvent pas entrer dans les dossiers hérites (ou télécharger les fichiers hérites).<br /> ** Le check de droit se fait dans une fonction qui check d'abord le &lt;code&gt;ownerId&lt;/code&gt;, puis le &lt;code&gt;projectId&lt;/code&gt; et puis enfin si le fichier appartient à un parent. Pour cela elle fait appel à la base pour récupérer la relation d’héritage. IL y avait une erreur de comparaison entre le résultat de la requête et les information fichier (erreur de type parce que PHP).<br /> * Analyse complète du système de droit création d'un tableau explicatif de l'état actuel et l'état voulu.<br /> [[File:EDCampus_2019_Tableau_de_droits.png|center]]<br /> * Suite au tableau, mise en place de la protection des fichiers hérités.<br /> ** Ajout d'une vérification sur le &lt;code&gt;projectId&lt;/code&gt;, empêchant les utilisateurs non propriétaires du fichier de le supprimer, renommer ou déplacer.<br /> <br /> ==== Zoran ====<br /> * Extension du scan sonar dans le pipeline à toutes les sections du projet<br /> * Affichage de badges d'état du pipeline sur la page de présentation de chaque section du projet<br /> * Reprise des recherches concernant les tests unitaires<br /> * Tentative de systématisation des tests dans le pipeline<br /> ** Difficulté : les tests nécessitent des fichiers de configurations qui ne sont pas présents sur le repository git<br /> * Recherche de contournement pour ne pas exposer des configurations privées dans le projet public<br /> <br /> === 08/02/19 ===<br /> <br /> ==== Servan ====<br /> Suppression de la vue pour les non membres et correction partielle du système de droits.<br /> * Lorsque qu'une commande est envoyée par le front-end vers le back-end, elle passe dans une fonction qui vérifie les droits (&lt;code&gt;Right.php checkRights($command)&lt;/code&gt;). La fonction compare la commande utilisée par l'utilisateur aux commandes que cet utilisateur a en général le droit d'utiliser. Le problème était que le tableau de commandes au sein de la fonction (permettant la comparaison) contenait des commandes mal formatées. J'ai donc corrigé celle qui m'intéressais pour empêcher les non membres d'un projet à consulter les fichiers, et j'en ai profiter pour corriger toutes les autres.<br /> <br /> ==== Zoran ====<br /> * Configuration des scanners sonar dans le pipeline (redirection vers une branche du projet sonarcloud nommée selon la branche GitLab sur laquelle le pipeline est lancé)<br /> * Aide à la correction du système de droits<br /> * Réalisation de tâches mineures importantes pour le Hackaton<br /> ** Retirer la vidéo Waza de l'accueil de la plateforme<br /> ** Redirection de l'utilisateur vers la plateforme lorsqu'il accède à l'url du dossier : [[Apache mod_rewrite]]<br /> ** Correction de l'url donné lors de l'appel au service de mails pour la validation de compte<br /> <br /> == Semaine 3 ==<br /> <br /> === 12/02/19 ===<br /> <br /> ==== Servan ====<br /> * Systeme de droits entierement corrigé pour le cas des fichiers.<br /> ** Privilèges administrateurs.<br /> *** Dans la fonction qui verifie les droits &lt;code&gt;Right.php checkRights($command)&lt;/code&gt;, le cas de l'administrateur n'était pas vraiment traité. Il y avait un verification pour empecher tout utilisateur non administrateur d'executer une commande administrateur, mais sinon l'administrateur était traité comme un utilisateur lambda. J'ai donc ajouté un test permettant de donner les pleins pouvoirs. Presque. Il fallait aussi ajouter un test dans la fonction &lt;code&gt;File.php _checkFileAccess(...)&lt;/code&gt; qui pour certaines actions sur les fichiers, agit comme une surcouche à la fonction &lt;code&gt;checkRights&lt;/code&gt; (ce qui permet entre autres des actions sur les fichiers hérités pour le tuteur et les membres).<br /> ** Cas du déplacement de fichier hérités.<br /> *** Avec l'accord d'Anthony, on a conclu que le déplacement de fichier hérité était une mauvaise idée, donc cela reste non autorisé, même pour les admins.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être supprimés.<br /> ** Les appels à la base effectuait une comparaison avec un &lt;code&gt;LIKE&lt;/code&gt; au lieu d'un &lt;code&gt;=&lt;/code&gt; dans la requête SQL, ce qui ne marchait pas dans le cas présent.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être renommés.<br /> ** Le nom du fichier est traité et enregistré par le fichier JS, qui est non typé donc il decide que si le nom n'est que des numeros, alors ce ne sera pas une string. Or pour renommer le fichier, on veux modifer la partie du nom qui est avant le point (de l'extension), donc on fait un appel à &lt;code&gt;name.lastIndexOf(&quot;.&quot;);&lt;/code&gt;, qui s'execute eclusivement sur une string. J'ai donc realisé un &lt;code&gt;.toString()&lt;/code&gt; sur le nom à chaque fois que necessaire.<br /> * Correction du fait que lorsque l'on supprimait un fichier dans un dossier, on était renvoyé à la racine du projet plutot que dans le dossier.<br /> ** Il manquait un paramètre (le dossier) à la fonction &lt;code&gt;getFiles(...)&lt;/code&gt; appalée après la suppréssion.<br /> * Transformation du bouton &quot;Ajouter&quot; en deux boutons, un pour les dossiers, un pour les fichiers.<br /> <br /> ==== Zoran ====<br /> * Mise à Jour de templates de mail (&gt;100 templates)<br /> ** Remplacement des références à Waza Education par EDCampus<br /> ** Production d'une banière et remplacement de l'ancienne<br /> * Tests des fichiers de configuration des tests unitaires<br /> * Recherches sur le passage de l'HTTP vers HTTPS avec [https://letsencrypt.org/ Let's Encrypt] : voir le [[Let's Encrypt | résumé rapide]]<br /> ** Choix d'utilisation de [https://certbot.eff.org/ Certbot]<br /> <br /> === 13/02/19 ===<br /> <br /> ==== Servan ====<br /> Nouvelle tâche assignée : Améliorer les tâches, faire en sorte que si un nom est placé sur un label d'une couleur au sein d'un projet, tous les labels de cette couleur auront ce même nom.<br /> <br /> ==== Zoran ====<br /> * Sauvegarde de la base de données de l'ancienne plateforme<br /> * Passage de l'ancienne plateforme de l'HTTP à l'HTTPS<br /> ** Réparation de la configuration d'Apache<br /> ** Génération des certificats<br /> ** Configuration d'Apache pour l'HTTPS<br /> <br /> === 14/02/19 ===<br /> <br /> ==== Servan ====<br /> * Backend corrigé, on ne peux plus créer une tache d'un nom au choix si il y a deja une tache de cette couleur avec un nom dans le projet.<br /> * Etude approfondie du front-end et du systeme evenementiel pour corriger les defauts de mise à jour.<br /> <br /> ==== Zoran ====<br /> * Recherches sur l'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Découverte et compréhension d'une [https://github.com/BirgerK/docker-apache-letsencrypt image existante]<br /> * Tentative de passage de l'HTTP à l'HTTPS dans un Docker<br /> ** Sur la VM de l'ancienne plateforme (pour ne pas briser la version en prod)<br /> ** Fusion du Dockerfile existant et du Dockerfile de l'image trouvée<br /> <br /> === 15/02/19 ===<br /> <br /> ==== Servan ====<br /> * Correction superficielle des problemes des mise a jour a de la vue du systeme de tache. Le soucis etant que les taches et le petit menu qui indique les details ne sont pas le même module et n'interagissent pas vraiment entre eux, donc on ne peux pas actualier l'un depuis l'autre.<br /> * Correction du fait que dans le systeme de fichier, on ne pouvait pas délacer un fichier/dossier vers le dossier parent en le glissant sur la flèche retour. <br /> ** Le soucis venait du fichier html, qui avait l'air correct mais la variable qu'il etait censé recuppérer renvoyait undefined au lieu de l'identifiant du dossier parent.<br /> <br /> ==== Zoran ====<br /> * Poursuite de la tentative d'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Succès de la création de certificat<br /> ** L'HTTPS ne fonctionne toujours pas (sans doute à cause de la configuration d'Apache)<br /> <br /> == Semaine 4 ==<br /> <br /> Hack ton campus.<br /> <br /> == Semaine 5 ==<br /> <br /> === 05/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====<br /> <br /> === 06/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====<br /> <br /> === 07/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====<br /> <br /> === 08/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====</div>

Zoran.Chanet https://air.imag.fr/index.php?title=PROJET-INFO5_1819_EDCampus&diff=45132 2019-03-04T08:48:31Z

<p>Zoran.Chanet: /* Zoran */</p> <hr /> <div>[[File:Logo_EDCampus.png|thumb|right| Logo EDCampus]]<br /> = Le projet en quelques mots =<br /> La plateforme [[Contributions open-source au projet Eclipse EdCampus | EDCampus]] est une plateforme de gestion de projet développé par Disrupt Campus Grenoble. La plateforme est actuellement en train d’être soumis à la fondation Eclipse afin d’être mise en open source sous licence Eclipse. Dans le cadre du projet Disrupt Campus, les étudiants sont invités à contribuer à la plateforme. Dans le cadre de vos formations c’est une vraie plus value de contribuer à de réels projets plutôt qu’à des projets one-shot qui seront mis à la poubelle sitôt votre soutenance terminée. EDCampus est donc une opportunité de contribuer au logiciel libre et à la fondation Eclipse (et de s'assurer une jolie ligne sur son CV plutôt qu'un projet qui sera aussi vite oublié que l'ECOM !). <br /> <br /> = L'équipe et leurs rôles =<br /> <br /> * GEOURJON Anthony - Chef de projet (EXT)<br /> * [[User:Servan.Charlot | CHARLOT Servan]] - Chef de groupe<br /> * [[User:Zoran.Chanet | CHANET Zoran]] - Responsable DevOps<br /> <br /> = Roadmap =<br /> * '''20-22 février 2019 :''' Hack Ton Campus, la plateforme EDCampus sera utilisée pour la gestion des défis.<br /> * '''Avril 2019 :''' Projet pilote, un projet mêlant une entreprise, l'UGA et des étudiants servira de test à la plateforme.<br /> * '''Septembre 2019 :''' Mise en production globale.<br /> <br /> = Carnet de bord =<br /> <br /> == Semaine 1 ==<br /> <br /> === 28/01/19 ===<br /> <br /> Assignation du sujet [[Contributions open-source au projet Eclipse EdCampus | EDCampus]].<br /> <br /> === 29/01/19 ===<br /> <br /> * Rencontre avec Anthony au [http://fabmstic.liglab.fr/ Fablab], presentation du sujet, des enjeux, et de la roadmap<br /> * Installation du projet<br /> ** Difficultés dues au DNS des réseaux universitaires (impossible de télécharger le contenu nécessaire depuis les containers)<br /> <br /> === 30/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $scope._getProjectParent()&lt;/code&gt; qui ne marchait pas du tout. Il y avait une faute dans la plupart des variables qui s'appelaient &lt;code&gt;currentParentProject&lt;/code&gt; au lieu de &lt;code&gt;currentProjectParent&lt;/code&gt;.<br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $rootScope._checkProject()&lt;/code&gt; qui oubliait un paramètre dans son appel à &lt;code&gt;$scope._setProject()&lt;/code&gt;.<br /> <br /> ==== Zoran ====<br /> * Assignation d'une première tâche : réparer la création d'un projet indépendant<br /> * Découverte du code du projet<br /> * Poursuite de l'arborescence des appels depuis le bouton jusqu'à l'appel à la base de données<br /> <br /> === 01/02/19 ===<br /> ==== Servan ====<br /> <br /> * Assignation de la tâche consistant à réparer le système de fichier.<br /> * Exploration du systeme de fichier et son implementation.<br /> <br /> ==== Zoran ====<br /> * Production d'une méthode permettant des logs personnalisés<br /> * Recherches sur le rewriting d'URL<br /> * Correction du problème (lié au rewriting)<br /> * Production d'une fiche explicative de la solution<br /> <br /> == Semaine 2 ==<br /> <br /> === 04/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction des bugs suivants :<br /> <br /> * Affichage des fichiers du portefeuille père ssi il y a au moins un fichier présent dans le projet fils.<br /> ** Dans le backend, la fonction qui get les fichiers exécutait un &lt;code&gt;return false&lt;/code&gt; avant de get les fichiers parents dans le cas ou il n'y avait pas de fichier à la base.<br /> * N'actualise pas la liste des fichiers si on supprime le dernier fichier.<br /> * Tous les dossiers sont affichés comme des fichiers. Lors de la première sélection à la souris, si on sélectionne le fichier-dossier, il se transforme en dossier et on peut y accéder. Rien ne se passe pour les sélections suivantes.<br /> ** Dans le backend, un paramètre était traité comme chaîne de caractère alors qu'il représentait un booléen. Le résultat de ça est que l'on entrait dans la mauvaise partie d'un if, qui exécutait la mauvaise requête SQL nous privant de l'information concernant le type de fichier lu (un dossier est un type de fichier).<br /> * Le bouton qui permet de revenir en arrière, sortir du dossier ne fonctionne pas.<br /> * On ne peut pas entrer dans un dossier hérité.<br /> <br /> ==== Zoran ====<br /> * Assignation de la mise en place de techniques DevOps<br /> * Recherches sur la mise en place de pipeline dans GitLab : voir [[GitLab CI/CD | compte-rendu]]<br /> * Mise en place d'un pipeline à chaque push<br /> * Production d'un tutoriel de création de runner GitLab : voir [[GitLab Runners | tutoriel]]<br /> * Recherches sur SonarQube et les tests unitaires<br /> ** Priorisation de SonarQube<br /> <br /> === 05/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug qui faisait que lors de la suppression d'un dossier, les fichiers à l'intérieur ne sont pas supprimés (le champ statut dans le BDD ne passe pas à 0).<br /> ** La fonctionnalité de suppression récursive n'était pas implémentée dans &lt;code&gt;File.php&lt;/code&gt;.<br /> * Début de l'analyse du système de droit des utilisateurs (Administrateur/Tuteur/Elève) sur les fichiers et dossiers (hérités ou non).<br /> <br /> ==== Zoran ====<br /> * Compréhension des scanners sonar : voir [[SonarQube Scanner | compte-rendu]]<br /> * Mise en place d'un scan dans le pipeline<br /> ** Nécessité d'un serveur sonar exposé<br /> ** Décision d'utiliser SonarCloud<br /> ** Configuration du scanner pour envoyer le rapport dans le bon projet sonarcloud<br /> ** Réussite du premier scan<br /> <br /> === 06/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Suite de la correction du système de droits des fichiers/dossiers.<br /> <br /> * Correction d'un bug qui faisait que les utilisateurs ne peuvent pas entrer dans les dossiers hérites (ou télécharger les fichiers hérites).<br /> ** Le check de droit se fait dans une fonction qui check d'abord le &lt;code&gt;ownerId&lt;/code&gt;, puis le &lt;code&gt;projectId&lt;/code&gt; et puis enfin si le fichier appartient à un parent. Pour cela elle fait appel à la base pour récupérer la relation d’héritage. IL y avait une erreur de comparaison entre le résultat de la requête et les information fichier (erreur de type parce que PHP).<br /> * Analyse complète du système de droit création d'un tableau explicatif de l'état actuel et l'état voulu.<br /> [[File:EDCampus_2019_Tableau_de_droits.png|center]]<br /> * Suite au tableau, mise en place de la protection des fichiers hérités.<br /> ** Ajout d'une vérification sur le &lt;code&gt;projectId&lt;/code&gt;, empêchant les utilisateurs non propriétaires du fichier de le supprimer, renommer ou déplacer.<br /> <br /> ==== Zoran ====<br /> * Extension du scan sonar dans le pipeline à toutes les sections du projet<br /> * Affichage de badges d'état du pipeline sur la page de présentation de chaque section du projet<br /> * Reprise des recherches concernant les tests unitaires<br /> * Tentative de systématisation des tests dans le pipeline<br /> ** Difficulté : les tests nécessitent des fichiers de configurations qui ne sont pas présents sur le repository git<br /> * Recherche de contournement pour ne pas exposer des configurations privées dans le projet public<br /> <br /> === 08/02/19 ===<br /> <br /> ==== Servan ====<br /> Suppression de la vue pour les non membres et correction partielle du système de droits.<br /> * Lorsque qu'une commande est envoyée par le front-end vers le back-end, elle passe dans une fonction qui vérifie les droits (&lt;code&gt;Right.php checkRights($command)&lt;/code&gt;). La fonction compare la commande utilisée par l'utilisateur aux commandes que cet utilisateur a en général le droit d'utiliser. Le problème était que le tableau de commandes au sein de la fonction (permettant la comparaison) contenait des commandes mal formatées. J'ai donc corrigé celle qui m'intéressais pour empêcher les non membres d'un projet à consulter les fichiers, et j'en ai profiter pour corriger toutes les autres.<br /> <br /> ==== Zoran ====<br /> * Configuration des scanners sonar dans le pipeline (redirection vers une branche du projet sonarcloud nommée selon la branche GitLab sur laquelle le pipeline est lancé)<br /> * Aide à la correction du système de droits<br /> * Réalisation de tâches mineures importantes pour le Hackaton<br /> ** Retirer la vidéo Waza de l'accueil de la plateforme<br /> ** Redirection de l'utilisateur vers la plateforme lorsqu'il accède à l'url du dossier : [[Apache mod_rewrite]]<br /> ** Correction de l'url donné lors de l'appel au service de mails pour la validation de compte<br /> <br /> == Semaine 3 ==<br /> <br /> === 12/02/19 ===<br /> <br /> ==== Servan ====<br /> * Systeme de droits entierement corrigé pour le cas des fichiers.<br /> ** Privilèges administrateurs.<br /> *** Dans la fonction qui verifie les droits &lt;code&gt;Right.php checkRights($command)&lt;/code&gt;, le cas de l'administrateur n'était pas vraiment traité. Il y avait un verification pour empecher tout utilisateur non administrateur d'executer une commande administrateur, mais sinon l'administrateur était traité comme un utilisateur lambda. J'ai donc ajouté un test permettant de donner les pleins pouvoirs. Presque. Il fallait aussi ajouter un test dans la fonction &lt;code&gt;File.php _checkFileAccess(...)&lt;/code&gt; qui pour certaines actions sur les fichiers, agit comme une surcouche à la fonction &lt;code&gt;checkRights&lt;/code&gt; (ce qui permet entre autres des actions sur les fichiers hérités pour le tuteur et les membres).<br /> ** Cas du déplacement de fichier hérités.<br /> *** Avec l'accord d'Anthony, on a conclu que le déplacement de fichier hérité était une mauvaise idée, donc cela reste non autorisé, même pour les admins.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être supprimés.<br /> ** Les appels à la base effectuait une comparaison avec un &lt;code&gt;LIKE&lt;/code&gt; au lieu d'un &lt;code&gt;=&lt;/code&gt; dans la requête SQL, ce qui ne marchait pas dans le cas présent.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être renommés.<br /> ** Le nom du fichier est traité et enregistré par le fichier JS, qui est non typé donc il decide que si le nom n'est que des numeros, alors ce ne sera pas une string. Or pour renommer le fichier, on veux modifer la partie du nom qui est avant le point (de l'extension), donc on fait un appel à &lt;code&gt;name.lastIndexOf(&quot;.&quot;);&lt;/code&gt;, qui s'execute eclusivement sur une string. J'ai donc realisé un &lt;code&gt;.toString()&lt;/code&gt; sur le nom à chaque fois que necessaire.<br /> * Correction du fait que lorsque l'on supprimait un fichier dans un dossier, on était renvoyé à la racine du projet plutot que dans le dossier.<br /> ** Il manquait un paramètre (le dossier) à la fonction &lt;code&gt;getFiles(...)&lt;/code&gt; appalée après la suppréssion.<br /> * Transformation du bouton &quot;Ajouter&quot; en deux boutons, un pour les dossiers, un pour les fichiers.<br /> <br /> ==== Zoran ====<br /> * Mise à Jour de templates de mail (&gt;100 templates)<br /> ** Remplacement des références à Waza Education par EDCampus<br /> ** Production d'une banière et remplacement de l'ancienne<br /> * Tests des fichiers de configuration des tests unitaires<br /> * Recherches sur le passage de l'HTTP vers HTTPS avec [https://letsencrypt.org/ Let's Encrypt] : voir le [[Let's Encrypt | résumé rapide]]<br /> ** Choix d'utilisation de [https://certbot.eff.org/ Certbot]<br /> <br /> === 13/02/19 ===<br /> <br /> ==== Servan ====<br /> Nouvelle tâche assignée : Améliorer les tâches, faire en sorte que si un nom est placé sur un label d'une couleur au sein d'un projet, tous les labels de cette couleur auront ce même nom.<br /> <br /> ==== Zoran ====<br /> * Sauvegarde de la base de données de l'ancienne plateforme<br /> * Passage de l'ancienne plateforme de l'HTTP à l'HTTPS<br /> ** Réparation de la configuration d'Apache<br /> ** Génération des certificats<br /> ** Configuration d'Apache pour l'HTTPS<br /> <br /> === 14/02/19 ===<br /> <br /> ==== Servan ====<br /> * Backend corrigé, on ne peux plus créer une tache d'un nom au choix si il y a deja une tache de cette couleur avec un nom dans le projet.<br /> * Etude approfondie du front-end et du systeme evenementiel pour corriger les defauts de mise à jour.<br /> <br /> ==== Zoran ====<br /> * Recherches sur l'utilisation de [[Let's Encrypt]] avec [[Docker]]<br /> ** Découverte et compréhension d'une [https://github.com/BirgerK/docker-apache-letsencrypt image existante]<br /> * Tentative de passage de l'HTTP à l'HTTPS dans un Docker<br /> ** Sur la VM de l'ancienne plateforme (pour ne pas briser la version en prod)<br /> ** Fusion du Dockerfile existant et du Dockerfile de l'image trouvée<br /> <br /> === 15/02/19 ===<br /> <br /> ==== Servan ====<br /> * Correction superficielle des problemes des mise a jour a de la vue du systeme de tache. Le soucis etant que les taches et le petit menu qui indique les details ne sont pas le même module et n'interagissent pas vraiment entre eux, donc on ne peux pas actualier l'un depuis l'autre.<br /> * Correction du fait que dans le systeme de fichier, on ne pouvait pas délacer un fichier/dossier vers le dossier parent en le glissant sur la flèche retour. <br /> ** Le soucis venait du fichier html, qui avait l'air correct mais la variable qu'il etait censé recuppérer renvoyait undefined au lieu de l'identifiant du dossier parent.<br /> <br /> ==== Zoran ====<br /> <br /> == Semaine 4 ==<br /> <br /> Hack ton campus.<br /> <br /> == Semaine 5 ==<br /> <br /> === 05/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====<br /> <br /> === 06/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====<br /> <br /> === 07/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====<br /> <br /> === 08/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====</div>

Zoran.Chanet https://air.imag.fr/index.php?title=PROJET-INFO5_1819_EDCampus&diff=45131 2019-03-04T08:39:07Z

<p>Zoran.Chanet: /* Zoran */</p> <hr /> <div>[[File:Logo_EDCampus.png|thumb|right| Logo EDCampus]]<br /> = Le projet en quelques mots =<br /> La plateforme [[Contributions open-source au projet Eclipse EdCampus | EDCampus]] est une plateforme de gestion de projet développé par Disrupt Campus Grenoble. La plateforme est actuellement en train d’être soumis à la fondation Eclipse afin d’être mise en open source sous licence Eclipse. Dans le cadre du projet Disrupt Campus, les étudiants sont invités à contribuer à la plateforme. Dans le cadre de vos formations c’est une vraie plus value de contribuer à de réels projets plutôt qu’à des projets one-shot qui seront mis à la poubelle sitôt votre soutenance terminée. EDCampus est donc une opportunité de contribuer au logiciel libre et à la fondation Eclipse (et de s'assurer une jolie ligne sur son CV plutôt qu'un projet qui sera aussi vite oublié que l'ECOM !). <br /> <br /> = L'équipe et leurs rôles =<br /> <br /> * GEOURJON Anthony - Chef de projet (EXT)<br /> * [[User:Servan.Charlot | CHARLOT Servan]] - Chef de groupe<br /> * [[User:Zoran.Chanet | CHANET Zoran]] - Responsable DevOps<br /> <br /> = Roadmap =<br /> * '''20-22 février 2019 :''' Hack Ton Campus, la plateforme EDCampus sera utilisée pour la gestion des défis.<br /> * '''Avril 2019 :''' Projet pilote, un projet mêlant une entreprise, l'UGA et des étudiants servira de test à la plateforme.<br /> * '''Septembre 2019 :''' Mise en production globale.<br /> <br /> = Carnet de bord =<br /> <br /> == Semaine 1 ==<br /> <br /> === 28/01/19 ===<br /> <br /> Assignation du sujet [[Contributions open-source au projet Eclipse EdCampus | EDCampus]].<br /> <br /> === 29/01/19 ===<br /> <br /> * Rencontre avec Anthony au [http://fabmstic.liglab.fr/ Fablab], presentation du sujet, des enjeux, et de la roadmap<br /> * Installation du projet<br /> ** Difficultés dues au DNS des réseaux universitaires (impossible de télécharger le contenu nécessaire depuis les containers)<br /> <br /> === 30/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $scope._getProjectParent()&lt;/code&gt; qui ne marchait pas du tout. Il y avait une faute dans la plupart des variables qui s'appelaient &lt;code&gt;currentParentProject&lt;/code&gt; au lieu de &lt;code&gt;currentProjectParent&lt;/code&gt;.<br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $rootScope._checkProject()&lt;/code&gt; qui oubliait un paramètre dans son appel à &lt;code&gt;$scope._setProject()&lt;/code&gt;.<br /> <br /> ==== Zoran ====<br /> * Assignation d'une première tâche : réparer la création d'un projet indépendant<br /> * Découverte du code du projet<br /> * Poursuite de l'arborescence des appels depuis le bouton jusqu'à l'appel à la base de données<br /> <br /> === 01/02/19 ===<br /> ==== Servan ====<br /> <br /> * Assignation de la tâche consistant à réparer le système de fichier.<br /> * Exploration du systeme de fichier et son implementation.<br /> <br /> ==== Zoran ====<br /> * Production d'une méthode permettant des logs personnalisés<br /> * Recherches sur le rewriting d'URL<br /> * Correction du problème (lié au rewriting)<br /> * Production d'une fiche explicative de la solution<br /> <br /> == Semaine 2 ==<br /> <br /> === 04/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction des bugs suivants :<br /> <br /> * Affichage des fichiers du portefeuille père ssi il y a au moins un fichier présent dans le projet fils.<br /> ** Dans le backend, la fonction qui get les fichiers exécutait un &lt;code&gt;return false&lt;/code&gt; avant de get les fichiers parents dans le cas ou il n'y avait pas de fichier à la base.<br /> * N'actualise pas la liste des fichiers si on supprime le dernier fichier.<br /> * Tous les dossiers sont affichés comme des fichiers. Lors de la première sélection à la souris, si on sélectionne le fichier-dossier, il se transforme en dossier et on peut y accéder. Rien ne se passe pour les sélections suivantes.<br /> ** Dans le backend, un paramètre était traité comme chaîne de caractère alors qu'il représentait un booléen. Le résultat de ça est que l'on entrait dans la mauvaise partie d'un if, qui exécutait la mauvaise requête SQL nous privant de l'information concernant le type de fichier lu (un dossier est un type de fichier).<br /> * Le bouton qui permet de revenir en arrière, sortir du dossier ne fonctionne pas.<br /> * On ne peut pas entrer dans un dossier hérité.<br /> <br /> ==== Zoran ====<br /> * Assignation de la mise en place de techniques DevOps<br /> * Recherches sur la mise en place de pipeline dans GitLab : voir [[GitLab CI/CD | compte-rendu]]<br /> * Mise en place d'un pipeline à chaque push<br /> * Production d'un tutoriel de création de runner GitLab : voir [[GitLab Runners | tutoriel]]<br /> * Recherches sur SonarQube et les tests unitaires<br /> ** Priorisation de SonarQube<br /> <br /> === 05/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug qui faisait que lors de la suppression d'un dossier, les fichiers à l'intérieur ne sont pas supprimés (le champ statut dans le BDD ne passe pas à 0).<br /> ** La fonctionnalité de suppression récursive n'était pas implémentée dans &lt;code&gt;File.php&lt;/code&gt;.<br /> * Début de l'analyse du système de droit des utilisateurs (Administrateur/Tuteur/Elève) sur les fichiers et dossiers (hérités ou non).<br /> <br /> ==== Zoran ====<br /> * Compréhension des scanners sonar : voir [[SonarQube Scanner | compte-rendu]]<br /> * Mise en place d'un scan dans le pipeline<br /> ** Nécessité d'un serveur sonar exposé<br /> ** Décision d'utiliser SonarCloud<br /> ** Configuration du scanner pour envoyer le rapport dans le bon projet sonarcloud<br /> ** Réussite du premier scan<br /> <br /> === 06/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Suite de la correction du système de droits des fichiers/dossiers.<br /> <br /> * Correction d'un bug qui faisait que les utilisateurs ne peuvent pas entrer dans les dossiers hérites (ou télécharger les fichiers hérites).<br /> ** Le check de droit se fait dans une fonction qui check d'abord le &lt;code&gt;ownerId&lt;/code&gt;, puis le &lt;code&gt;projectId&lt;/code&gt; et puis enfin si le fichier appartient à un parent. Pour cela elle fait appel à la base pour récupérer la relation d’héritage. IL y avait une erreur de comparaison entre le résultat de la requête et les information fichier (erreur de type parce que PHP).<br /> * Analyse complète du système de droit création d'un tableau explicatif de l'état actuel et l'état voulu.<br /> [[File:EDCampus_2019_Tableau_de_droits.png|center]]<br /> * Suite au tableau, mise en place de la protection des fichiers hérités.<br /> ** Ajout d'une vérification sur le &lt;code&gt;projectId&lt;/code&gt;, empêchant les utilisateurs non propriétaires du fichier de le supprimer, renommer ou déplacer.<br /> <br /> ==== Zoran ====<br /> * Extension du scan sonar dans le pipeline à toutes les sections du projet<br /> * Affichage de badges d'état du pipeline sur la page de présentation de chaque section du projet<br /> * Reprise des recherches concernant les tests unitaires<br /> * Tentative de systématisation des tests dans le pipeline<br /> ** Difficulté : les tests nécessitent des fichiers de configurations qui ne sont pas présents sur le repository git<br /> * Recherche de contournement pour ne pas exposer des configurations privées dans le projet public<br /> <br /> === 08/02/19 ===<br /> <br /> ==== Servan ====<br /> Suppression de la vue pour les non membres et correction partielle du système de droits.<br /> * Lorsque qu'une commande est envoyée par le front-end vers le back-end, elle passe dans une fonction qui vérifie les droits (&lt;code&gt;Right.php checkRights($command)&lt;/code&gt;). La fonction compare la commande utilisée par l'utilisateur aux commandes que cet utilisateur a en général le droit d'utiliser. Le problème était que le tableau de commandes au sein de la fonction (permettant la comparaison) contenait des commandes mal formatées. J'ai donc corrigé celle qui m'intéressais pour empêcher les non membres d'un projet à consulter les fichiers, et j'en ai profiter pour corriger toutes les autres.<br /> <br /> ==== Zoran ====<br /> * Configuration des scanners sonar dans le pipeline (redirection vers une branche du projet sonarcloud nommée selon la branche GitLab sur laquelle le pipeline est lancé)<br /> * Aide à la correction du système de droits<br /> * Réalisation de tâches mineures importantes pour le Hackaton<br /> ** Retirer la vidéo Waza de l'accueil de la plateforme<br /> ** Redirection de l'utilisateur vers la plateforme lorsqu'il accède à l'url du dossier : [[Apache mod_rewrite]]<br /> ** Correction de l'url donné lors de l'appel au service de mails pour la validation de compte<br /> <br /> == Semaine 3 ==<br /> <br /> === 12/02/19 ===<br /> <br /> ==== Servan ====<br /> * Systeme de droits entierement corrigé pour le cas des fichiers.<br /> ** Privilèges administrateurs.<br /> *** Dans la fonction qui verifie les droits &lt;code&gt;Right.php checkRights($command)&lt;/code&gt;, le cas de l'administrateur n'était pas vraiment traité. Il y avait un verification pour empecher tout utilisateur non administrateur d'executer une commande administrateur, mais sinon l'administrateur était traité comme un utilisateur lambda. J'ai donc ajouté un test permettant de donner les pleins pouvoirs. Presque. Il fallait aussi ajouter un test dans la fonction &lt;code&gt;File.php _checkFileAccess(...)&lt;/code&gt; qui pour certaines actions sur les fichiers, agit comme une surcouche à la fonction &lt;code&gt;checkRights&lt;/code&gt; (ce qui permet entre autres des actions sur les fichiers hérités pour le tuteur et les membres).<br /> ** Cas du déplacement de fichier hérités.<br /> *** Avec l'accord d'Anthony, on a conclu que le déplacement de fichier hérité était une mauvaise idée, donc cela reste non autorisé, même pour les admins.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être supprimés.<br /> ** Les appels à la base effectuait une comparaison avec un &lt;code&gt;LIKE&lt;/code&gt; au lieu d'un &lt;code&gt;=&lt;/code&gt; dans la requête SQL, ce qui ne marchait pas dans le cas présent.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être renommés.<br /> ** Le nom du fichier est traité et enregistré par le fichier JS, qui est non typé donc il decide que si le nom n'est que des numeros, alors ce ne sera pas une string. Or pour renommer le fichier, on veux modifer la partie du nom qui est avant le point (de l'extension), donc on fait un appel à &lt;code&gt;name.lastIndexOf(&quot;.&quot;);&lt;/code&gt;, qui s'execute eclusivement sur une string. J'ai donc realisé un &lt;code&gt;.toString()&lt;/code&gt; sur le nom à chaque fois que necessaire.<br /> * Correction du fait que lorsque l'on supprimait un fichier dans un dossier, on était renvoyé à la racine du projet plutot que dans le dossier.<br /> ** Il manquait un paramètre (le dossier) à la fonction &lt;code&gt;getFiles(...)&lt;/code&gt; appalée après la suppréssion.<br /> * Transformation du bouton &quot;Ajouter&quot; en deux boutons, un pour les dossiers, un pour les fichiers.<br /> <br /> ==== Zoran ====<br /> * Mise à Jour de templates de mail (&gt;100 templates)<br /> ** Remplacement des références à Waza Education par EDCampus<br /> ** Production d'une banière et remplacement de l'ancienne<br /> * Tests des fichiers de configuration des tests unitaires<br /> * Recherches sur le passage de l'HTTP vers HTTPS avec [https://letsencrypt.org/ Let's Encrypt] : voir le [[Let's Encrypt | résumé rapide]]<br /> ** Choix d'utilisation de [https://certbot.eff.org/ Certbot]<br /> <br /> === 13/02/19 ===<br /> <br /> ==== Servan ====<br /> Nouvelle tâche assignée : Améliorer les tâches, faire en sorte que si un nom est placé sur un label d'une couleur au sein d'un projet, tous les labels de cette couleur auront ce même nom.<br /> <br /> ==== Zoran ====<br /> * Sauvegarde de la base de données de l'ancienne plateforme<br /> * Passage de l'ancienne plateforme de l'HTTP à l'HTTPS<br /> ** Réparation de la configuration d'Apache<br /> ** Génération des certificats<br /> ** Configuration d'Apache pour l'HTTPS<br /> <br /> === 14/02/19 ===<br /> <br /> ==== Servan ====<br /> * Backend corrigé, on ne peux plus créer une tache d'un nom au choix si il y a deja une tache de cette couleur avec un nom dans le projet.<br /> * Etude approfondie du front-end et du systeme evenementiel pour corriger les defauts de mise à jour.<br /> <br /> ==== Zoran ====<br /> <br /> === 15/02/19 ===<br /> <br /> ==== Servan ====<br /> * Correction superficielle des problemes des mise a jour a de la vue du systeme de tache. Le soucis etant que les taches et le petit menu qui indique les details ne sont pas le même module et n'interagissent pas vraiment entre eux, donc on ne peux pas actualier l'un depuis l'autre.<br /> * Correction du fait que dans le systeme de fichier, on ne pouvait pas délacer un fichier/dossier vers le dossier parent en le glissant sur la flèche retour. <br /> ** Le soucis venait du fichier html, qui avait l'air correct mais la variable qu'il etait censé recuppérer renvoyait undefined au lieu de l'identifiant du dossier parent.<br /> <br /> ==== Zoran ====<br /> <br /> == Semaine 4 ==<br /> <br /> Hack ton campus.<br /> <br /> == Semaine 5 ==<br /> <br /> === 05/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====<br /> <br /> === 06/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====<br /> <br /> === 07/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====<br /> <br /> === 08/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====</div>

Zoran.Chanet https://air.imag.fr/index.php?title=PROJET-INFO5_1819_EDCampus&diff=45130 2019-03-04T08:23:16Z

<p>Zoran.Chanet: /* Zoran */</p> <hr /> <div>[[File:Logo_EDCampus.png|thumb|right| Logo EDCampus]]<br /> = Le projet en quelques mots =<br /> La plateforme [[Contributions open-source au projet Eclipse EdCampus | EDCampus]] est une plateforme de gestion de projet développé par Disrupt Campus Grenoble. La plateforme est actuellement en train d’être soumis à la fondation Eclipse afin d’être mise en open source sous licence Eclipse. Dans le cadre du projet Disrupt Campus, les étudiants sont invités à contribuer à la plateforme. Dans le cadre de vos formations c’est une vraie plus value de contribuer à de réels projets plutôt qu’à des projets one-shot qui seront mis à la poubelle sitôt votre soutenance terminée. EDCampus est donc une opportunité de contribuer au logiciel libre et à la fondation Eclipse (et de s'assurer une jolie ligne sur son CV plutôt qu'un projet qui sera aussi vite oublié que l'ECOM !). <br /> <br /> = L'équipe et leurs rôles =<br /> <br /> * GEOURJON Anthony - Chef de projet (EXT)<br /> * [[User:Servan.Charlot | CHARLOT Servan]] - Chef de groupe<br /> * [[User:Zoran.Chanet | CHANET Zoran]] - Responsable DevOps<br /> <br /> = Roadmap =<br /> * '''20-22 février 2019 :''' Hack Ton Campus, la plateforme EDCampus sera utilisée pour la gestion des défis.<br /> * '''Avril 2019 :''' Projet pilote, un projet mêlant une entreprise, l'UGA et des étudiants servira de test à la plateforme.<br /> * '''Septembre 2019 :''' Mise en production globale.<br /> <br /> = Carnet de bord =<br /> <br /> == Semaine 1 ==<br /> <br /> === 28/01/19 ===<br /> <br /> Assignation du sujet [[Contributions open-source au projet Eclipse EdCampus | EDCampus]].<br /> <br /> === 29/01/19 ===<br /> <br /> * Rencontre avec Anthony au [http://fabmstic.liglab.fr/ Fablab], presentation du sujet, des enjeux, et de la roadmap<br /> * Installation du projet<br /> ** Difficultés dues au DNS des réseaux universitaires (impossible de télécharger le contenu nécessaire depuis les containers)<br /> <br /> === 30/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $scope._getProjectParent()&lt;/code&gt; qui ne marchait pas du tout. Il y avait une faute dans la plupart des variables qui s'appelaient &lt;code&gt;currentParentProject&lt;/code&gt; au lieu de &lt;code&gt;currentProjectParent&lt;/code&gt;.<br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $rootScope._checkProject()&lt;/code&gt; qui oubliait un paramètre dans son appel à &lt;code&gt;$scope._setProject()&lt;/code&gt;.<br /> <br /> ==== Zoran ====<br /> * Assignation d'une première tâche : réparer la création d'un projet indépendant<br /> * Découverte du code du projet<br /> * Poursuite de l'arborescence des appels depuis le bouton jusqu'à l'appel à la base de données<br /> <br /> === 01/02/19 ===<br /> ==== Servan ====<br /> <br /> * Assignation de la tâche consistant à réparer le système de fichier.<br /> * Exploration du systeme de fichier et son implementation.<br /> <br /> ==== Zoran ====<br /> * Production d'une méthode permettant des logs personnalisés<br /> * Recherches sur le rewriting d'URL<br /> * Correction du problème (lié au rewriting)<br /> * Production d'une fiche explicative de la solution<br /> <br /> == Semaine 2 ==<br /> <br /> === 04/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction des bugs suivants :<br /> <br /> * Affichage des fichiers du portefeuille père ssi il y a au moins un fichier présent dans le projet fils.<br /> ** Dans le backend, la fonction qui get les fichiers exécutait un &lt;code&gt;return false&lt;/code&gt; avant de get les fichiers parents dans le cas ou il n'y avait pas de fichier à la base.<br /> * N'actualise pas la liste des fichiers si on supprime le dernier fichier.<br /> * Tous les dossiers sont affichés comme des fichiers. Lors de la première sélection à la souris, si on sélectionne le fichier-dossier, il se transforme en dossier et on peut y accéder. Rien ne se passe pour les sélections suivantes.<br /> ** Dans le backend, un paramètre était traité comme chaîne de caractère alors qu'il représentait un booléen. Le résultat de ça est que l'on entrait dans la mauvaise partie d'un if, qui exécutait la mauvaise requête SQL nous privant de l'information concernant le type de fichier lu (un dossier est un type de fichier).<br /> * Le bouton qui permet de revenir en arrière, sortir du dossier ne fonctionne pas.<br /> * On ne peut pas entrer dans un dossier hérité.<br /> <br /> ==== Zoran ====<br /> * Assignation de la mise en place de techniques DevOps<br /> * Recherches sur la mise en place de pipeline dans GitLab : voir [[GitLab CI/CD | compte-rendu]]<br /> * Mise en place d'un pipeline à chaque push<br /> * Production d'un tutoriel de création de runner GitLab : voir [[GitLab Runners | tutoriel]]<br /> * Recherches sur SonarQube et les tests unitaires<br /> ** Priorisation de SonarQube<br /> <br /> === 05/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug qui faisait que lors de la suppression d'un dossier, les fichiers à l'intérieur ne sont pas supprimés (le champ statut dans le BDD ne passe pas à 0).<br /> ** La fonctionnalité de suppression récursive n'était pas implémentée dans &lt;code&gt;File.php&lt;/code&gt;.<br /> * Début de l'analyse du système de droit des utilisateurs (Administrateur/Tuteur/Elève) sur les fichiers et dossiers (hérités ou non).<br /> <br /> ==== Zoran ====<br /> * Compréhension des scanners sonar : voir [[SonarQube Scanner | compte-rendu]]<br /> * Mise en place d'un scan dans le pipeline<br /> ** Nécessité d'un serveur sonar exposé<br /> ** Décision d'utiliser SonarCloud<br /> ** Configuration du scanner pour envoyer le rapport dans le bon projet sonarcloud<br /> ** Réussite du premier scan<br /> <br /> === 06/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Suite de la correction du système de droits des fichiers/dossiers.<br /> <br /> * Correction d'un bug qui faisait que les utilisateurs ne peuvent pas entrer dans les dossiers hérites (ou télécharger les fichiers hérites).<br /> ** Le check de droit se fait dans une fonction qui check d'abord le &lt;code&gt;ownerId&lt;/code&gt;, puis le &lt;code&gt;projectId&lt;/code&gt; et puis enfin si le fichier appartient à un parent. Pour cela elle fait appel à la base pour récupérer la relation d’héritage. IL y avait une erreur de comparaison entre le résultat de la requête et les information fichier (erreur de type parce que PHP).<br /> * Analyse complète du système de droit création d'un tableau explicatif de l'état actuel et l'état voulu.<br /> [[File:EDCampus_2019_Tableau_de_droits.png|center]]<br /> * Suite au tableau, mise en place de la protection des fichiers hérités.<br /> ** Ajout d'une vérification sur le &lt;code&gt;projectId&lt;/code&gt;, empêchant les utilisateurs non propriétaires du fichier de le supprimer, renommer ou déplacer.<br /> <br /> ==== Zoran ====<br /> * Extension du scan sonar dans le pipeline à toutes les sections du projet<br /> * Affichage de badges d'état du pipeline sur la page de présentation de chaque section du projet<br /> * Reprise des recherches concernant les tests unitaires<br /> * Tentative de systématisation des tests dans le pipeline<br /> ** Difficulté : les tests nécessitent des fichiers de configurations qui ne sont pas présents sur le repository git<br /> * Recherche de contournement pour ne pas exposer des configurations privées dans le projet public<br /> <br /> === 08/02/19 ===<br /> <br /> ==== Servan ====<br /> Suppression de la vue pour les non membres et correction partielle du système de droits.<br /> * Lorsque qu'une commande est envoyée par le front-end vers le back-end, elle passe dans une fonction qui vérifie les droits (&lt;code&gt;Right.php checkRights($command)&lt;/code&gt;). La fonction compare la commande utilisée par l'utilisateur aux commandes que cet utilisateur a en général le droit d'utiliser. Le problème était que le tableau de commandes au sein de la fonction (permettant la comparaison) contenait des commandes mal formatées. J'ai donc corrigé celle qui m'intéressais pour empêcher les non membres d'un projet à consulter les fichiers, et j'en ai profiter pour corriger toutes les autres.<br /> <br /> ==== Zoran ====<br /> * Configuration des scanners sonar dans le pipeline (redirection vers une branche du projet sonarcloud nommée selon la branche GitLab sur laquelle le pipeline est lancé)<br /> * Aide à la correction du système de droits<br /> * Réalisation de tâches mineures importantes pour le Hackaton<br /> ** Retirer la vidéo Waza de l'accueil de la plateforme<br /> ** Redirection de l'utilisateur vers la plateforme lorsqu'il accède à l'url du dossier : [[Apache mod_rewrite]]<br /> ** Correction de l'url donné lors de l'appel au service de mails pour la validation de compte<br /> <br /> == Semaine 3 ==<br /> <br /> === 12/02/19 ===<br /> <br /> ==== Servan ====<br /> * Systeme de droits entierement corrigé pour le cas des fichiers.<br /> ** Privilèges administrateurs.<br /> *** Dans la fonction qui verifie les droits &lt;code&gt;Right.php checkRights($command)&lt;/code&gt;, le cas de l'administrateur n'était pas vraiment traité. Il y avait un verification pour empecher tout utilisateur non administrateur d'executer une commande administrateur, mais sinon l'administrateur était traité comme un utilisateur lambda. J'ai donc ajouté un test permettant de donner les pleins pouvoirs. Presque. Il fallait aussi ajouter un test dans la fonction &lt;code&gt;File.php _checkFileAccess(...)&lt;/code&gt; qui pour certaines actions sur les fichiers, agit comme une surcouche à la fonction &lt;code&gt;checkRights&lt;/code&gt; (ce qui permet entre autres des actions sur les fichiers hérités pour le tuteur et les membres).<br /> ** Cas du déplacement de fichier hérités.<br /> *** Avec l'accord d'Anthony, on a conclu que le déplacement de fichier hérité était une mauvaise idée, donc cela reste non autorisé, même pour les admins.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être supprimés.<br /> ** Les appels à la base effectuait une comparaison avec un &lt;code&gt;LIKE&lt;/code&gt; au lieu d'un &lt;code&gt;=&lt;/code&gt; dans la requête SQL, ce qui ne marchait pas dans le cas présent.<br /> * Correction du fait que les fichiers ayant un numero pour nom ne peuvent pas être renommés.<br /> ** Le nom du fichier est traité et enregistré par le fichier JS, qui est non typé donc il decide que si le nom n'est que des numeros, alors ce ne sera pas une string. Or pour renommer le fichier, on veux modifer la partie du nom qui est avant le point (de l'extension), donc on fait un appel à &lt;code&gt;name.lastIndexOf(&quot;.&quot;);&lt;/code&gt;, qui s'execute eclusivement sur une string. J'ai donc realisé un &lt;code&gt;.toString()&lt;/code&gt; sur le nom à chaque fois que necessaire.<br /> * Correction du fait que lorsque l'on supprimait un fichier dans un dossier, on était renvoyé à la racine du projet plutot que dans le dossier.<br /> ** Il manquait un paramètre (le dossier) à la fonction &lt;code&gt;getFiles(...)&lt;/code&gt; appalée après la suppréssion.<br /> * Transformation du bouton &quot;Ajouter&quot; en deux boutons, un pour les dossiers, un pour les fichiers.<br /> <br /> ==== Zoran ====<br /> * Mise à Jour de templates de mail (&gt;100 templates)<br /> ** Remplacement des références à Waza Education par EDCampus<br /> ** Production d'une banière et remplacement de l'ancienne<br /> * Tests des fichiers de configuration des tests unitaires<br /> * Recherches sur le passage de l'HTTP vers HTTPS avec [https://letsencrypt.org/ Let's Encrypt] : voir le [[Let's Encrypt | résumé rapide]]<br /> ** Choix d'utilisation de [https://certbot.eff.org/ Certbot]<br /> <br /> === 13/02/19 ===<br /> <br /> ==== Servan ====<br /> Nouvelle tâche assignée : Améliorer les tâches, faire en sorte que si un nom est placé sur un label d'une couleur au sein d'un projet, tous les labels de cette couleur auront ce même nom.<br /> <br /> ==== Zoran ====<br /> <br /> === 14/02/19 ===<br /> <br /> ==== Servan ====<br /> * Backend corrigé, on ne peux plus créer une tache d'un nom au choix si il y a deja une tache de cette couleur avec un nom dans le projet.<br /> * Etude approfondie du front-end et du systeme evenementiel pour corriger les defauts de mise à jour.<br /> <br /> ==== Zoran ====<br /> <br /> === 15/02/19 ===<br /> <br /> ==== Servan ====<br /> * Correction superficielle des problemes des mise a jour a de la vue du systeme de tache. Le soucis etant que les taches et le petit menu qui indique les details ne sont pas le même module et n'interagissent pas vraiment entre eux, donc on ne peux pas actualier l'un depuis l'autre.<br /> * Correction du fait que dans le systeme de fichier, on ne pouvait pas délacer un fichier/dossier vers le dossier parent en le glissant sur la flèche retour. <br /> ** Le soucis venait du fichier html, qui avait l'air correct mais la variable qu'il etait censé recuppérer renvoyait undefined au lieu de l'identifiant du dossier parent.<br /> <br /> ==== Zoran ====<br /> <br /> == Semaine 4 ==<br /> <br /> Hack ton campus.<br /> <br /> == Semaine 5 ==<br /> <br /> === 05/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====<br /> <br /> === 06/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====<br /> <br /> === 07/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====<br /> <br /> === 08/03/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====</div>

Zoran.Chanet https://air.imag.fr/index.php?title=Let%27s_Encrypt&diff=45129 2019-03-04T08:22:42Z

<p>Zoran.Chanet: Created page with &quot;= Auteur = CHANET Zoran = Introduction = Cette page s&#039;intéresse à la compréhension de Let&#039;s Encrypt, puis présente un tutoriel simple d&#039;utilisatio...&quot;</p> <hr /> <div>= Auteur =<br /> [[User:Zoran.Chanet | CHANET Zoran]]<br /> <br /> = Introduction =<br /> Cette page s'intéresse à la compréhension de Let's Encrypt, puis présente un tutoriel simple d'utilisation de Let's Encrypt via le logiciel Certbot (dans le cas d'un serveur Apache installé sur un système d'exploitation Ubuntu. Pour d'autres utilisations, visitez [https://certbot.eff.org/ le site du logiciel].<br /> <br /> = Let's Encrypt =<br /> Let’s encrypt est une autorité mondiale de certification délivrant des certificats gratuits pour crypter les échanges HTTP, et donc passer de l’HTTP à l’HTTPS. Ces certificats doivent être placés à la racine de l’hôte, la mise en place de let’s encrypt peut donc nécessiter des droits SSH vers l’hôte. Afin de prouver que le demandeur de certificats possède bien le site, le protocole ACME est utilisé. Let’s encrypt encourage l’utilisation de Certbot pour une gestion simplifiée des certificats.<br /> Les certificats délivrés par Let’s encrypt ont une validité de 90 jours. Il est donc nécessaire de les renouveler. Certbot propose un système de renouvellement automatique.<br /> <br /> = Certbot =<br /> Ce tutoriel couvre l'installation et l'utilisation de Certbot dans le cas d'un serveur Apache installé sur un système d'exploitation Ubuntu. Les manipulations suivantes sont à faire sur le serveur. Il est donc nécessaire de pouvoir accéder au serveur et le modifier, par exemple par un accès SSH.<br /> == Installation ==<br /> sudo apt-get update<br /> sudo apt-get install software-properties-common<br /> sudo add-apt-repository universe<br /> sudo add-apt-repository ppa:certbot/certbot<br /> sudo apt-get update<br /> sudo apt-get install certbot python-certbot-apache<br /> <br /> == Création du certificat ==<br /> La commande suivante permet de générer le certificat et de configurer automatiquement une vhost Apache https utilisant ce certificat.<br /> sudo certbot --apache<br /> Pour se contenter de générer le certificat (ce qui nécessite donc une configuration d'Apache manuelle), le commande suivante peut être utilisée.<br /> sudo certbot --apache certonly<br /> <br /> == Test du renouvellement automatique ==<br /> sudo certbot renew --dry-run<br /> <br /> == Renouveler les certificats ==<br /> Il faut créer une tâche de fond qui lance certbot renew.&lt;br&gt;<br /> Exemple (tous les jours à midi et minuit) : <br /> 0 0,12 * * * python -c 'import random; import time; time.sleep(random.random() * 3600)' &amp;&amp; certbot renew<br /> <br /> <br /> = Astuces =<br /> * Apache ne supporte pas d'appels à Listen qui se superposent (e.g. deux fois Listen 80)<br /> * Il est nécessaire d'activer le mod_ssl d’Apache<br /> * Les connexions https se feront sur le port 443 (il faut donc une vhost qui reçoive sur ce port, et qui copie celle qui reçoit sur 80 tout en renseignant le certificat)<br /> * Avoir plusieurs vhost avec le même nom de serveur peut créer des soucis (e.g. 500)<br /> * [https://www.ssllabs.com/ssltest/analyze.html www.ssllabs.com/ssltest/analyze.html] permet de tester le certificat et l’accès au site<br /> * Le succès de la création du certificat provoquera le message suivant (domain.name étant le nom de domaine pour lequel le certificat a été produit)<br /> domain.name<br /> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -<br /> Congratulations! You have successfully enabled https://domain.name<br /> <br /> You should test your configuration at:<br /> https://www.ssllabs.com/ssltest/analyze.html?d=domain.name<br /> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -<br /> <br /> IMPORTANT NOTES:<br /> - Congratulations! Your certificate and chain have been saved at:<br /> /etc/letsencrypt/live/domain.name/fullchain.pem<br /> Your key file has been saved at:<br /> /etc/letsencrypt/live/domain.name/privkey.pem<br /> Your cert will expire on xxxx-xx-xx. To obtain a new or tweaked<br /> version of this certificate in the future, simply run certbot again<br /> with the &quot;certonly&quot; option. To non-interactively renew *all* of<br /> your certificates, run &quot;certbot renew&quot;<br /> - If you like Certbot, please consider supporting our work by:<br /> <br /> Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate<br /> Donating to EFF: https://eff.org/donate-le<br /> <br /> = Sources =<br /> Site de Let's Encrypt : [https://letsencrypt.org/ letsencrypt.org/]&lt;br&gt;<br /> Site de Certbot : [https://certbot.eff.org/ certbot.eff.org/]<br /> <br /> = Liens utiles =<br /> Image pour l'utilisation d'Apache et Certbot avec [[Docker]] : [https://github.com/BirgerK/docker-apache-letsencrypt github.com/BirgerK/docker-apache-letsencrypt]<br /> Informations sur la configuration d'Apache pour tenir compte des certificats : [https://www.ssl247.fr/support/installer/apache www.ssl247.fr/support/installer/apache]</div>

Zoran.Chanet https://air.imag.fr/index.php?title=Thorntail&diff=44909 2019-02-11T08:53:45Z

<p>Zoran.Chanet: /* Mentions */</p> <hr /> <div>http://thorntail.io/<br /> <br /> Thorntail offers an innovative approach to packaging and running JavaEE applications by packaging them with just enough of the server runtime to &quot;java -jar&quot; your application. However, it's all much, much cooler than that ...<br /> <br /> https://github.com/thorntail<br /> <br /> = Mentions =<br /> Une synthèse de cette technologie a été proposée pour le cours de [[VT2018|Veille Technologique et Stratégique]] : [[VT2018_Thorntail|Synthèse de la technologie Thorntail]] par [[User:Zoran.Chanet | Zoran CHANET]]</div>

Zoran.Chanet https://air.imag.fr/index.php?title=Ordre_passages_soutenances_RICM4_2017_2018&diff=44908 2019-02-11T08:52:56Z

<p>Zoran.Chanet: /* Ordre de passages avec horaires et dates */</p> <hr /> <div>== Lieu ==<br /> A Polytech' la salle '''257''' le lundi 9 avril;<br /> <br /> == Ordre de passages avec horaires et dates ==<br /> {|class=&quot;wikitable alternance&quot;<br /> |+ Affectation des projets RICM4 2017-2018<br /> |-<br /> |<br /> !scope=&quot;col&quot;| Sujet<br /> !scope=&quot;col&quot;| Etudiants<br /> !scope=&quot;col&quot;| Enseignant(s)<br /> !scope=&quot;col&quot;| Fiche de suivi<br /> !scope=&quot;col&quot;| Dépot git<br /> !scope=&quot;col&quot;| Horaire et date<br /> |-<br /> <br /> <br /> !scope=&quot;row&quot;| 2<br /> | [[Dashboard pour gestionnaire de tâches]] (Angular 5)<br /> | BELGUENDOUZ Sekina, LARNICOL Titouan<br /> | Olivier Richard<br /> | [[RICM4_2017_2018_-_Dashboard| Fiche]] - [[RICM4_2017_2018_-_Dashboard/SRS|SRS]] - [[RICM4_2017_2018_-_Dashboard/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/2 gitlab]<br /> | '''09:00-09:22'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 4<br /> | [[ESP32 et language D]]<br /> | MANGER Raphael, HOUBRON Adrian<br /> | Olivier Richard<br /> | [[RICM4_2017_2018_-_ESP32_D| Fiche]] - [[RICM4_2017_2018_-_ESP32_D/_SRS|SRS]] - [[RICM4_2017_2018_-_ESP32_D/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/4 gitlab]<br /> | '''09:25-09:47'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 5<br /> | [[Serious game multi-joueurs pour tables tactiles en réseau]]<br /> | LEPAGE Tim, SERGEANT Dimitri <br /> | Didier Donsez, Anne-Laure Finkel, Stéphanie Diligent<br /> | [[RICM4_2017_2018_-SeriousGame Polystar | Fiche]] - [[RICM4_2017_2018_- SeriousGame Polystar /_SRS|SRS]] - [[RICM4_2017_2018_- SeriousGame Polystar /UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/5 gitlab]<br /> | '''09:50-10:12'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 7.1<br /> | Projet [[UltraTeam]] avec des trackers [[ESP32-LoRa]] + GPS<br /> | TERRIER Bastien, GROS-DAILLON Hugo <br /> | Didier Donsez<br /> | [[RICM4_2017_2018_-_UltraTeam_7.1| Fiche]] - [[RICM4_2017_2018_-_UltraTeam_7.1/_SRS|SRS]] - [[RICM4_2017_2018_-_UltraTeam_7.1/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/7.1 gitlab]<br /> | '''10:15-10:37'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 7.2<br /> | Projet [[UltraTeam]] avec des trackers [[ESP32-LoRa]] + GPS<br /> | MOLION Enzo, VALETTE Léo<br /> | Didier Donsez<br /> | [[RICM4_2017_2018_-_UltraTeamMV| Fiche]] - [[RICM4_2017_2018_-_UltraTeamMV_:_SRS|SRS]] - [[RICM4_2017_2018_-_UltraTeamMV_:_UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/7.2 gitlab]<br /> | '''10:40-11:02'''<br /> |-<br /> <br /> <br /> !scope=&quot;row&quot;| 8<br /> | Projet [[Réseau Social LoRa]] avec des pods [[ESP32-LoRa]]<br /> | VEGREVILLE Thibaud, GENTILLON Loris, ZHENG Jian<br /> | Olivier Richard<br /> | [[RICM4_2017_2018_-_Réseau_Social_LoRa| Fiche]] - [[RICM4_2017_2018_-_Réseau_Social_LoRa/_SRS|SRS]] - [[RICM4_2017_2018_-_Réseau_Social_LoRa/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/8 gitlab]<br /> | '''11:05-11:27'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 10<br /> | [[Ruche connectée LoRa]] <br /> | BESNIER Benjamin, LÉVESQUE Théo, WEILL William<br /> | Nicolas Palix<br /> | [[RICM4_2017_2018_-_Ruche_Connectee_| Fiche]] - [[RICM4_2017_2018_-_Ruche_Connectee_/_SRS|SRS]] - [[RICM4_2017_2018_-_Ruche_Connectee/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/10 gitlab]<br /> | '''11:30-11:52'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 11<br /> | [[Serres connectées]]<br /> | BESNARD Guillaume, DEPRIESTER Timothée<br /> | Nicolas Palix<br /> | [[RICM4_2017_2018_-_Serre_Connectee| Fiche]] - [[RICM4_2017_2018_-_Serre_Connectee_/_SRS|SRS]] - [[RICM4_2017_2018_-_Serre_Connecte/UML | UML]] - [[RICM4_2017_2018_-_Serre_Connecte/Schedule | Schedule]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/11 gitlab]<br /> | '''11:55-12:17'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 12<br /> | [[I-Greenhouse]] : [[Serre connectée aquaponie]] <br /> | SURIER GAROFALO Aurélien, FERREIRA Joffrey, OZENDA Thomas<br /> | Nicolas Palix<br /> | [[RICM4_2017_2018_-_IGreenHouse| Fiche]] - [[RICM4_2017_2018_-_IGreenHouse_/_SRS|SRS]] - [[IGreenHouse/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/12 gitlab]<br /> | '''14:10-14:32'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 17.1<br /> | [[RobAIR]] : Robot Majordome<br /> | DEVOS Xavier, LAFRASSE Cédric<br /> | J. Maisonnasse, Germain Lemasson, Bastien Scher<br /> | [[RICM4_2017_2018_-_RobAIR17-1| Fiche]] - [[RICM4_2017_2018_-_RobAIRDL/_SRS|SRS]] - [[RICM4_2017_2018_-_RobAIRDL/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/17.1 gitlab]<br /> | '''14:35-14:57'''<br /> |-<br /> <br /> <br /> !scope=&quot;row&quot;| 6<br /> | [[Challenge OpenCity]]<br /> | BOUCHERIMA Amina, FOMBARON Quentin<br /> | Georges-Pierre Bonneau, Didier Donsez<br /> | [[RICM4_2017_2018_-_OpenCity| Fiche]] - [[RICM4_2017_2018_-_OpenCity/_SRS|SRS]] - [[RICM4_2017_2018_-_OpenCity/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/6 gitlab]<br /> | '''15:00-15:22'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 15<br /> | Connected Shop (avec [[Eclipse SmartHome]])<br /> | CUZIN Florian, ECHEVET Théo<br /> | Didier Donsez<br /> | [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/15 gitlab]<br /> | '''15:25-15:47'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 16<br /> | [[Deploiment Nucleo | Déploiement sécurisé et sans fil pour carte Nucleo]]<br /> | [[User:Zoran.Chanet | CHANET Zoran]], [[User:Servan.Charlot | CHARLOT Servan]]<br /> | Olivier Richard, Sylain Toru<br /> | [[RICM4_2017_2018_-_Nucleo | Fiche]] - [[RICM4_2017_2018_-_Nucleo/_SRS|SRS]] - [[RICM4_2017_2018_-_Nucleo/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/16 gitlab]<br /> | '''15:50-16:12'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 14<br /> | [[Chatbot pour borne d'accueil handicap]]<br /> | AUCLAIR-CORDAT Julien, BAMBA Samuel<br /> | Didier Donsez, Marie-Paule Balicco et Jérôme Maisonnasse <br /> | [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/14 gitlab]<br /> | '''16:15-16:37'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 13<br /> | Projet &quot;Plateforme de mise en relation pour les entrepreneurs sociaux&quot;<br /> | AUBERT Vincent, COURTIAL Julien<br /> | Didier Donsez<br /> | [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_Entrepreneur_AUBERT_COURTIAL/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/13 gitlab]<br /> | '''16:40-17:02'''<br /> |-<br /> <br /> <br /> !scope=&quot;row&quot;| 17.2<br /> | [[RobAIR]] : Robot Majordome<br /> | JEAN Jordan, EZ-ZINE Najwa<br /> | J. Maisonnasse, Germain Lemasson, Bastien Scher<br /> | [[RICM4_2017_2018_-_robair2| Fiche]] - [[RICM4_2017_2018_-_robair2/_SRS|SRS]] - [[RICM4_2017_2018_-_robair2/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/17.2 gitlab]<br /> | '''17:05-17:27'''<br /> |-<br /> <br /> |}</div>

Zoran.Chanet https://air.imag.fr/index.php?title=Ordre_passages_mi_parcours_RICM4_2017_2018&diff=44907 2019-02-11T08:51:39Z

<p>Zoran.Chanet: /* Ordre de passages avec horaires et dates */</p> <hr /> <div>== Lieux ==<br /> A Polytech' la salle '''257''' le lundi et la salle '''11''' le mardi;<br /> <br /> == Ordre de passages avec horaires et dates ==<br /> {|class=&quot;wikitable alternance&quot;<br /> |+ Affectation des projets RICM4 2017-2018<br /> |-<br /> |<br /> !scope=&quot;col&quot;| Sujet<br /> !scope=&quot;col&quot;| Etudiants<br /> !scope=&quot;col&quot;| Enseignant(s)<br /> !scope=&quot;col&quot;| Fiche de suivi<br /> !scope=&quot;col&quot;| Dépot git<br /> !scope=&quot;col&quot;| Horaire et date<br /> |-<br /> <br /> <br /> !scope=&quot;row&quot;| 2<br /> | [[Dashboard pour gestionnaire de tâches]] (Angular 5)<br /> | BELGUENDOUZ Sekina, LARNICOL Titouan<br /> | Olivier Richard<br /> | [[RICM4_2017_2018_-_Dashboard| Fiche]] - [[RICM4_2017_2018_-_Dashboard/_SRS|SRS]] - [[RICM4_2017_2018_-_Dashboard/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/2 gitlab]<br /> | '''14h30-14h40 Lundi 12/03'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 4<br /> | [[ESP32 et language D]]<br /> | MANGER Raphael, HOUBRON Adrian<br /> | Olivier Richard<br /> | [[RICM4_2017_2018_-_ESP32_D| Fiche]] - [[RICM4_2017_2018_-_ESP32_D/_SRS|SRS]] - [[RICM4_2017_2018_-_ESP32_D/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/4 gitlab]<br /> | '''14h42-14h52 Lundi 12/03'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 5<br /> | [[Serious game multi-joueurs pour tables tactiles en réseau]]<br /> | LEPAGE Tim, SERGEANT Dimitri <br /> | Didier Donsez, Anne-Laure Finkel, Stéphanie Diligent<br /> | [[RICM4_2017_2018_-SeriousGame Polystar | Fiche]] - [[RICM4_2017_2018_- SeriousGame Polystar /_SRS|SRS]] - [[RICM4_2017_2018_- SeriousGame Polystar /UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/5 gitlab]<br /> | '''14h54-15h04 Lundi 12/03'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 6<br /> | [[Challenge OpenCity]]<br /> | BOUCHERIMA Amina, FOMBARON Quentin<br /> | Georges-Pierre Bonneau, Didier Donsez<br /> | [[RICM4_2017_2018_-_OpenCity| Fiche]] - [[RICM4_2017_2018_-_OpenCity/_SRS|SRS]] - [[RICM4_2017_2018_-_OpenCity/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/6 gitlab]<br /> | '''15h06-15h16 Lundi 12/03'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 7.1<br /> | Projet [[UltraTeam]] avec des trackers [[ESP32-LoRa]] + GPS<br /> | TERRIER Bastien, GROS-DAILLON Hugo <br /> | Didier Donsez<br /> | [[RICM4_2017_2018_-_UltraTeam_7.1| Fiche]] - [[RICM4_2017_2018_-_UltraTeam_7.1/_SRS|SRS]] - [[RICM4_2017_2018_-_UltraTeam_7.1/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/7.1 gitlab]<br /> | '''15h18-15h28 Lundi 12/03'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 7.2<br /> | Projet [[UltraTeam]] avec des trackers [[ESP32-LoRa]] + GPS<br /> | MOLION Enzo, VALETTE Léo<br /> | Didier Donsez<br /> | [[RICM4_2017_2018_-_UltraTeamMV| Fiche]] - [[RICM4_2017_2018_-_UltraTeamMV_:_SRS|SRS]] - [[RICM4_2017_2018_-_UltraTeamMV_:_UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/7.2 gitlab]<br /> | '''15h30-15h40 Lundi 12/03'''<br /> |-<br /> <br /> <br /> !scope=&quot;row&quot;| 8<br /> | Projet [[Réseau Social LoRa]] avec des pods [[ESP32-LoRa]]<br /> | VEGREVILLE Thibaud, GENTILLON Loris, ZHENG Jian<br /> | Olivier Richard<br /> | [[RICM4_2017_2018_-_Réseau_Social_LoRa| Fiche]] - [[RICM4_2017_2018_-_Réseau_Social_LoRa/_SRS|SRS]] - [[RICM4_2017_2018_-_Réseau_Social_LoRa/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/8 gitlab]<br /> | '''15h42-15h52 Lundi 12/03'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 10<br /> | [[Ruche connectée LoRa]] <br /> | BESNIER Benjamin, LÉVESQUE Théo, WEILL William<br /> | Nicolas Palix<br /> | [[RICM4_2017_2018_-_Ruche_Connectee_| Fiche]] - [[RICM4_2017_2018_-_Ruche_Connectee_/_SRS|SRS]] - [[RICM4_2017_2018_-_Ruche_Connectee/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/10 gitlab]<br /> | '''15h54-16h04 Lundi 12/03'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 11<br /> | [[Serres connectées]]<br /> | BESNARD Guillaume, DEPRIESTER Timothée<br /> | Nicolas Palix<br /> | [[RICM4_2017_2018_-_Serre_Connectee| Fiche]] - [[RICM4_2017_2018_-_Serre_Connectee_/_SRS|SRS]] - [[RICM4_2017_2018_-_Serre_Connecte/UML | UML]] - [[RICM4_2017_2018_-_Serre_Connecte/Schedule | Schedule]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/11 gitlab]<br /> | '''16h06-16h16 Lundi 12/03'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 12<br /> | [[I-Greenhouse]] : [[Serre connectée aquaponie]] <br /> | SURIER GAROFALO Aurélien, FERREIRA Joffrey, OZENDA Thomas<br /> | Nicolas Palix<br /> | [[RICM4_2017_2018_-_IGreenHouse| Fiche]] - [[RICM4_2017_2018_-_IGreenHouse_/_SRS|SRS]] - [[IGreenHouse/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/12 gitlab]<br /> | '''16h18-16h28 Lundi 12/03'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 13<br /> | Projet &quot;Plateforme de mise en relation pour les entrepreneurs sociaux&quot;<br /> | AUBERT Vincent, COURTIAL Julien<br /> | Didier Donsez<br /> | [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_Entrepreneur_AUBERT_COURTIAL/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/13 gitlab]<br /> | '''16h30-16h40 Lundi 12/03'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 14<br /> | [[Chatbot pour borne d'accueil handicap]]<br /> | AUCLAIR-CORDAT Julien, BAMBA Samuel<br /> | Didier Donsez, Marie-Paule Balicco et Jérôme Maisonnasse <br /> | [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/14 gitlab]<br /> | '''16h42-16h52 Lundi 12/03'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 15<br /> | Connected Shop (avec [[Eclipse SmartHome]])<br /> | CUZIN Florian, ECHEVET Théo<br /> | Didier Donsez<br /> | [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/15 gitlab]<br /> | '''14h00-14h10 Mardi 13/03'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 16<br /> | [[Deploiment Nucleo | Déploiement sécurisé et sans fil pour carte Nucleo]]<br /> | [[User:Zoran.Chanet | CHANET Zoran]], [[User:Servan.Charlot | CHARLOT Servan]]<br /> | Olivier Richard, Sylain Toru<br /> | [[RICM4_2017_2018_-_Nucleo | Fiche]] - [[RICM4_2017_2018_-_Nucleo/_SRS|SRS]] - [[RICM4_2017_2018_-_Nucleo/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/16 gitlab]<br /> | '''14h12-14h22 Mardi 13/03'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 17.1<br /> | [[RobAIR]] : Robot Majordome<br /> | DEVOS Xavier, LAFRASSE Cédric<br /> | J. Maisonnasse, Germain Lemasson, Bastien Scher<br /> | [[RICM4_2017_2018_-_RobAIR17-1| Fiche]] - [[RICM4_2017_2018_-_RobAIRDL/_SRS|SRS]] - [[RICM4_2017_2018_-_RobAIRDL/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/17.1 gitlab]<br /> | '''14h24-14h34 Mardi 13/03'''<br /> |-<br /> <br /> !scope=&quot;row&quot;| 17.2<br /> | [[RobAIR]] : Robot Majordome<br /> | JEAN Jordan, EZ-ZINE Najwa<br /> | J. Maisonnasse, Germain Lemasson, Bastien Scher<br /> | [[RICM4_2017_2018_-_robair2| Fiche]] - [[RICM4_2017_2018_-_robair2/_SRS|SRS]] - [[RICM4_2017_2018_-_robair2/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/17.2 gitlab]<br /> | '''14h36-14h46 Mardi 13/03'''<br /> |-<br /> <br /> |}</div>

Zoran.Chanet https://air.imag.fr/index.php?title=Projets_2018-2019&diff=44906 2019-02-11T08:50:43Z

<p>Zoran.Chanet: /* Affectations */</p> <hr /> <div>&lt;&lt;[[Projets 2017-2018]] | [[Projets]] | [[Projets 2019-2020]]&gt;&gt;<br /> =INFO=<br /> ==INFO3==<br /> <br /> ==INFO4==<br /> ===Projet Semestre S8===<br /> <br /> Enseignants responsables : Olivier Richard, Didier Donsez<br /> <br /> * Dates : Lundi après-midi, Mardi après-midi <br /> * Lancement: '''21/01/19 à 14h30'''<br /> * Soutenance à mi-parcours: A définir<br /> * Soutenance: A définir<br /> <br /> * '''Evaluation à mi-parcours le lundi/mardi ???''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.<br /> <br /> '''Consignes générales:'''<br /> <br /> * '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: creuser la question, contacter l'auteur du code si il y a lieu, écrire un rapport de bug ('''Attention:''' ca se prépare !), soumettre un patch/pull request, contacter l'enseignant ou la personne référente du projet.<br /> <br /> * '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par info4_2018_2019. '''Cette fiche compte pour la note finale'''<br /> <br /> * '''Votre code''' pour doit être hébergé sur le gitlab et à l'URL suivante https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19 , vous utiliserez votre compte UGA.<br /> <br /> * Chaque projet doit avoir '''aux moins 2 dépôts git''':<br /> ** '''Un pour les documents''' demandés rapport, présentation de pré-soutenante, de soutenance, flyer. '''Il sera appelé documents.'''<br /> ** Un ou plusieurs pour le code, les tests, les évaluations, les preuves de concept, la ou les documentations afférentes. <br /> <br /> * Les documents public doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions). Une bonnification sera accordée si le rapport et les transparents sont en anglais (la soutenance sera en francais).<br /> <br /> * '''La note obtenue''' tiendra compte du '''nombre et de la qualité des commits''' observé dans '''vos dépots git et la branche master''' (or depot documents). La qualité comprend l'intitulé du commit et son contenu. Les notes pourront être différentiées dans un groupe, il n'est pas acceptable de pas avoir de commit dans le(s) dépôt(s) du projet (or dépôt documents).<br /> <br /> * Il est fortement conseillé de suivre un '''développement incrémental''' qui permette d'avoir à tout moment un démonstrateur à présenter, un projet peut être constituer d'une succession de '''démonstrateurs présentables séparément'''.<br /> <br /> * Vous devez faire aussi des '''schémas d'architectures générales et/ou spéficiques, des diagrammes de séquence''', et autre documents de spécification si nécessaire. Ces documents vous serviront de base de discussion/brainstorming interne ainsi que dans vos différents documents (rapport, présentations, documentation). Ces schémas sont avant tout conceptuels et techniques.<br /> <br /> ===Propositions de projets===<br /> <br /> * [[LoRaGAN]] : LoRa in the Space, Didier Donsez avec le [https://www.csug.fr/ CSUG] (S)<br /> * [[LoRaRescueBalloon]], Didier Donsez avec le [https://www.csug.fr/ CSUG] et des élèves IESE 3 et 4. (S)<br /> * Agriculture connectée à [[ASAC/AP|Polytech]] et à [[ASAC/SJC|St Cassien]] en partenariat avec les projets collectifs IESE/MAT<br /> *# [[ASAC/AP/AP-2019-1|Serre Polytech - Système embarqué]] - Projet embarqué sur STM32 ou RPi3 + LoRa (S)<br /> *# [[ASAC/AP/AP-2019-2|Serre Polytech - Kiosk]] - Kiosk, App. mobile Android et site web de visualisation des données (M)<br /> *# [[ASAC/SJC/SJC-2019|Serre St Cassien]] - Kiosk, App. mobile Android et site web de visualisation des données (M)<br /> * [[Projet FICHA - tri sélectif connecté]], Sylvain Toru.<br /> * [[Dataviz de la qualité de l'air]], Didier Donsez, avec Atmo AURA et [https://github.com/CampusIoT/campusiot.github.io CampusIoT] (M)<br /> * [[Application mobile Ionic pour Cages à marmotte connectées en LoRaWAN]], Didier Donsez, Franck Delbard, avec le [https://www.jardinalpindulautaret.fr/ Station alpine Joseph Fourier] (M)<br /> * [[Testeur radio LoRaWAN en Ionic pour la plateforme CampusIoT]], Didier Donsez (S&amp;M)<br /> * [[Serious game multi-joueurs pour tables tactiles en réseau]] : Anne-Laure Finkel, Tim Lepage, Didier Donsez. (S&amp;M)<br /> * [[Interface de visualisation mobile du projet e-Tree]]: Anne Delaballe, Didier Donsez. (M)<br /> * [[OpenHAB UPnP DCS 2018]], Didier Donsez (S&amp;M)<br /> * [[Application mobile Ionic pour cabine de biathlon connectée en LoRa]], Didier Donsez et d'autres avec Neoxia<br /> * [[P2P_IPFS | Réseau social pair-à-pair basé sur IPFS]], Olivier Richard (S)<br /> * [[proxy_web_oar | Service de Proxy web pour un gestionnaire de tâches]], Olivier Richard (S)<br /> * [[Colmet_energy | Mesure de consommation d'énergie et de perfomance pour cluster]], Olivier Richard (S)<br /> * [[kanixfs | Diffusion de fichiers pour le gestionnaire de paquets NIX sur supercalculateur]], Olivier Richard (S)<br /> * [[dashboard_sci | Générateur de tableau de bord pour applications scientifiques]], Olivier Richard (S&amp;M)<br /> * [[generate_NIX_expression | Génération d'expression NIX]] (S)<br /> <br /> Non prioritaire<br /> * [[Précarité numérique]], Didier Donsez, avec [https://disrupt-campus.univ-grenoble-alpes.fr/ Disrupt Campus]<br /> * [[Covoiturage Solidaire]], Didier Donsez<br /> * [[CannonBall de voitures autonomes 2018]]<br /> * Intégration de [[Walabot]] à [[RobAIR]]<br /> <br /> ==== Affectation ====<br /> {|class=&quot;wikitable alternance&quot;<br /> |+ Affectation des projets INFO4 2018-2019<br /> |-<br /> |<br /> !scope=&quot;col&quot;| Sujet<br /> !scope=&quot;col&quot;| Etudiants<br /> !scope=&quot;col&quot;| Enseignant(s)<br /> !scope=&quot;col&quot;| Fiche de suivi<br /> !scope=&quot;col&quot;| Dépot git<br /> |-<br /> <br /> !scope=&quot;row&quot;| 1<br /> | [[LoRaGAN]]<br /> | VINCENT Mathieu, SAUTON Tanguy, ANCRENAZ Ariane<br /> | Didier Donsez avec le [https://www.csug.fr/ CSUG]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/1/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 2<br /> | [[LoRaRescueBalloon]]<br /> | Non attribué<br /> | Didier Donsez avec le [https://www.csug.fr/ CSUG]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/2/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 3<br /> | [[ASAC/AP/AP-2019-1|Serre Polytech - Système embarqué]]<br /> | Non attribué<br /> | Nicolas Palix<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/3/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 4<br /> | [[ASAC/AP/AP-2019-2|Serre Polytech]]<br /> | RAKOTOARIMALALA Andriamahatratra, BARDOU Eva, GAUFFIER Léni<br /> | Nicolas Palix<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/4/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 5<br /> | [[ASAC/SJC/SJC-2019|Serre St Cassien]]<br /> | DECAMPS Marceau, LANDI Estelle, BONASPETTI GIULIA<br /> | Nicolas Palix<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/5/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 6<br /> | [[Projet FICHA - tri sélectif connecté]]<br /> | SCHANEN Loïc, VINCENT Maxence, VANDAL Jade<br /> | Sylvain Toru<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/6/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 7<br /> | [[Dataviz de la qualité de l'air]]<br /> | ZARCOS Paul, ZHENG Jian, REYMOND Estelle<br /> | Didier Donsez, avec Atmo AURA et [https://github.com/CampusIoT/campusiot.github.io CampusIoT]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/7/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 8<br /> | [[Application mobile Ionic pour Cages à marmotte connectées en LoRaWAN]]<br /> | SERRE Ancelin, BOUVIER Baptiste, WYKLAND Damien<br /> | Didier Donsez, Franck Delbard, avec le [https://www.jardinalpindulautaret.fr/ Station alpine Joseph Fourier]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/8/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 9<br /> | [[Testeur radio LoRaWAN en Ionic pour la plateforme CampusIoT]]<br /> | THOMAS Antoine, RIVOIRE Antoine, DENIS Guillaume<br /> | Didier Donsez<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/9/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 10<br /> | [[Serious game multi-joueurs pour tables tactiles en réseau]]<br /> | DUMENIL Antoine, BETEND Baptiste, JAN Léo<br /> | Anne-Laure Finkel, Tim Lepage, Didier Donsez<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/10/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 11<br /> | [[Interface de visualisation mobile du projet e-Tree]]<br /> | SOLVERY Tom, SALA Ergi, DUMAX-VORZET Mathieu<br /> | Anne Delaballe, Didier Donsez<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/11/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 12<br /> | [[OpenHAB UPnP DCS 2018]]<br /> | VARENNE Rémi, TRESTOUR Grégory, SOUCHON Loïc<br /> | Didier Donsez<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/12/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 13<br /> | [[Application mobile Ionic pour cabine de biathlon connectée en LoRa]]<br /> | LORDEY Maxime, LATTARD Alexis, GILBERT-COLLET Bertrand<br /> | Didier Donsez et d'autres avec Neoxia<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/13/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 14<br /> | [[P2P_IPFS | Réseau social pair-à-pair basé sur IPFS]]<br /> | REYGROBELLET Lucas, BRES Maxence, PELISSON Antoine<br /> | Olivier Richard<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/14/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 15<br /> | [[proxy_web_oar | Service de Proxy web pour un gestionnaire de tâches]]<br /> | Non attribué<br /> | Olivier Richard<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/15/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 16<br /> | [[Colmet_energy | Mesure de consommation d'énergie et de perfomance pour cluster]]<br /> | DALAINE Nathan, FONTFREYDE Joachim, GAUTIER-PIGNONBLANC Yann<br /> | Olivier Richard, Adrien Faure<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/16/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 17<br /> | [[kanixfs | Diffusion de fichiers pour le gestionnaire de paquets NIX sur supercalculateur]]<br /> | Non attribué<br /> | Olivier Richard<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/17/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 18<br /> | [[dashboard_sci | Générateur de tableau de bord pour applications scientifiques]]<br /> | BADAT Léya, CUAU Victor, MASSON Jérémy<br /> | Olivier Richard<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/18/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 19<br /> | [[generate_NIX_expression | Génération d'expression NIX]]<br /> | CHABRE Manon, DE ARAUJO Bastien, COSCIA Daniel<br /> | Olivier Richard<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/19/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 20<br /> | [[Gestion des Polypoints]]<br /> | CASTANO Nicolas, SIBUE Quentin, LAPLANTE Juliette<br /> | Didier Donsez, Olivier Richard<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/20/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 21<br /> | [[Smart Recruting]]<br /> | GUILLOT Romain, ARNOUX Thibaut, CHASSEGUET Corentin<br /> | Didier Donsez, Olivier Richard<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/21/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 22<br /> | [[Aide aux handicaps]]<br /> | JALMIN Hoël, ALACALI Kadir uraz, MASTOURA Iheb<br /> | Didier Donsez, Olivier Richard<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/18-19/22/docs/README.md Fiche]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> |}<br /> <br /> ==INFO5==<br /> ===Projet IoT S9===<br /> Enseignants responsables : Bernard Tourancheau<br /> <br /> Calendrier: ??? Septembre à ??? Décembre 2017.<br /> <br /> * Projet IoT 3 : [[Ski-locator]] (Bernard Tourancheau)<br /> <br /> <br /> <br /> ===Projet Semestre S10===<br /> <br /> Enseignants responsables : [[user:Donsez | Didier Donsez]]<br /> <br /> Calendrier: Fin Janvier à Mi Mars 2019.<br /> <br /> Séances de Management de projets innovants:<br /> <br /> Réunion de présentation : Salle 249 de 11H30 a 12H30, Mercredi 23 Janvier. Faire couler le café.<br /> <br /> Démarrage : A définir: Salle 251 de 8H30 a 11H00, Lundi 23 Janvier. Faire couler le café.<br /> <br /> Soutenance à mi-parcours : A définir, 8H00-11H00 (30 minutes par équipe).<br /> <br /> Soutenance (puis Pot de la fin) : A définir<br /> <br /> <br /> <br /> ==== Planning soutenances mi-parcours ====<br /> <br /> ==== Planning soutenances finales ====<br /> <br /> ==== Affectations ====<br /> {|class=&quot;wikitable alternance&quot;<br /> |+ Affectation des projets INFO5 2018-2019<br /> |-<br /> |<br /> !scope=&quot;col&quot;| Sujet<br /> !scope=&quot;col&quot;| Etudiants<br /> !scope=&quot;col&quot;| Enseignant(s)<br /> !scope=&quot;col&quot;| Fiche de suivi<br /> !scope=&quot;col&quot;| Documents<br /> |-<br /> <br /> !scope=&quot;row&quot;| 1<br /> | [[LoRaGAN/INFO5A/2019|LoRaGAN]]<br /> | Thibaud VEGREVILLE,Aurélien SURIER GAROFALO<br /> | Didier Donsez, Bernard Tourancheau, Mathieu Barthélémy ([https://www.csug.fr/ CSUG])<br /> | TBD<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 2<br /> | [[Contributions open-source au projet Eclipse EdCampus]]<br /> | [[User:Servan.Charlot | CHARLOT Servan]] (chef de projet), [[User:Zoran.Chanet | CHANET Zoran]]<br /> | Anthony Geourjon, Gérard Pollier, Didier Donsez<br /> | [[PROJET-INFO5 1819 EDCampus | Fiche de suivi ]]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 3<br /> | [[RICM5 2018 2019 - UGAChain|UGAChain 2019]] : [[Générateur Hyperledger pour JHipster]] : refactoring du projet [[RICM5 2017 2018 - UGAChain|UGAChain 2018]]<br /> | Loris GENTILLON, Jordan JEAN, Enzo MOLION, Léo VALETTE<br /> | Didier Donsez, Anthony Geourjon<br /> | TBD<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 4<br /> | [[Aide aux déficients visuelles]] (deep-learning avec [[Intel Movidius]], [https://greenwaves-technologies.com/product/gapduino/ GAPDunio], [[Lidar]] 1D et 2D, ...)<br /> | Samuel Bamba, Florian Cuzin, Théo Echevet, Raphaël Manger<br /> | Didier Donsez, Marie-Paule Balicco, Nicolas Vuillerme<br /> | TBD<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 5<br /> | [[Plateforme CampusIoT]]<br /> | '''William Weill (CP)''', Guillaume Besnard, Benjamin Besnier, Timothée Depriester, Théo Lévesque<br /> | Didier Donsez<br /> | [[PROJET-1FO5_1819_CampusIoT|Fiche]] - [[PROJET-1FO5_1819_CampusIoT/SRS|SRS]]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 6<br /> | [[Rééducation Kiné connecté]]<br /> | '''Sekina Belguendouz (CP)''', Vincent Aubert, Amina Boucherima, Najwa Ez-Zine<br /> | Sylvain Toru, Bernard Tourancheau<br /> | [[PROJET-INFO5_Kiné_Connecté | Fiche]]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 7<br /> | Projet IoT 3 : [[Ski-locator]]<br /> | '''Quentin Fombaron (CP)''', Tim Lepage, Thomas Ozenda, Joffrey Ferreira, Titouan Larnicol<br /> | Bernard Tourancheau<br /> | [[PROJET-1FO5_1819_SkiLocator|Fiche]] - [[PROJET-1FO5_1819_SkiLocator/SRS|SRS]]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 8<br /> | [[Contributions open-source au projet JHipster]]<br /> | '''Hugo GROS-DAILLON (CP)''', Julien COURTIAL, Cédric LAFRASSE, Bastien TERRIER<br /> | Didier Donsez, Anthony Geourjon<br /> | [[ PROJET-INFO5_Contributions_JHipster | Fiche ]]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> |}<br /> <br /> Réserve<br /> * [[Contributions à Software Heritage]] (Didier Donsez and co)<br /> * [[Sécurisation des données IoT avec des blockchains de consortium]] (Didier Donsez) --&gt; commun avec CampusIoT et UGAChain<br /> <br /> = Projets collectifs MAT/IESE =<br /> <br /> == Années 3 et 4 ==<br /> <br /> * [[ASAC/SJC|Serres connectées @ Jardin du coteau]]<br /> * [[ASAC/GEJC|Gestion de l'eau @ Jardin du coteau]]<br /> * [[ASAC/AP|Aquaponie @ Polytech]]<br /> <br /> =[[Projets M2PGI Services Machine-to-Machine et Internet-of-Things]]=<br /> ==[[PM2M/2019/TP|PM2M]]==<br /> <br /> =Réserve (boite à idées)=<br /> # [http://www.opti-solar.com/french/ap_applications.fr.html |Interface contrôleur de charge batterie/PV]<br /> # [[Sonotone à apprentissage profond]]<br /> # [[StartAIR2]] (Nicolas Palix)<br /> # [[Tag et Paint Ball en réalité augmentée]] (Michaël Périn) <br /> # [[Passe moi ton fichier]] (Michaël Périn) <br /> # [[Extensions à Fab Server]] (Jean-Michel Molenaar) sous reserve (CM ou SR)<br /> # [[Table multijeux de café 2.0]]<br /> # [[ GPIO_Qemu_RasPI| Emulation des GPIO dans QEMU pour le carte Raspberry Pi]] (Olivier Richard)<br /> # [[ Qemu et STM32F0-Discovery ]] (Olivier Richard)<br /> # [[Serrure à clé MIDI multifactorielle]] (Didier Donsez)<br /> # [[Table interactive musicale]] (Didier Donsez)<br /> # [[iMailbox]] (Didier Donsez)<br /> # [[AmILight]] (eclairage d'ambience intelligent) (Didier Donsez)<br /> # [[PDAmeetPDA]] (synchronisation d'agenda) (Michaël Périn)<br /> # [[1 000 000 VMs]] (expérimentation d'application distribuée à très grande échelle) (Olivier Richard) (2-3 RICM4)<br /> # [[Multiple Kinect]] (utilisation simultanée de plusieurs Kinect) (Olivier Richard) (RICM ou 3I)<br /> # [[Kinect musicale]] (Didier Donsez) (RICM)<br /> # [[Ktechlab Simavr Arduino | Ktechlab et integration de Simavr(Arduino)]] (Olivier Richard) (2-3 RICM4-SR)<br /> # Ocaml on AVR (Arduino)<br /> # Ocaml on Cortex-M3<br /> # [[Arduino on STM32 Discovery]]<br /> # [[Reverse Geocache Puzzle Box]]<br /> # [[OSGi ME]] (Didier Donsez)<br /> # [[Affichage Etudiant à Polytech]]<br /> # Synthèse 3D + motion capture Kinect<br /> # Logiciel d'[[apprentissage du calcul]] sur tablette Android (reconnaissance de chiffres manuscrits)<br /> # Plancher de verre (saint gobain) à la [http://www.wat.tv/video/mickael-jackson-billie-jean-oewj_2ey2h_.html Mickael Jackson dans Billie Jean] ! woo<br /> # [[Ktechlab Simavr Arduino | Ktechlab et integration de Simavr(Arduino)]] (Olivier Richard) (2-3 RICM4-SR)<br /> # [[CNC]]<br /> # [[Idées en Vrac]]<br /> # Scheme Everywhere (Olivier Richard) (2-3 RICM4-SR)<br /> # [[Projet Station Météo]]<br /> # Ocaml on AVR (Arduino)<br /> # [[Table interactive musicale]] (Didier Donsez)<br /> # [[AmILight]] (eclairage d'amnbience intelligent) (Didier Donsez)<br /> # [[Cube pointeur]] d'activité ingénieur<br /> # [http://www.instructables.com/id/Puppeteer-Motion-Capture-Costume/ Puppeteer Motion-Capture Costume]<br /> # [[Musical Staircase]] @ Polytech (Didier Donsez, 1 RICM4 + 1 3I4)<br /> # [[Total Recall]] (Didier Donsez)<br /> # [[SoundMachine]]<br /> # [[IGN-OSM|Importation de données IGN publiques dans OSM]]<br /> # [[Speed-limit-OSM|Analyse de traces GPX pour déterminer les limitations de vitesse]]<br /> # [[Multi perceptual cameras]] (Didier Donsez)<br /> # [[Photomaton 3D]] (Didier Donsez)<br /> # [[ArduCopter]]<br /> # [[Parking Intelligent]]<br /> # Frontend Web multi-utilisateur pour un jeu sérieux d'entreprise : Didier Donsez, Stéphanie Diligent, Emmanuelle Tréhoust.<br /> # Construction d'un roadbook d'ultratrail (mais aussi trek, randonnée, cyclisme, ...) à partir de traces GPX et des réseaux sociaux (Strava, Trace de Trail, ...): Didier Donsez</div>

Zoran.Chanet https://air.imag.fr/index.php?title=RICM4_2017_2018_-_Nucleo/_SRS&diff=44905 2019-02-11T08:49:55Z

<p>Zoran.Chanet: </p> <hr /> <div>The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard.<br /> <br /> <br /> {|class=&quot;wikitable alternance&quot;<br /> |+ Document History<br /> |-<br /> |<br /> !scope=&quot;col&quot;| Version<br /> !scope=&quot;col&quot;| Date<br /> !scope=&quot;col&quot;| Authors<br /> !scope=&quot;col&quot;| Description<br /> !scope=&quot;col&quot;| Validator<br /> !scope=&quot;col&quot;| Validation Date<br /> |-<br /> !scope=&quot;row&quot; |<br /> | 0.1.0<br /> | 2018<br /> | [[User:Zoran.Chanet | CHANET Zoran]] - [[User:Servan.Charlot | CHARLOT Servan]]<br /> | TBC<br /> | TBC<br /> | TBC<br /> <br /> |}<br /> <br /> <br /> =1. Introduction=<br /> ==1.1 Purpose of the requirements document==<br /> This Software Requirements Specification document explains the ins and outs of the Nucleo project, along with the requirements and specifications.<br /> <br /> ==1.2 Scope of the product==<br /> This product is dedicated to whoever uses a Nucleo card and needs or want to remotely reprogram it.<br /> <br /> As it is redistributable, this product may be used for personal or industrial use.<br /> <br /> ==1.3 Definitions, acronyms and abbreviations==<br /> Nucleo : for this project, a STM32F446 Nucleo-64 card will be used<br /> <br /> Arduino/Olimexino : for this project, an olimexino-328 will be used<br /> <br /> Wifi : for this project, an esp8266ex (or an ESP1-12 WEMOS) chipset will be used<br /> <br /> SRS : Software Requirements Specification<br /> <br /> ==1.4 References==<br /> * [[Projets_2017-2018 | Projects list]]<br /> * [[RICM4_2017_2018_-_Nucleo | Fiche]]<br /> * [[RICM4_2017_2018_-_Nucleo/UML | UML]]<br /> * [[Deploiment_Nucleo | Documentation]]<br /> <br /> ==1.5 Overview of the remainder of the document==<br /> The remainder of this SRS clarifies the requirements of the Nucleo project.<br /> <br /> =2. General description=<br /> ==2.1 Product perspective==<br /> Redistributable software allowing to dynamically remotely reprogram a Nucleo card through Wifi with the use of an ESP card.<br /> <br /> ==2.2 Product functions==<br /> Remotely reprogram a Nucleo card through Wifi with the use of an ESP card<br /> <br /> ==2.3 User characteristics==<br /> Both personal and industrial use.<br /> The product may be useful for an user who would like to reprogram its Nucleo card from a near remote location (because it may be inaccessible for some reasons).<br /> <br /> ==2.4 General constraints==<br /> - Security (not anyone should reprogram the card)<br /> <br /> - Reliability (what happens if the connexion stops while sending the new software ?)<br /> <br /> ==2.5 Assumptions and dependencies==<br /> It is needed to have an ESP8266EX plugged on a ST32F446 Nucleo (for the flashing purposes), and the computer who will send the binary through wifi.<br /> <br /> =3.Specific requirements, covering functional, non-functional and interface requirements=<br /> * document external interfaces,<br /> * describe system functionality and performance<br /> * specify logical database requirements,<br /> * design constraints,<br /> * emergent system properties and quality characteristics.<br /> <br /> ==3.1 Requirement | Reprogramming==<br /> '''Function''': Reprogramming the Nucleo via Wifi<br /> <br /> '''Description''': Sending a compiled program to the Nucleo<br /> <br /> '''Inputs''': Binary file (compiled program)<br /> <br /> '''Source''': User<br /> <br /> '''Outputs''': None<br /> <br /> '''Destination''': The ESP then the Nucleo card<br /> <br /> '''Action''': Reprograms the Nucleo card<br /> <br /> Natural language sentences (with MUST, MAY, SHALL)<br /> * The file sent MUST be a compiled program<br /> * The Nucleo card SHALL reprogram itself with the file (implying it has the proper software installed)<br /> * In case of malfunction, reset or shutdown during the transfer of the file, the Nucleo card MUST ignore the operation<br /> <br /> Graphical Notations : [[RICM4_2017_2018_-_Nucleo/UML | UML diagram and Sequences diagram]]<br /> <br /> '''Non functional requirements''': None.<br /> <br /> '''Pre-condition''': The ESP must display its wifi network and the user must be connected to it.<br /> <br /> '''Post-condition''': None.<br /> <br /> '''Side-effects''': None.<br /> <br /> =4. Product evolution=<br /> An interesting evolution for the project could be the development of a simplified user interface to connect to the ESP and send the binary to it.<br /> <br /> =5. Appendices=<br /> '''SRS related documents used to establish this page:'''<br /> * http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx<br /> * http://en.wikipedia.org/wiki/Software_requirements_specification<br /> * [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]<br /> <br /> = Links =<br /> * [[Projets_2017-2018 | Projects list]]<br /> * [[RICM4_2017_2018_-_Nucleo | Fiche]]<br /> * [[RICM4_2017_2018_-_Nucleo/UML | UML]]<br /> * [[Deploiment_Nucleo | Documentation]]</div>

Zoran.Chanet https://air.imag.fr/index.php?title=VT2018&diff=44904 2019-02-11T08:48:55Z

<p>Zoran.Chanet: /* Planning */</p> <hr /> <div>[[VT2017|&lt;&lt; Etudes 2017]] [[VT|Sommaire]] [[VT2019|Etudes 2019 &gt;&gt;]]<br /> <br /> <br /> =Veille Technologique et Stratégique=<br /> * Enseignants: [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]<br /> * UE/Module: EAM (HPRJ9R6B) et EAR (HPRJ9R4B) en RICM5<br /> <br /> L'objectif de cette UE est de réaliser un travail de synthèse et d’évaluation sur une technologie / spécification / tendance<br /> <br /> Dans votre futur vie d'ingénieur, vous aurez à d'une part, vous former par vous-même sur une technologie émergente et d'autre part à réaliser une veille technologique (et stratégique) par rapport à votre entreprise et projet.<br /> Il s'agira de réaliser<br /> * le positionnement par rapport au marché<br /> * d'être critique<br /> <br /> Votre synthèse fait l'objet d'une présentation orale convaincante devant un auditoire (dans le futur, vos collègues, vos chefs ou vos clients) avec des transparents et un discours répété.<br /> Pour finir de convaincre (Saint Thomas), vous ferez la présentation d'une démonstration.<br /> <br /> Votre présentation sera noté et commenté par tous vos camarades via un sondage (téléphone mobile). Leurs notes et leurs commentaires seront notés en fonction de leur exactitude de jugement.<br /> <br /> Remarque: Le [https://fr.wikipedia.org/wiki/Plagiat plagiat] est incompatible avec l'éthique de l'ingénieur. Le directeur d'école peut demander à votre traduction devant la commission disciplinaire de l'université. La sanction peut aller jusqu’à une interdiction d'inscription dans les établissements de l'enseignement supérieur français pendant plusieurs années : Le jeu, en vaut-il la chandelle ?<br /> <br /> La présentation peut être réalisée avec [[reveal.js]]<br /> <br /> [[File:presentation-VT-RICM5-1516.pdf|transparents d'introduction à l'UE]]<br /> <br /> =Affectation des sujets=<br /> [[File:AffectationSujetsVT2018.pdf]]<br /> <br /> =Planning=<br /> * Vendredi 7/9: présentation et choix des sujets<br /> [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]<br /> * Lundi 12/11: (GPB,DD en visio)<br /> ** 1: Julien COURTIAL - Apollo 2.0, [[VT2018_Apollo|Fiche de synthèse]], [[Media:Apollo_Auto_Platform.pdf|Transparents]], [https://github.com/ApolloAuto/apollo/tree/master/docs/demo_guide Démo]<br /> ** 2: Sekina BELGUENDOUZ - Service Mesh, [[VT2018_Service_Mesh|Fiche de synthèse]], [[Media:VT2018_Service_Mesh_presentation.pdf|Transparents]], [[VT2018_Service_Mesh_Demo|Démo avec Istrio]] (Reporté)<br /> ** 3: [[User:Servan.Charlot | Servan CHARLOT]] - [[OpenWhisk]] : [[VT2018_OpenWhisk|Fiche de synthèse]], [[Media:VT2018_OpenWhisk_presentation.pdf|Transparents]], [[VT2018_OpenWhisk_Demo|Démo]]<br /> ** 4: Théo ECHEVET - Fabric8, [[VT2018_fabric8|Fiche de synthèse]], [[Media:Fabric8_Pres_Theo_Echevet.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]<br /> ** 5: Bastien TERRIER - [[Performance_Monitoring|Performance Monitoring]], [[VT2018_Performance_Monitoring|Fiche de synthèse]], [[Media:VT2018_Performance_Monitoring_presentation.pdf|Transparents]], [[VT2018_Performance_Monitoring_Demo|Démo]]<br /> * Lundi 19/11: (GPB,DD en visio)<br /> ** 6: Samuel BAMBA - DevSecOps, [[VT2018_DevSecOps|Fiche de synthèse]], [[Media:VT2018_DevSecOps.pdf|Transparents]], [https://github.com/CoolerVoid/codewarrior Démo]<br /> ** 7: [[User:Zoran.Chanet | Zoran CHANET]] - [[Wildfly_Swarm|&lt;strike&gt;Wildfly Swarm&lt;/strike&gt;]] [[Thorntail|Thorntail]], [[VT2018_Thorntail|Fiche de synthèse]], [[Media:VT2018_Thorntail_presentation.pdf|Transparents]], [[VT2018_Thorntail_Demo|Démo]] (reporté)<br /> ** 8: Thibaud VEGREVILLE, Techniques et technologies de &quot;Lag Compensation&quot; dans les jeux en ligne, [[VT2018_Lag_Compensation|Fiche de synthèse]], [[Media:Lag_Compensation_in_Games.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]<br /> ** 9: Hugo GROS-DAILLON - [[ActionHero.js]], [[VT2018_ActionHero|Fiche de synthèse]], [[Media:VT2018ActionHero.pdf|Transparents]], [https://github.com/HugoSecteur4/DemoVT2018ActionHero/tree/master/ActionHero Démo]<br /> ** 10: Vincent AUBERT - Apache MXNet : Demo avec Intel Movidius, [[VT2018_Apache_Mxnet|Fiche de synthèse]], [[Media:VT2018_Mxnet_presentation.pdf|Transparents]], [[VT2018_Mxnet_Demo|Démo]]<br /> * Lundi 10/12: (GPB+DD)<br /> ** 11: Joffrey FERREIRA - Keycloak, [[VT2018_Keycloak|Fiche de synthèse]], [[Media:VT2018_Keycloak_presentation.pdf|Transparents]], [[VT2018_Keycloak_Demo|Démo]]<br /> ** 12: Loris GENTILLON - Gceasy, [[VT2018_GCeasy-synthese|Fiche de synthèse]], [[Media:GCeasy_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]] <br /> ** 13: Thomas OZENDA - Zipkin et Daper, [[VT2018_Zipkin|Fiche de synthèse]], [[Media:VT2018_Zipkin_presentation.pdf|Transparents]], [[VT2018_Zipkin_Demo|Démo]]<br /> ** 14: Aurélien SURIER - CloudFoundry, [[VT2018_CloudFoundry|Fiche de synthèse]], [[Media:VT2018_CloudFoundry_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]] (reporté) <br /> ** 15: Enzo MOLION - Web3j, [[VT2018_Web3j|Fiche de synthèse]], [[Media:Presentation_Web3j.pdf|Transparents]], [https://air.imag.fr/index.php/VT2018_Web3j#D.C3.A9monstration Démo]<br /> * Lundi 17/12: (GPB)<br /> ** 16: Quentin FOMBRAON - Web Assembly, [[VT2018_WebAssembly|Fiche de synthèse]], [[Media:VT2018_WebAssembly_presentation.pdf|Transparents]], [[VT2018_WebAssembly#D.C3.A9monstration|Démo]]<br /> ** 17: Timothée DEPRIESTER - Kafka Stream, [[VT2018_Kafka|Fiche de synthèse]], [[Media:VT2018_kafka_presentation.pdf|Transparents]], [[VT2018_kafka_Demo|Démo]]<br /> ** 18: Benjamin BESNIER - Apache Beam, [[VT2018_ApacheBeam|Fiche de synthèse]], [[Media:VT2018_ApacheBeam_presentation.pdf|Transparents]], [[VT2018_ApacheBeam#Demonstration|Démo]]<br /> ** 19: Théo LEVESQUE - OpenShift, [[VT2018_OpenShift|Fiche de synthèse]], [[Media:VT2018_OpenShift.pdf|Transparents]], [[VT2018_OpenShift#D.C3.A9monstration|Démo]]<br /> ** 20: William WEILL - CMS, [[VT2018_CrafterCMS|Fiche de synthèse]], [[Media:VT2018_CrafterCMS.pdf|Transparents]], [[VT2018_CrafterCMS#D.C3.A9monstration|Démo]]<br /> * Lundi 07/01/2019: (GPB+DD)<br /> ** 21: Tim LEPAGE - Moby, [[VT2018_Moby|Fiche de synthèse]], [[Media:VT2018_Moby_presentation.pdf|Transparents]], [[VT2018_Moby_Demo|Démo]]<br /> ** 22: Cédric LAFRASSE - SIG, [[VT2018_SIG|Fiche de synthèse]], [[Media:VT2018_SIG_presentation.pdf|Transparents]], [[VT2018_SIG#Demonstration|Démo]]<br /> ** 23: Léo VALETTE - Architectures de processeurs pour le Deep Learning (NPU): Démo de l'Intel Movidius, , [[VT2018_NPU|Fiche de synthèse]], [[Media:VT2018_NPU_presentation.pdf|Transparents]], [[VT2018_NPU_Demo|Démo]]<br /> ** 24: Florian CUZIN - Hazelcast IMDG, [[VT2018_Hazelcast_IMDG|Fiche de synthèse]], [[Media:Hazelcast_IMDG_Presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]<br /> ** 25: Raphael MANGER - Apache Solr, [[VT2018_Apache_Solr|Fiche de synthèse]], [[Media:Apache_Solr.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]<br /> * Lundi 14/01/2019: (GPD+DD)<br /> ** 26: Amina BOUCHERIMA - Content delivery networks, [[VT2018_CDN|Fiche de synthèse]], [[Media:VT2018_CDN_presentation.pdf|Transparents]], [[VT2018_CDN_Demo|Démo]]<br /> ** 27: Najwa EZ-ZINE - FIDO, [[VT2018_FIDO|Fiche de synthèse]], [[Media:VT2018FIDOUPLOAD.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]<br /> ** 28: Sekina BELGUENDOUZ - Service Mesh, [[VT2018_Service_Mesh|Fiche de synthèse]], [[Media:VT2018_Service_Mesh_presentation.pdf|Transparents]], [https://medium.freecodecamp.org/jhipster-microservices-with-istio-service-mesh-on-kubernetes-a7d0158ba9a3 Démo avec Istio]<br /> ** 29: [[User:Zoran.Chanet | Zoran CHANET]] - [[Wildfly_Swarm|&lt;strike&gt;Wildfly Swarm&lt;/strike&gt;]] [[Thorntail|Thorntail]], [[VT2018_Thorntail|Fiche de synthèse]], [[Media:VT2018_Thorntail_presentation.pdf|Transparents]], [[VT2018_Thorntail_Demo|Démo]]<br /> ** 30: Aurélien SURIER - CloudFoundry, [[VT2018_CloudFoundry|Fiche de synthèse]], [[Media:VT2018_CloudFoundry_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]</div>

Zoran.Chanet https://air.imag.fr/index.php?title=VT2018&diff=44903 2019-02-11T08:48:15Z

<p>Zoran.Chanet: /* Planning */</p> <hr /> <div>[[VT2017|&lt;&lt; Etudes 2017]] [[VT|Sommaire]] [[VT2019|Etudes 2019 &gt;&gt;]]<br /> <br /> <br /> =Veille Technologique et Stratégique=<br /> * Enseignants: [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]<br /> * UE/Module: EAM (HPRJ9R6B) et EAR (HPRJ9R4B) en RICM5<br /> <br /> L'objectif de cette UE est de réaliser un travail de synthèse et d’évaluation sur une technologie / spécification / tendance<br /> <br /> Dans votre futur vie d'ingénieur, vous aurez à d'une part, vous former par vous-même sur une technologie émergente et d'autre part à réaliser une veille technologique (et stratégique) par rapport à votre entreprise et projet.<br /> Il s'agira de réaliser<br /> * le positionnement par rapport au marché<br /> * d'être critique<br /> <br /> Votre synthèse fait l'objet d'une présentation orale convaincante devant un auditoire (dans le futur, vos collègues, vos chefs ou vos clients) avec des transparents et un discours répété.<br /> Pour finir de convaincre (Saint Thomas), vous ferez la présentation d'une démonstration.<br /> <br /> Votre présentation sera noté et commenté par tous vos camarades via un sondage (téléphone mobile). Leurs notes et leurs commentaires seront notés en fonction de leur exactitude de jugement.<br /> <br /> Remarque: Le [https://fr.wikipedia.org/wiki/Plagiat plagiat] est incompatible avec l'éthique de l'ingénieur. Le directeur d'école peut demander à votre traduction devant la commission disciplinaire de l'université. La sanction peut aller jusqu’à une interdiction d'inscription dans les établissements de l'enseignement supérieur français pendant plusieurs années : Le jeu, en vaut-il la chandelle ?<br /> <br /> La présentation peut être réalisée avec [[reveal.js]]<br /> <br /> [[File:presentation-VT-RICM5-1516.pdf|transparents d'introduction à l'UE]]<br /> <br /> =Affectation des sujets=<br /> [[File:AffectationSujetsVT2018.pdf]]<br /> <br /> =Planning=<br /> * Vendredi 7/9: présentation et choix des sujets<br /> [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]<br /> * Lundi 12/11: (GPB,DD en visio)<br /> ** 1: Julien COURTIAL - Apollo 2.0, [[VT2018_Apollo|Fiche de synthèse]], [[Media:Apollo_Auto_Platform.pdf|Transparents]], [https://github.com/ApolloAuto/apollo/tree/master/docs/demo_guide Démo]<br /> ** 2: Sekina BELGUENDOUZ - Service Mesh, [[VT2018_Service_Mesh|Fiche de synthèse]], [[Media:VT2018_Service_Mesh_presentation.pdf|Transparents]], [[VT2018_Service_Mesh_Demo|Démo avec Istrio]] (Reporté)<br /> ** 3: [[User:Servan.Charlot | Servan CHARLOT]] - [[OpenWhisk]] : [[VT2018_OpenWhisk|Fiche de synthèse]], [[Media:VT2018_OpenWhisk_presentation.pdf|Transparents]], [[VT2018_OpenWhisk_Demo|Démo]]<br /> ** 4: Théo ECHEVET - Fabric8, [[VT2018_fabric8|Fiche de synthèse]], [[Media:Fabric8_Pres_Theo_Echevet.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]<br /> ** 5: Bastien TERRIER - [[Performance_Monitoring|Performance Monitoring]], [[VT2018_Performance_Monitoring|Fiche de synthèse]], [[Media:VT2018_Performance_Monitoring_presentation.pdf|Transparents]], [[VT2018_Performance_Monitoring_Demo|Démo]]<br /> * Lundi 19/11: (GPB,DD en visio)<br /> ** 6: Samuel BAMBA - DevSecOps, [[VT2018_DevSecOps|Fiche de synthèse]], [[Media:VT2018_DevSecOps.pdf|Transparents]], [https://github.com/CoolerVoid/codewarrior Démo]<br /> ** 7: [[User:Zoran.Chanet | Zoran CHANET]] - [[Wildfly_Swarm|&lt;strike&gt;Wildfly Swarm&lt;/strike&gt;]] [[Thorntail|Thorntail]], [[VT2018_Thorntail|Fiche de synthèse]], [[Media:VT2018_Thorntail_presentation.pdf|Transparents]], [[VT2018_Thorntail_Demo|Démo]] (reporté)<br /> ** 8: Thibaud VEGREVILLE, Techniques et technologies de &quot;Lag Compensation&quot; dans les jeux en ligne, [[VT2018_Lag_Compensation|Fiche de synthèse]], [[Media:Lag_Compensation_in_Games.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]<br /> ** 9: Hugo GROS-DAILLON - [[ActionHero.js]], [[VT2018_ActionHero|Fiche de synthèse]], [[Media:VT2018ActionHero.pdf|Transparents]], [https://github.com/HugoSecteur4/DemoVT2018ActionHero/tree/master/ActionHero Démo]<br /> ** 10: Vincent AUBERT - Apache MXNet : Demo avec Intel Movidius, [[VT2018_Apache_Mxnet|Fiche de synthèse]], [[Media:VT2018_Mxnet_presentation.pdf|Transparents]], [[VT2018_Mxnet_Demo|Démo]]<br /> * Lundi 10/12: (GPB+DD)<br /> ** 11: Joffrey FERREIRA - Keycloak, [[VT2018_Keycloak|Fiche de synthèse]], [[Media:VT2018_Keycloak_presentation.pdf|Transparents]], [[VT2018_Keycloak_Demo|Démo]]<br /> ** 12: Loris GENTILLON - Gceasy, [[VT2018_GCeasy-synthese|Fiche de synthèse]], [[Media:GCeasy_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]] <br /> ** 13: Thomas OZENDA - Zipkin et Daper, [[VT2018_Zipkin|Fiche de synthèse]], [[Media:VT2018_Zipkin_presentation.pdf|Transparents]], [[VT2018_Zipkin_Demo|Démo]]<br /> ** 14: Aurélien SURIER - CloudFoundry, [[VT2018_CloudFoundry|Fiche de synthèse]], [[Media:VT2018_CloudFoundry_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]] (reporté) <br /> ** 15: Enzo MOLION - Web3j, [[VT2018_Web3j|Fiche de synthèse]], [[Media:Presentation_Web3j.pdf|Transparents]], [https://air.imag.fr/index.php/VT2018_Web3j#D.C3.A9monstration Démo]<br /> * Lundi 17/12: (GPB)<br /> ** 16: Quentin FOMBRAON - Web Assembly, [[VT2018_WebAssembly|Fiche de synthèse]], [[Media:VT2018_WebAssembly_presentation.pdf|Transparents]], [[VT2018_WebAssembly#D.C3.A9monstration|Démo]]<br /> ** 17: Timothée DEPRIESTER - Kafka Stream, [[VT2018_Kafka|Fiche de synthèse]], [[Media:VT2018_kafka_presentation.pdf|Transparents]], [[VT2018_kafka_Demo|Démo]]<br /> ** 18: Benjamin BESNIER - Apache Beam, [[VT2018_ApacheBeam|Fiche de synthèse]], [[Media:VT2018_ApacheBeam_presentation.pdf|Transparents]], [[VT2018_ApacheBeam#Demonstration|Démo]]<br /> ** 19: Théo LEVESQUE - OpenShift, [[VT2018_OpenShift|Fiche de synthèse]], [[Media:VT2018_OpenShift.pdf|Transparents]], [[VT2018_OpenShift#D.C3.A9monstration|Démo]]<br /> ** 20: William WEILL - CMS, [[VT2018_CrafterCMS|Fiche de synthèse]], [[Media:VT2018_CrafterCMS.pdf|Transparents]], [[VT2018_CrafterCMS#D.C3.A9monstration|Démo]]<br /> * Lundi 07/01/2019: (GPB+DD)<br /> ** 21: Tim LEPAGE - Moby, [[VT2018_Moby|Fiche de synthèse]], [[Media:VT2018_Moby_presentation.pdf|Transparents]], [[VT2018_Moby_Demo|Démo]]<br /> ** 22: Cédric LAFRASSE - SIG, [[VT2018_SIG|Fiche de synthèse]], [[Media:VT2018_SIG_presentation.pdf|Transparents]], [[VT2018_SIG#Demonstration|Démo]]<br /> ** 23: Léo VALETTE - Architectures de processeurs pour le Deep Learning (NPU): Démo de l'Intel Movidius, , [[VT2018_NPU|Fiche de synthèse]], [[Media:VT2018_NPU_presentation.pdf|Transparents]], [[VT2018_NPU_Demo|Démo]]<br /> ** 24: Florian CUZIN - Hazelcast IMDG, [[VT2018_Hazelcast_IMDG|Fiche de synthèse]], [[Media:Hazelcast_IMDG_Presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]<br /> ** 25: Raphael MANGER - Apache Solr, [[VT2018_Apache_Solr|Fiche de synthèse]], [[Media:Apache_Solr.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]<br /> * Lundi 14/01/2019: (GPD+DD)<br /> ** 26: Amina BOUCHERIMA - Content delivery networks, [[VT2018_CDN|Fiche de synthèse]], [[Media:VT2018_CDN_presentation.pdf|Transparents]], [[VT2018_CDN_Demo|Démo]]<br /> ** 27: Najwa EZ-ZINE - FIDO, [[VT2018_FIDO|Fiche de synthèse]], [[Media:VT2018FIDOUPLOAD.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]<br /> ** 28: Sekina BELGUENDOUZ - Service Mesh, [[VT2018_Service_Mesh|Fiche de synthèse]], [[Media:VT2018_Service_Mesh_presentation.pdf|Transparents]], [https://medium.freecodecamp.org/jhipster-microservices-with-istio-service-mesh-on-kubernetes-a7d0158ba9a3 Démo avec Istio]<br /> ** 29: Zoran CHANET - [[Wildfly_Swarm|&lt;strike&gt;Wildfly Swarm&lt;/strike&gt;]] [[Thorntail|Thorntail]], [[VT2018_Thorntail|Fiche de synthèse]], [[Media:VT2018_Thorntail_presentation.pdf|Transparents]], [[VT2018_Thorntail_Demo|Démo]]<br /> ** 30: Aurélien SURIER - CloudFoundry, [[VT2018_CloudFoundry|Fiche de synthèse]], [[Media:VT2018_CloudFoundry_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]</div>

Zoran.Chanet https://air.imag.fr/index.php?title=Projets_2017-2018&diff=44902 2019-02-11T08:47:10Z

<p>Zoran.Chanet: /* Affectations */</p> <hr /> <div>&lt;&lt;[[Projets 2016-2017]] | [[Projets]] | [[Projets 2018-2019]]&gt;&gt;<br /> =RICM=<br /> ==RICM3==<br /> <br /> ==RICM4==<br /> ===Projet Semestre S8===<br /> <br /> Enseignants responsables : Olivier Richard, Didier Donsez<br /> <br /> * Dates : Lundi après-midi, Mardi après-midi <br /> * Lancement: 15/01/2018 en 257 à 15h45<br /> * Soutenances: '''Lundi 9 avril''': [[Ordre_passages_soutenances_RICM4_2017_2018 | Ordre de passages]]<br /> * Soutenances à mi-parcours: Lundi 12 et mardi 13 mars: [[ordre_passages_mi_parcours_RICM4_2017_2018 | Ordre de passages]]<br /> <br /> * '''Evaluation à mi-parcours le lundi/mardi ???''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.<br /> <br /> '''Consignes générales:'''<br /> <br /> * '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: creuser la question, contacter l'auteur du code si il y a lieu, écrire un rapport de bug ('''Attention:''' ca se prépare !), soumettre un patch/pull request, contacter l'enseignant ou la personne référente du projet.<br /> <br /> * '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par ricm4_2017_2018. '''Cette fiche compte pour la note finale'''<br /> <br /> * '''Votre code''' pour doit être hébergé sur le gitlab et à l'URL suivante https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18 , vous utiliserez votre compte UGA.<br /> <br /> * Les documents public doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions). Une bonnification sera accordée si le rapport et les transparents sont en anglais (la soutenance sera en francais).<br /> <br /> '''Propositions de projets:'''<br /> <br /> # [[QCM C2I]] , Pierre Gillois, Didier Donsez<br /> # [[Dashboard pour gestionnaire de tâches]] (Angular 5): Olivier Richard<br /> # [[Moteur de workflows distribué]] (WDL/Cromwell): Olivier Richard <br /> # [[ESP32 et language D]]: Olivier Richard<br /> # [[Serious game multi-joueurs pour tables tactiles en réseau]] : Didier Donsez, Anne-Laure Finkel, Stéphanie Diligent.<br /> # [[Challenge OpenCity]] : Georges-Pierre Bonneau, Didier Donsez<br /> # Projet [[UltraTeam]] avec des trackers [[ESP32-LoRa]] + GPS : Reprise partielle du projet eCOM de gestion des courses sportives et du projet [[UltraTeam]] 2017 pour la partie backend et frontend du projet : Didier Donsez<br /> # Projet [[Réseau Social LoRa]] avec des pods [[ESP32-LoRa]] : Olivier Richard.<br /> # Contribution et evaluation au/du projet [https://github.com/IntelLabs/hpat HPAT] (A compiler-based big data framework in Python): Olivier Richard.<br /> # [[Ruche connectée LoRa]] : Nicolas Palix<br /> # [[Serres connectées]] : Nicolas Palix<br /> # [[I-Greenhouse]] : [[Serre connectée aquaponie]] : Nicolas Palix<br /> # Projet &quot;Plateforme de mise en relation pour les entrepreneurs sociaux&quot; : Didier Donsez<br /> # [[Chatbot pour borne d'accueil handicap]] : Didier Donsez, Marie-Paule Balicco et Jérôme Maisonnasse (service accueil handicap COMUE UGA)<br /> # Connected Shop (avec [[Eclipse SmartHome]]) : Didier Donsez.<br /> # [[Deploiment Nucleo | Déploiement sécurisé et sans fil pour carte Nucleo]]: Olivier Richard et Sylain Toru<br /> # [[RobAIR]] : Cobot Majordome : Jérôme Maisonnasse, Germain Lemasson, Bastien Scher (FabMSTIC).<br /> <br /> ==== Affectations ====<br /> {|class=&quot;wikitable alternance&quot;<br /> |+ Affectation des projets RICM4 2017-2018<br /> |-<br /> |<br /> !scope=&quot;col&quot;| Sujet<br /> !scope=&quot;col&quot;| Etudiants<br /> !scope=&quot;col&quot;| Enseignant(s)<br /> !scope=&quot;col&quot;| Fiche de suivi<br /> !scope=&quot;col&quot;| Dépot git<br /> |-<br /> <br /> !scope=&quot;row&quot;| 1<br /> | [[QCM C2I]]<br /> | NON ATTRIBUÉ<br /> | Pierre Gillois, Didier Donsez<br /> | [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]<br /> | <br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 2<br /> | [[Dashboard pour gestionnaire de tâches]] (Angular 5)<br /> | BELGUENDOUZ Sekina, LARNICOL Titouan<br /> | Olivier Richard<br /> | [[RICM4_2017_2018_-_Dashboard| Fiche]] - [[RICM4_2017_2018_-_Dashboard/SRS|SRS]] - [[RICM4_2017_2018_-_Dashboard/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/2 gitlab]<br /> | [[Media:RICM4_2017_2018_-_Dashboard-Rapport.pdf|Rapport final]] - [[Media:RICM4_2017_2018_-_Dashboard-Presentation_Finale-FR.pdf|Presentation finale FR]] - [[Media:RICM4_2017_2018_-_Dashboard-Presentation_Finale-EN.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Dashboard_en.pdf|Presentation de mi-parcours EN]] - [[Media:Dashboard_fr.pdf|Presentation de mi-parcours FR]] - [[Media:Dashboard_fr.pptx|Presentation de mi-parcours en pptx]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 3<br /> | [[Moteur de workflows distribué]] (WDL/Cromwell)<br /> | NON ATTRIBUÉ<br /> | Olivier Richard<br /> | [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]<br /> | <br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 4<br /> | [[ESP32 et language D]]<br /> | MANGER Raphael, HOUBRON Adrian<br /> | Olivier Richard<br /> | [[RICM4_2017_2018_-_ESP32_D| Fiche]] - [[RICM4_2017_2018_-_ESP32_D/_SRS|SRS]] - [[RICM4_2017_2018_-_ESP32_D/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/4 gitlab]<br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 5<br /> | [[Serious game multi-joueurs pour tables tactiles en réseau]]<br /> | LEPAGE Tim, SERGEANT Dimitri <br /> | Didier Donsez, Anne-Laure Finkel, Stéphanie Diligent<br /> | [[RICM4_2017_2018_-SeriousGame Polystar | Fiche]] - [[RICM4_2017_2018_- SeriousGame Polystar /_SRS|SRS]] - [[RICM4_2017_2018_- SeriousGame Polystar /UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/5 gitlab]<br /> | [[Media:Polystar_Final_Report_Lepage_Sergeant.pdf|Rapport final]] - [[Media:Final_presentation_Polystar.pdf|Presentation finale FR]] - [[Media:affiche_Polystar.pdf|Affiche]] - [[Media:PolyStar.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 6<br /> | [[Challenge OpenCity]]<br /> | BOUCHERIMA Amina, FOMBARON Quentin<br /> | Georges-Pierre Bonneau, Didier Donsez<br /> | [[RICM4_2017_2018_-_OpenCity| Fiche]] - [[RICM4_2017_2018_-_OpenCity/_SRS|SRS]] - [[RICM4_2017_2018_-_OpenCity/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/6 gitlab]<br /> | [[Media:Projet-RICM4 OpenCity Rapport.pdf|Rapport final]] - [http://www.quentinfombaron.fr/final_presentation_FR/ Presentation finale FR] - [http://www.quentinfombaron.fr/final_presentation_EN/ Final Presentation EN] - [[Media:-Projet-RICM4-OpenCity Flyer.jpg|Flyer]] - [http://www.quentinfombaron.fr/mi_presentation_FR/ Presentation de mi-parcours]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 7.1<br /> | Projet [[UltraTeam]] avec des trackers [[ESP32-LoRa]] + GPS<br /> | TERRIER Bastien, GROS-DAILLON Hugo <br /> | Didier Donsez<br /> | [[RICM4_2017_2018_-_UltraTeam_7.1| Fiche]] - [[RICM4_2017_2018_-_UltraTeam_7.1/_SRS|SRS]] - [[RICM4_2017_2018_-_UltraTeam_7.1/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/7.1 gitlab]<br /> | [[Media:Final_Report_UltraTeam7.1.pdf|Rapport final]] - [[Media:UltraTeam7.1_Final_PowerPoint_.pdf‎|Presentation finale FR]] - [[Media:UltraTeam7.1_Final_PowerPoint_.pdf‎|Final Presentation EN]] - [[Media:UltraTeam_7.1_Flyer.jpg|Flyer]] - [[Media:UltraTeam 7.1 Mid Presentation.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 7.2<br /> | Projet [[UltraTeam]] avec des trackers [[ESP32-LoRa]] + GPS<br /> | MOLION Enzo, VALETTE Léo<br /> | Didier Donsez<br /> | [[RICM4_2017_2018_-_UltraTeamMV| Fiche]] - [[RICM4_2017_2018_-_UltraTeamMV_:_SRS|SRS]] - [[RICM4_2017_2018_-_UltraTeamMV_:_UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/7.2 gitlab] - [https://github.com/ultratrail/UltraTeamMV GitHub]<br /> | [https://air.imag.fr/images/a/a3/UltrateamMVReport.pdf Rapport final] - [https://air.imag.fr/images/0/0e/UltraTeamMVFinalPresentationEN.pdf Final Presentation EN] - [https://air.imag.fr/images/b/b7/UltraTeamMVMidtermPresentationEN.pdf Presentation de mi-parcours]<br /> |-<br /> <br /> <br /> !scope=&quot;row&quot;| 8<br /> | Projet [[Réseau Social LoRa]] avec des pods [[ESP32-LoRa]]<br /> | VEGREVILLE Thibaud, GENTILLON Loris, ZHENG Jian<br /> | Olivier Richard<br /> | [[RICM4_2017_2018_-_Réseau_Social_LoRa| Fiche]] - [[RICM4_2017_2018_-_Réseau_Social_LoRa/_SRS|SRS]] - [[RICM4_2017_2018_-_Réseau_Social_LoRa/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/8 gitlab]<br /> | [https://air.imag.fr/images/7/7b/Final_report_social_network_lora.pdf Rapport final] - [https://air.imag.fr/images/f/f5/Final-presentation_social_network_lora.pptx Final Presentation EN]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 9<br /> | Contribution et evaluation au/du projet [https://github.com/IntelLabs/hpat HPAT]<br /> | NON ATTRIBUÉ<br /> | Olivier Richard<br /> | [[RICM4_2017_2018_-_| Fiche]] - [[RICM4_2017_2018_-_/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]<br /> | <br /> | [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 10<br /> | [[Ruche connectée LoRa]] <br /> | BESNIER Benjamin, LÉVESQUE Théo, WEILL William<br /> | Nicolas Palix<br /> | [[RICM4_2017_2018_-_Ruche_Connectee_| Fiche]] - [[RICM4_2017_2018_-_Ruche_Connectee_/_SRS|SRS]] - [[RICM4_2017_2018_-_Ruche_Connectee/UML | UML]] - [[Media:RICM4_2017_2018_-_Ruche_Connectee_-_Schedule.png|Schedule]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/10 gitlab]<br /> | [[Media:RICM4_2017_2018_-_Rapport_final.pdf|Rapport final]] - [[Media:Connected Hive final presentation.pdf|Final Presentation EN]] - [[Media:RICM4_2017_2018_-_Ruche_Connectee_Mi_parcours_presentation.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 11<br /> | [[Serres connectées]]<br /> | BESNARD Guillaume, DEPRIESTER Timothée<br /> | Nicolas Palix<br /> | [[RICM4_2017_2018_-_Serre_Connectee| Fiche]] - [[RICM4_2017_2018_-_Serre_Connectee_/_SRS|SRS]] - [[RICM4_2017_2018_-_Serre_Connecte/UML | UML]] - [[RICM4_2017_2018_-_Serre_Connecte/Schedule | Schedule]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/11 gitlab]<br /> | [[Media:RICM4_2017_2018_-_Serre_Connecte_Rapport_Final.pdf|Rapport final]] - [[Media:RICM4_2017_2018_-_Serre_Connecte_Presentation_Final_EN.pdf|Final Presentation EN]] - [[Media:RICM4_2017_2018_-_Serre_Connecte_Mi_parcours_presentation.pdf|Presentation de mi-parcours]] - [[Media:RICM4_2017_2018_-_Serre_Connecte_Poster.pdf|Poster]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 12<br /> | [[I-Greenhouse]] : [[Serre connectée aquaponie]] <br /> | SURIER GAROFALO Aurélien, FERREIRA Joffrey, OZENDA Thomas<br /> | Nicolas Palix<br /> | [[RICM4_2017_2018_-_IGreenHouse| Fiche]] - [[RICM4_2017_2018_-_IGreenHouse_/_SRS|SRS]] - [[IGreenHouse/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/12 gitlab]<br /> | [[Media:Rapport_Projet_I-Greenhouse_2017-2018.pdf‎|Rapport final]] - [[Media:Presentation 2017-2018 I-greenhouse.pdf|Presentation finale FR]] - [[Media:Presentation 2017-2018 I-greenhouse.pdf|Final Presentation EN]] - [[Media:Poster_i-greenhouse_2017-2018.pdf|Flyer]] - [[Media:Presentation_mi-parcours_i-greenhouse_2017-2018.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 13<br /> | Projet &quot;Plateforme de mise en relation pour les entrepreneurs sociaux&quot;<br /> | AUBERT Vincent, COURTIAL Julien<br /> | Didier Donsez<br /> | [[RICM4_2017_2018_-_Entrepreneur| Fiche]] - [[RICM4_2017_2018_-_Entrepreneur_AUBERT_COURTIAL/_SRS|SRS]] - [[RICM4_2017_2018_-_Entrepreneur_AUBERT_COURTIAL/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/13 gitlab]<br /> | [[Media:Rapport_Entrepreneur.pdf|Rapport final]] - [[Media:Soutenance_Entrepreneur_FR.pdf|Presentation finale FR]] - [[Media:Soutenance_Entrepreneur.pdf|Final Presentation EN]] - [[Media:Présoutenance_Projet.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> <br /> !scope=&quot;row&quot;| 14<br /> | [[Chatbot pour borne d'accueil handicap]]<br /> | AUCLAIR-CORDAT Julien, BAMBA Samuel<br /> | Didier Donsez, Marie-Paule Balicco et Jérôme Maisonnasse (service accueil handicap COMUE UGA) <br /> | [[RICM4_2017_2018_-_ChatBot| Fiche]] - [[RICM4_2017_2018_-_/_SRS|SRS]] - [[RICM4_2017_2018_-_/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/14 gitlab]<br /> | [[Media:Final_Report___Chatbot_SAH.pdf|Rapport final]] - [[Media:ChatBot.pdf|Presentation finale FR]] - [[Media:ChatBot.pdf|Final Presentation EN]] - [[Media:ChatBot.pdf|Flyer]] - [[Media:Chatbot_mi-parcours.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 15<br /> | Connected Shop (avec [[Eclipse SmartHome]])<br /> | CUZIN Florian, ECHEVET Théo<br /> | Didier Donsez<br /> | [[RICM4_2017_2018_-Connected_shop| Fiche]] - [[RICM4_2017_2018_-_Connected_shop_SRS|SRS]] - [[RICM4_2017_2018_-_Connected_Shops/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/15 gitlab]<br /> | [[Media:Rapport_Virtual_fitting_room.pdf|Rapport final]] - [[Media:Presentation_finale_virtual_fitting_room.pdf|Presentation finale FR]] - [[Media:Presentation_mi_soutenance_fr_Connected_Shops.pdf|Presentation de mi-parcours]] - [https://www.youtube.com/watch?v=qVNoHjpnASw&amp;feature=youtu.be Vidéo]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 16<br /> | [[Deploiment Nucleo | Déploiement sécurisé et sans fil pour carte Nucleo]]<br /> | [[User:Zoran.Chanet | CHANET Zoran]], [[User:Servan.Charlot | CHARLOT Servan]]<br /> | Olivier Richard, Sylain Toru<br /> | [[RICM4_2017_2018_-_Nucleo | Fiche]] - [[RICM4_2017_2018_-_Nucleo/_SRS|SRS]] - [[RICM4_2017_2018_-_Nucleo/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/16 gitlab]<br /> | [[Media:Final_Report_Nucleo_CHANET_CHARLOT.pdf|Rapport final]] - [[Media:Presentation_Finale_Nucleo.pdf|Presentation finale FR]] - [[Media:Nucleo Final Presentation.pdf‎|Presentation finale]] - [[Media:Projet_Nucleo_diapo_mi_parcours.pdf‎|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 17.1<br /> | [[RobAIR]] : Robot Majordome<br /> | DEVOS Xavier, LAFRASSE Cédric<br /> | Jérôme Maisonnasse, Germain Lemasson, Bastien Scher (FabMSTIC)<br /> | [[RICM4_2017_2018_-_RobAIR17-1| Fiche]] - [[RICM4_2017_2018_-_RobAIRDL/_SRS|SRS]] - [[RICM4_2017_2018_-_RobAIRDL/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/17.1 gitlab]<br /> | [[Media:RobAIRrapport.pdf|Rapport final]] - [[Media:Final_robair_fr.pdf|Presentation finale FR]] - [[Media:Final_robair.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:RobAIR_Robotics_guide.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 17.2<br /> | [[RobAIR]] : Robot Majordome<br /> | JEAN Jordan, EZ-ZINE Najwa<br /> | Jérôme Maisonnasse, Germain Lemasson, Bastien Scher (FabMSTIC)<br /> | [[RICM4_2017_2018_-_robair2| Fiche]] - [[RICM4_2017_2018_-_robair2/_SRS|SRS]] - [[RICM4_2017_2018_-_robair2/UML | UML]]<br /> | [https://gricad-gitlab.univ-grenoble-alpes.fr/Projet-RICM4/17-18/17.2 gitlab]<br /> | [[Media:Report_robair_tweet.pdf|Rapport final]] - [[Media:RobAIR.pdf|Presentation finale FR]] - [[Media:RobAIR.pdf|Final Presentation EN]] - [[Media:poster_robair.pdf|Flyer]] - [[Media:RobAIR-Mi-soutenance.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> |}<br /> <br /> ==RICM5==<br /> ===Projet IoT S9===<br /> Enseignants responsables : Bernard Tourancheau<br /> <br /> Calendrier: ??? Septembre à ??? Décembre 2017.<br /> <br /> * Projet IoT 3 : [[Ski-locator]] (Bernard Tourancheau)<br /> <br /> <br /> <br /> ===Projet Semestre S10===<br /> <br /> Enseignants responsables : Didier Donsez<br /> <br /> Calendrier: 29 Janvier à 15 Mars 2018.<br /> <br /> Séances de Management de projets innovants:<br /> * Mercredi 31/01 de 8h à 12h: Stéphanie Diligent<br /> * Mercredi 7 février de 8h à 12h : Stéphanie Diligent<br /> * Mardi 15 février de 8h à 12 : Emmanuelle Tréhoust<br /> * Lundi 26 février de 8h à 12h : Olivier Gilles<br /> * Mardi 13 mars de 8h à 12h : Stéphanie Diligent et Emmanuelle Tréhoust<br /> <br /> Réunion de présentation : 8 Janvier 2018 Matin à 9H00-10H00 (RdV Salle P257 et Salle AIR P259). Faire couler le café.<br /> <br /> Hackathon Vinci (8,9,10/02) : http://hacktogether.vinci-energies.com/<br /> <br /> Démarrage : Lundi 29 Janvier 2018<br /> <br /> Soutenance à mi-parcours : Mercredi 14 Février 2018, 8H00-11H00 (30 minutes par équipe).<br /> <br /> Rendu rapport de management : Mardi 13 Mars 2018 - Matin<br /> <br /> Soutenance (puis Pot de la fin) : Jeudi 15 Mars 2018<br /> <br /> Vendredi 16 Mars : 10000 ans de RICM<br /> <br /> <br /> ==== Planning soutenances mi-parcours ====<br /> Mercredi 14 Février 2018, salle P144, 8H00-11H00 (25 minutes TTC par équipe).<br /> <br /> * 8H00-8H30 [[Real Time Subtitles 2017-2018| Real Time Subtitles]]<br /> * 8H30-9H00 [[Deep Learning 2017-2018 | Deep Learning]]<br /> * 9H00-9H30 [[EasyFlight_2017-2018|EasyFlight]]<br /> * 9H30-10H00 [[ Réalité virtuelle et Augmentée pour la maintenance d'usines]]<br /> * 10H00-10H30 [[R'Montagne]]<br /> * 10H30-11H00 [[SmartMove]]<br /> * 11H00-11H30 [[RICM5 2017 2018 - UGAChain|UGAChain]]<br /> <br /> ==== Planning soutenances finales ====<br /> Jeudi 15 Mars 2018<br /> Matin (Salle P251)<br /> * 8H00-9H00 [[R'Montagne]] (50 minutes TTC)<br /> * 9H00-10H00 [[SmartMove]] (50 minutes TTC)<br /> * 10H00-11H00 (50 minutes TTC) [[ Réalité virtuelle et Augmentée pour la maintenance d'usines]]<br /> * 11H00-12H00 (50 minutes TTC) [[RICM5 2017 2018 - UGAChain|UGAChain]] : Blockchain for Education<br /> Pause déjeuner<br /> Matin (Salle P249)<br /> * 13H00-14H00 [[Real Time Subtitles 2017-2018| Real Time Subtitles]] (50 minutes TTC)<br /> * 14H00-15H00 [[SmartRecruiting]] (50 minutes TTC)<br /> * 15H00-16H00 [[EasyFlight_2017-2018|EasyFlight]] (50 minutes TTC)<br /> <br /> ====Instructions pour la soutenance====<br /> * Chaque soutenance comporte 20 minutes de présentation, 10 minutes de question et 20 minutes de démonstration. Un transparent doit être consacré au travail confié et réalisé par les étudiants en DUT (AVOSTI) pour R'Montagne.<br /> * La présentation est constituée des chapitres suivants:<br /> ** Rappel du sujet/besoin et cahier des charges<br /> ** Technologies employées<br /> ** Architecture techniques<br /> ** Réalisations techniques<br /> ** Gestion de projet (méthode, planning prévisionnel et effectif, gestion des risques, rôles des membres, ...)<br /> ** Outils (collaboration, CD/CI par exemple ...)<br /> ** Métriques logiciels : lignes de code, langages, performance, temps ingénieur (d'après vos journaux)...)<br /> ** Conclusion (Retour d'expérience)<br /> ** Transparent introduisant la démonstration<br /> * Répétez plusieurs fois votre présentation et votre démonstration. Il y aura des personnalités invitées. Prévoyez un démonstration filmée pour palier à l'effet &quot;démo&quot;.<br /> * L'ensemble des documents (y compris photos, vidéos et ''[[Logiciels#Screencast|screencast]]s'') doivent être accessibles depuis le tableau ci-dessous et dans chaque fiche de suivi. Prévoyez une copie sur clé USB.<br /> * Les étudiants de DUT vous accompagnent lors de votre soutenance et présenteront leur travail. Coordonnez vous avec eux et faites les répéter.<br /> * '''TOUT Le matériel prêté devra être rapporté et restitué dans un sac cabas lors de la soutenance.'''<br /> <br /> ==== Affectations ====<br /> {|class=&quot;wikitable alternance&quot;<br /> |+ Affectation des projets RICM5 2017-2018<br /> |-<br /> |<br /> !scope=&quot;col&quot;| Sujet<br /> !scope=&quot;col&quot;| Etudiants<br /> !scope=&quot;col&quot;| Enseignant(s)<br /> !scope=&quot;col&quot;| Fiche de suivi<br /> !scope=&quot;col&quot;| Dépot git<br /> |-<br /> <br /> <br /> !scope=&quot;row&quot;| 1<br /> | [[Real Time Subtitles 2017-2018| Sous-titre d'un cours en temps réel]]<br /> | '''Estelle ALLARD''' / Aymeric BROCHIER / Louis COCHINHO / Oriane DALLE / Alexandre FERRERA / Alice RIVOAL<br /> | Didier Donsez, Laurent Besacier, François Portet, Marie-Paule Balicco, Jérome Maisonnasse<br /> | [[Real Time Subtitles 2017-2018| Fiche]] - [[Real_Time_Subtitles_2017-2018/SRS|SRS]]<br /> | [https://gitlab.com/LouisCochinho/RealTimeSubtitles GitLab]<br /> | [[Media:RICM5_2017_2018_Real_time_subtitles_rapport.pdf|Rapport final]] - [[Media:RICM5_2017_2018_Real_time_subtitles_slides.pdf|Presentation finale]] - [[Media:RICM5_2017_2018_Real_time_subtitles_mi.pdf|Presentation de mi-parcours]] - [[Media:RICM5_2017_2018_Real_time_subtitles_flyer.pdf|Flyer]] - [[Media:RICM5_2017_2018_Real_time_subtitles_poster.pdf|Poster]] - [[Media:Demo_RealTimeSubtitles.rar|Video]]<br /> <br /> |-<br /> <br /> !scope=&quot;row&quot;| 2<br /> | [[Réalité Augmentée pour le Smart Campus 2018|Réalité Augmentée pour le Smart Campus]]<br /> | Lucas LESAGE / '''Denis LACHARTRE''' / Douria ZENNOUCHE / Gilles BONHOURE / Maxime DEREYMEZ<br /> | Didier Donsez, Georges-Pierre Bonneau<br /> | [[Campus_Augmente_2017-2018|Fiche]] - [[Media:SRS_ProjetAR_2018.pdf|SRS]] <br /> | [https://github.com/ProjetS10-CyberHoloMachin Organisation Git]<br /> | [[Media:Guide_developpeur_ProjetAR_2018.pdf|Guide developpeur]] - [[Media:Presentation_finale_ProjetAR_2018.pdf|Presentation finale ]] -[[Media : Cyberposter_ProjetAR_2018.pdf | Poster]] - [[Media:Rapport_final_MPI_ProjetAR_2018.pdf‎ | Rapport final MPI ]] - [[Media:Guide_utilisateur_ProjetAR_2018.pdf|Guide utilisateur]]- [[Media:Presentation_Mi_parcours_ProjetAR_2018.pdf|Presentation de mi-parcours]] - [http://youtulle.com/XXXX Vidéo 1]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 3<br /> | SmartRecruiting : [[SmartRecruiting|Deep Learning]] avec [[TensorFlow]] sur les référentiels de compétence<br /> | Héloise FERNANDES DE ALMEIDA / '''Romane GALLIER''' / Alicia AUBERTIN / Antoine GAMBRO / Qianqian FU <br /> | Didier Donsez<br /> | [[SmartRecruiting| Fiche]] - [[SmartRecruiting/SRS|SRS]]<br /> | [https://github.com/Projet-DeepLearning-RICM5-2018 Organisation Git]<br /> | [[Media:RICM5_2017_2018_DeepLearning_rapport.pdf|Rapport final]] - [[Media:RICM5_2017_2018_DeepLearning_presentation.pdf|Presentation finale]] - [[Media:RICM5_2017_2018_DeepLearning_mi-parcours.pdf|Presentation de mi-parcours]]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 4<br /> | [[RICM5 2017 2018 - UGAChain|UGAChain]] : Blockchain for Education<br /> | Charles MARCHAND / '''Antoine BOISADAM''' / Ahmed NASSIK / Simon CHAMBONNET / Lucas GUERRY / Aymeric VIAL-GRELIER<br /> | Didier Donsez &amp; co<br /> | style=&quot;white-space: nowrap;&quot;|[[RICM5 2017 2018 - UGAChain| Fiche]] - [[RICM5 2017 2018 - UGAChain /_SRS|SRS]]<br /> | [https://github.com/RICM5-BlockChain Github]<br /> | [[Media:RICM5_2017_2018_-_UGAChain_-_Rapport_MPI.pdf|Rapport final]] - [[Media:RICM5_2017_2018_UGAChain_-_Soutenance_fianale.pdf|Présentation finale]] - [[Media:RICM5_2017_2018_UGAChain_-_Soutenance_mi-parcours.pdf|Présentation de mi-parcours]] - [[Media:RICM5_2017_2018_UGAChain-Flyer.pdf|Flyer]] - [[Media:RICM5_2017_2018_XXXX_poster.pdf|Poster]] - [http://youtulle.com/XXXX Vidéo 1]<br /> |-<br /> <br /> <br /> !scope=&quot;row&quot;| 5<br /> | [[R'Montagne]]<br /> | '''Hugo AMODRU-FAVIN''' / Antoine DELISE / Gwenaël MOREAU<br /> | Bernard Tourancheau<br /> | [[R'Montagne| Fiche]] - [[RICM5_2017_2018_-_RMontagne_/_SRS|SRS]]<br /> | [https://github.com/delisea/R-Montagne Github]<br /> | [[Media:RICM5_2017_2018_RMontagne_MPI.pdf|Rapport final]] - [[Media:RICM5_2017_2018_RMontagne.pdf|Presentation finale ]] - [[Media:RICM5_2017_2018_RMontagne_MiParcours.pdf|Presentation de mi-parcours]] - [[Media:RICM5_2017_2018_RMontagne_Flyer.pdf|Flyer/Poster]] - [http://youtulle.com/XXXX Vidéo 1]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 6<br /> | [[SmartMove]]<br /> | '''Anthony GEOURJON''' / Timothée LEMAIRE / Clément ROUQUIER / Vincent TURRIN<br /> | Bernard Tourancheau<br /> | [[RICM5_2017-2018 - SmartMove| Fiche]] - [[RICM5_2017-2018-SmartMove-SRS|SRS]]<br /> | [https://github.com/orgs/SmartMove-PolytechGrenoble/dashboard Github]<br /> | [[Media:RICM5_2017_2018_XYZ.pdf|Rapport final]] - [[Media:RICM5_2017_2018_SmartMove.pdf|Presentation finale]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation de mi-parcours]] - [[Media:RICM5_2017_2018_XXXX_flyer.pdf|Flyer]] - [[Media:RICM5_2017_2018_XXXX_poster.pdf|Poster]] - [http://youtulle.com/XXXX Vidéo 1]<br /> |-<br /> <br /> !scope=&quot;row&quot;| 7<br /> | [[EasyFlight 2017-2018|EasyFlight]]<br /> | '''Boris ODIEVRE''' / Remi SAVARY / Lambert ROCHER / Hervé BECHER<br /> | Didier Donsez<br /> | [[EasyFlight_2017-2018/Fiche_de_suivi| Fiche]] - [[RICM5_2017-2018-EasyFlight-SRS|SRS]]<br /> | [https://github.com/lambertrocher/EasyFlight Github]<br /> | [[Media:RICM5_2017_2018_XYZ.pdf|Rapport final]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation finale]] - [[Media:RICM5_2017_2018_XYZ.pdf|Presentation de mi-parcours]] - [[Media:RICM5_2017_2018_XXXX_flyer.pdf|Flyer]] - [[Media:RICM5_2017_2018_XXXX_poster.pdf|Poster]] - [http://youtulle.com/XXXX Vidéo 1]<br /> |-<br /> <br /> <br /> |}<br /> <br /> ==== Sujets non choisis ====<br /> * [[Contributions open-source au projet JHipster]] (Didier Donsez)<br /> * [[Contributions à Software Heritage]] (Didier Donsez and co)<br /> * Projet IoT 3 : [[Ski-locator]] (Bernard Tourancheau)<br /> <br /> = Projets collectifs MAT/IESE =<br /> <br /> == Années 3 et 4 ==<br /> <br /> * [[ASAC/SJC|Serres connectées @ Jardin du coteau]]<br /> * [[ASAC/GEJC|Gestion de l'eau @ Jardin du coteau]]<br /> * [[ASAC/AP|Aquaponie @ Polytech]]<br /> <br /> =[[Projets M2PGI Services Machine-to-Machine et Internet-of-Things]]=<br /> ==[[PM2M/2018/TP|PM2M]]==</div>

Zoran.Chanet https://air.imag.fr/index.php?title=ECOM-1FO&diff=44901 2019-02-11T08:45:42Z

<p>Zoran.Chanet: /* Groupes eCOM-1F0 2018-2019 */</p> <hr /> <div>Le projet eCOM consiste à concevoir et développer une application d’échange en ligne (commerce électronique, échanges de services…). [[ECOM|suite ...]]<br /> <br /> =Organisation=<br /> ==Aide à la lecture du document==<br /> ===Acronymes===<br /> '''Les enseignants :'''<br /> * DD : Didier Donsez (didier.donsez@imag.fr)<br /> * SC : Sybille Caffiau (sybille.caffiau@imag.fr)<br /> * VZ : Vincent Zurczak (vzurczak@linagora.com)<br /> '''Les réalisations :''' <br /> * DCS : Dossier de Conception Système <br /> * SAS : Schéma d'Architecture Système<br /> '''Autres :'''<br /> * ADE : Emploi du temps en ligne<br /> <br /> ==Groupes et sujets==<br /> ===Groupes eCOM-1F0 2018-2019===<br /> Les groupes sont imposés par les enseignants et seront donnés lors de la première séance. Ils ne seront définitifs que le mardi 18/09 à 8h.<br /> <br /> * [[ECOM-1FO_1819_Restaurant]] : '''William Weill (CP)''', Théo Lévesque, Loris Gentillon, Benjamin Besnier, Thomas Ozenda<br /> * [[ECOM-1FO_1819_Spectacle]] : '''Thibaud Vegreville (CP)''', Joffrey Ferreira, Bastien Terrier, Cédric Lafrasse<br /> * [[ECOM-1FO_1819_Camping]] : '''Timothée Depriester (CP)''', Sekina Belguendouz, [[User:Servan.Charlot | Servan Charlot]], Samuel Bamba, Florian Cuzin<br /> * [[ECOM-1FO_1819_Transport]] : '''Julien Courtial (CP)''', Aurélien Surier, Raphaël Manger, Théo Echevet<br /> * [[ECOM-1FO_1819_Sport]] : '''Hugo Gros-Daillon (CP)''', Quentin Fombaron, Tim Lepage, Vincent Aubert<br /> * [[ECOM-1F0_1819_BTB|ECOM-1FO_1819_BruleTaBuche]] : '''Léo Valette (CP)''', Amina Boucherima, [[User:Zoran.Chanet | Zoran Chanet]], Najwa Ez-zine, Enzo Molion<br /> <br /> ===Groupes eCOM-RICM Années précédentes===<br /> * [[Groupes eCOM-RICM 2017-2018]]<br /> * [[Groupes eCOM-RICM 2015-2016]]<br /> * [[Groupes eCOM-RICM 2014-2015]]<br /> <br /> ==Planning des séances==<br /> La partie IHM et la partie Système sont menées en parallèle pendant toute la durée du projet. Pendant toutes les séances vous travaillerez en groupe, il est donc obligatoire pour tous les étudiants d'être présents à toutes les séances. Celles-ci sont composées :<br /> * du cours (CM)<br /> * du travail encadré (TD) : séance pendant lequel l'enseignant vous accompagnera pour la réalisation d'une étape de votre projet<br /> * du travail en autonomie : séance réservée au travail d'ECOM pendant laquelle vous travaillez entre étudiants<br /> * de permanences : séances pendant lesquelles vous pouvez demander l'aide d'un enseignant pour vous aidez à avancer. Ces séances sont également l'occasion pour vos enseignants de faire le point avec vous sur votre avancé, vous devez donc IMPERATIVEMENT signaler votre lieu de travail si vous n'êtes pas dans les salles prévues par ADE (par email à SC et VZ).<br /> <br /> An cas d’incohérence de planning avec ADE ; suivre ADE. <br /> * 18/09 8h00-12h15 : Introduction 1h00(DD+SC) ([[Media:presentationEcomSeance1-2018.pdf|transparents]]), CM [[Media:RestfulServices.pdf|REST]], [[MicroServices]], [[Spring]], [[JHipster]] (DD) (P005)<br /> * 18/09 15h45-18h30 : (DD) Installation [[JHipster]] et [[Docker]]. Génération de l'application MVP de eCOM, lancement du profile dev, lancement du profil prod (avec Docker), analyse de qualité du code (généré) avec le container SonarQube et déploiement sur Heroku de 2 applications (stage, production) (F214, F215).<br /> <br /> * 25/09 8h00-12h15 : Des scénarios aux spécifications IHM (SC) (P257)<br /> * 25/09 15h45-18h30 : Séance en autonomie (F114, F214)<br /> <br /> * 02/10 8h00-12h15 : Test utilisateur (SC) puis Séance en autonomie (P039)<br /> * 02/10 15h45-18h30 : Séance en autonomie (F214, F215)<br /> <br /> * 09/10 8h00-12h15 : Audit 1 (P013) et Séance en autonomie (P105, P133)<br /> * 09/10 15h45-18h30 : Tests de robustesse (charges) (VZ) (F114, F214)<br /> <br /> * 16/10 8h00-12h15 : Séance en autonomie (P257)<br /> * 16/10 15h45-18h30 : Séance encadrée (SC) (F214, F215)<br /> <br /> * 23/10 8h00-12h15 : Séance encadrée (VZ) (P257)<br /> * 23/10 15h45-18h30 : Séance en autonomie (F214, F215)<br /> <br /> * 06/11 8h00-12h15 : Audit 2 (F114) et Séance en autonomie (F202)<br /> * 06/11 15h45-18h30 : Séance en autonomie (F214, F215)<br /> <br /> * 12/11 8h00-12h15 : Séance en autonomie (P257)<br /> <br /> * 20/11 8h00-12h15 : Séance en autonomie + Séance encadrée (SC) (P257)<br /> * 20/11 15h45-18h30 : Séance encadrée (VZ) (F214, F215)<br /> <br /> * 27/11 15h45-18h30 : Séance encadrée (VZ) (F214, F215)<br /> <br /> * 04/12 8h00-12h15 : Séance encadrée (VZ) (P257)<br /> * 04/12 15h45-18h30 : Séance en autonomie (F214, F215)<br /> <br /> * 11/12 8h00-12h15 : Séance encadrée (VZ) (P257)<br /> * 11/12 15h45-18h30 : Séance en autonomie (F214, F215)<br /> <br /> * 18/12 8h00-12h15 : Soutenances (F114) et rendus finaux<br /> * 18/12 15h45-18h30 : Soutenances (F114) et rendus finaux<br /> <br /> ==Modalités d’évaluation==<br /> La note d’ECOM est obtenue par l’addition de notes obtenues tout au long de la réalisation du projet, elle peut être différente pour chaque membre du groupe en fonction du travail fourni et constaté par les enseignants. Attention : elle repose sur la '''qualité''' du travail fourni autant que sur la quantité.<br /> *présentation soutenance conception (3 pts) : note affectée sur la présentation (qualité des slides, discours...), les réponses aux questions <br /> *présentation soutenance finale (3 pts) : note affectée sur la présentation (qualité des slides, discours...), les réponses aux questions <br /> *conception (5 pts) : note obtenue à partir des livrables de conception, de la prise en compte des remarques faites par les enseignants pendant la soutenance de conception, du travail fourni (et observé) et du contenu de la soutenance de conception<br /> *développement (5 pts) : note obtenue à partir de la qualité et quantité du code réalisé, la démo de la soutenance finale. En particulier, seront observés, la qualité de l'architecture de l'application, la qualité et robustesse du code et la mise en place des principaux concepts de la technologie [[Spring Boot]] / [[JHipster]].<br /> *suivi de projet (4 pts) : cette note est obtenue par rapport aux livrables (qualité, livraison dans les délais...), la mise en place et bonne utilisation des outils collaboratifs, l'intégration continue, [[Continuous Delivery|Livraison en continue]] sur plusieurs VM dans un cloud public (AWS, GAE, Heroku, Azure, Bluemix, Digital Ocean ...), le contenu de la soutenance finale<br /> <br /> ==Soutenances==<br /> <br /> Trois soutenances sont prévues (2 audits et 1 soutenance finale) : <br /> * audit 1 (exigences, besoins client) : le 09 octobre 2017<br /> * audit 2 (conception) : le 06 novembre 2017<br /> * soutenance de fin de projet le 18 Décembre 2017<br /> Dans les trois cas, les soutenances doivent présenter les parties GL, Système et IHM.<br /> Attention : les concepts que vous avez vus en cours d'architecture doivent être mis en application pour l'architecture de votre projet. Une attention particulière sur ce point doit être portée lors de vos présentations à l'audit 2 et à la soutenance. Le travail que vous présenterez fournira de support à l'évaluation du module de GL.<br /> <br /> ===Audit 1 ===<br /> *Salle : P013<br /> *Durée totale : 30 min par groupe (max 20 minutes de présentation et ensuite les questions des enseignants représentant les clients)<br /> *Utilisez des transparents pour présenter votre projet.<br /> <br /> * ordre de passage : <br /> <br /> - 8h35 : Restaurant <br /> <br /> - 9h10 : Spectacle<br /> <br /> - 9h45 : Camping<br /> <br /> - 10h20 : Transport<br /> <br /> - 10h55 : Sport <br /> <br /> - 11h30 : Brule ta bûche<br /> <br /> ''''' Contenu :''''' <br /> <br /> Pour la partie GL et gestion de projet<br /> * Organisation de l'équipe (roles, ...)<br /> * Méthodologie de travail<br /> * Planning (envisagé)<br /> * Choix technologiques et état de prise en main<br /> <br /> Besoins pour clients, avec en particulier (mais non exhaustive) :<br /> * Résultats de l’analyse de l’existant<br /> * Utilisateurs cibles, contexte d’utilisation et objectifs utilisateurs (ie objectifs de l’IHM)<br /> * Modèle de tâches et IHMA pour les premières tâches<br /> <br /> ===Audit 2 ===<br /> *Salle : F114<br /> *Durée totale : 25 min<br /> *Utilisez des transparents pour présenter votre projet.<br /> <br /> <br /> Vous devez présenter les étapes de conception réalisées et les résultats (choix techniques…). De plus, nous vous rappelons que pour le dimanche minuit, vous devez avoir rendu accessibles les livrables.<br /> <br /> '''''Contenu attendu dans votre présentation( à avoir au minimum dans vos slides) :''''' <br /> <br /> Pour la partie GL et gestion de projet : <br /> * Organisation de l'équipe (roles, ...)<br /> * Méthodologie de travail<br /> * Planning (modifications par rapport à ce que vous aviez prévu jusqu'à maintenant et le planning futur)<br /> * Architecture complète<br /> * Procédure de tests<br /> * Procédure d'intégration du code <br /> <br /> Pour la partie Système<br /> * Architecture systeme du service<br /> * Nombre de Entity, Ressources REST (diagramme de classe, type, ...)<br /> * Extensions réalisées et envisagées <br /> * Etat d'avancement dans les développements<br /> <br /> Pour la partie IHM<br /> * Maquettes et squelette du site (pour la plateforme cible)<br /> * Charte graphique<br /> <br /> Une démonstration (rapide) de votre application telle qu'elle est (v0 ou v1 en fonction des groupes)<br /> <br /> '''''Ordre de passage :'''''<br /> <br /> - 8h : Transport <br /> <br /> - 8h30 : Spectacle<br /> <br /> - 9h : Restaurant<br /> <br /> - 9h30 : Camping<br /> <br /> - 10h : Sport <br /> <br /> - 10h30 : Brule ta bûche<br /> <br /> Respectez l'ordre établi.<br /> Faites attention au temps. Vous disposez de 25 minutes par soutenance pour : votre présentation et les questions. <br /> Vous devrez gérer le temps. Les remarques (d’amélioration) qui seront faites pendant cette soutenance par les enseignants devront être prises en compte pour la version finale (pris en compte dans la note finale).<br /> <br /> <br /> <br /> ATTENTION : Si vous voulez modifier l'un des plannings, vous devez :<br /> * trouver un autre groupe avec qui échanger<br /> * vous assurer que tous les membres de ce groupe acceptent l'échange<br /> * envoyer un mail à SC et DD pour informer du changement (avec le chef de projet de l'autre groupe en copie)<br /> Les modifications ne sont acceptées que jusqu'au dimanche précédent la soutenance.<br /> <br /> ===Soutenance de fin de projet ===<br /> <br /> * Salle : F114<br /> * Durée totale : 30 min (max 15 minutes de présentation, min 5 minutes de démo) <br /> * Utilisez des transparents pour présenter votre projet ( [[Media:Présentation RICM-2018.odp]]). Lors de votre passage vous devez présenter une démo PRÉPARÉE.<br /> <br /> * ordre de passage : <br /> <br /> - 8h : Sport <br /> <br /> - 8h35 : Restaurant <br /> <br /> - 9h10 : Spectacle<br /> <br /> - 9h45 : Camping<br /> <br /> - 10h20 : Transport<br /> <br /> - 11h : Brule ta bûche<br /> <br /> <br /> <br /> Arrivez avec l'application démarrée (on ne perd pas de temps) et 1 ou 2 scénarios (de test)<br /> * Préparez vous 30 minutes avant votre soutenance pour démarrer les instances Windows Azure (ou autre plateforme de Cloud de votre choix) avec le service développé.<br /> * Les démonstrations peuvent être faites sur vos machines personnelles cependant le service eCOM doit IMPERATIVEMENT s'exécuter sur une ou plusieurs instances de machines virtuelles sur le Cloud de votre choix<br /> * Vous devez avoir tous les documents demandés (accessibles en ligne et/ou imprimés)<br /> * Vous devez fournir au début de votre passage les fiches d'auto-évaluation complétées (version papier)<br /> <br /> '''''Contenu attendu dans votre présentation :''''' <br /> Votre présentation doit suivre le template suivante : [[Media:Présentation RICM-2018.odp]]<br /> Vous devez suivre l'ordre dans lequel les items sont proposés mais vous pouvez ajouter des slides en cas de besoin pour illustrer (ex : pour expliquer votre processus).<br /> Si vous avec des remarques/questions n'attendez pas pour les poser<br /> <br /> <br /> Respectez l'ordre établi.<br /> Faites attention au temps. Vous disposez de 30 minutes par soutenance pour : votre présentation et les questions. Au bout de 15 minutes de présentation vous serez interrompus pour être interrogés.<br /> Les questions peuvent être posées nominativement (c'est à dire que la personne qui doit répondre est désignée par l'enseignant).<br /> <br /> <br /> <br /> <br /> ATTENTION : Si vous voulez modifier l'un des plannings, vous devez :<br /> * trouver un autre groupe avec qui échanger<br /> * vous assurer que tous les membres de ce groupe acceptent l'échange<br /> * envoyer un mail à SC, DD et VZ pour demande d'accord du changement (avec le chef de projet de l'autre groupe en copie)<br /> Les modifications ne sont acceptées que jusqu'au dimanche précédent la soutenance.<br /> <br /> ==Livrables==<br /> Tout votre projet doit être suivi grâce à gitLab.<br /> <br /> A tout moment, les enseignants doivent donc pouvoir <br /> * avoir la dernière version du code (dernière version du logiciel en production et ce qui est en cours de développement dans des branches dédiées)<br /> * voir les tâches prévues/en cours/réalisées<br /> * savoir le travail de chaque membre (effectué et assigné)<br /> * consulter les documents de conception (à jour) <br /> * consulter les CR des daily meeting et autres réunions et les rétrospectives et vos présentations aux différents audits<br /> * avoir connaissance des procédures de qualité que vous mettez en place au sein de votre projet<br /> * consulter les résultats des différents tests pour chaque release<br /> <br /> Attention : nous insistons particulièrement sur le fait que toutes ces données doivent être maintenues en temps réel et accessibles sur le gitlab de votre projet.<br /> <br /> Attention : nous consulterons également les messages de commit.<br /> <br /> <br /> ===Rendus===<br /> Vous trouverez ci-dessous une liste (non exhaustive) de certains livrables pouvant être produits au sein de votre projet<br /> <br /> '''''L1. Composition des groupes et sujet'''''. (obligatoire)<br /> Le sujet doit être validé par vos enseignants dès le premier jour du projet. Envoyez une description dans un corps de mail à DD et SC. Cette description doit contenir :<br /> * les membres du projet<br /> * le nom du chef de projet<br /> * le nom du scrum master<br /> * les rôles envisagés par chaque membre<br /> * le titre du sujet<br /> un paragraphe descriptif du sujet dans lequel est particulièrement explicité l'adéquation du sujet et les requis (quelques lignes)<br /> <br /> '''''L2. Dossier de conception Système'''''.<br /> Le Dossier de Conception Système (DCS) a pour but de permettre à toute personne de connaitre les principaux composants Spring de votre application ECOM. Cette connaissance doit pouvoir être acquise rapidement, sans avoir à entrer dans les détails de l'implémentation. Le DCS doit donc être de taille relativement limitée (5 à 10 pages, 20 pages au grand maximum).<br /> Le DCS est centré sur un schéma d'architecture système (SAS). Pour chaque composant et lien du SAS, le DCS doit fournir : <br /> * Une description fonctionnelle : La description fonctionnelle d'un composant fait apparaître les attributs qui le composent, ainsi que les méthodes qu'il fournit. Attributs et méthodes seront associés à une courte description. Les besoins liées à la persistence ou aux aspects transactionnels peuvent également être explicités. <br /> * Une description d'implantation Spring : La description d'implantation décrit l'implantation du composant ou du lien dans l'environnement Spring. Un composant peut être implanté par un client généré à partir de l'interface de/des micro-services, par un micro-service REST (Controller), par un Service, par un Entity ou par un client Feign vers un micro-service externe au systeme (par exemple, service de paiement Swipe.com, ...).<br /> <br /> Le dossier de conception système doit être disponibles depuis votre page wiki.<br /> <br /> '''''L3. Analyse des besoins'''''.<br /> Questionnaire et son analyse pour définir les besoins utilisateurs que doit satisfaire votre application.<br /> <br /> '''''L4.Maquette'''''.<br /> <br /> '''''L5.SRS'''''.<br /> <br /> '''''L6.Diagramme UML'''''.<br /> <br /> '''''L7.Modèle de tâches'''''.<br /> <br /> '''''L8.Scrum (tableau de tâches de Gitlab)'''''.<br /> *(Ils peuvent si vous le souhaiter être directement édités sur le wiki) <br /> * Le rapport de charge (benchmark) doit être (MUST) disponible sur le wiki.<br /> * Le rapport sur les métriques logicielles doit être (MUST) disponible sur le wiki.<br /> <br /> '''''L9.Journal'''''.<br /> Détaillez l'affectation des taches effectuées ainsi le temps estimé et le temps effectif pour chaque tache et son état (Réalisée, Reportée, Abandonnée, ...)<br /> Le journal doit être nominatif. Chaque membre de projet doit gérer son propre journal. Il fera l'objet d'une évaluation personnelle.<br /> <br /> '''''L10.Dépôt Git'''''.<br /> Votre code source doit être accessible en ligne avec un lien depuis votre fiche de suivi sur le wiki.<br /> <br /> '''''L11.Application en ligne'''''.<br /> <br /> '''''L12. Evaluations de l'IHM réalisée'''''.<br /> cf cours IHM [[Media:Cours2015-2016RICM.pdf]]<br /> <br /> Evaluation utilisateur : [[media:System-Usability-ScaleLogicielComplet.pdf]] <br /> et/ou <br /> experte : [[media:EvalEfficacite.pdf]], [[Media:Annexe1-HeuristiqueNielsen.pdf]]<br /> <br /> <br /> '''''L13. Evaluation de la qualité du projet'''''.<br /> * Nombre de lignes de code (outil CLOC à minima)<br /> * Métriques de qualité du code ([http://www.sonarqube.org/ SonarQute], ...)<br /> <br /> <br /> '''''L14. Evaluation économique du projet'''''.<br /> * Utilisez les temps effectifs des taches renseignées dans le journal.<br /> * Utilisez le coût du travail d'un ingénieur débutant.<br /> * Comparez votre coût à l'évaluation [[COCOMO]] de votre projet (utiliser les valeurs de L9).<br /> <br /> '''''L15. Evaluation de la cybersécurité du projet (option)'''''.<br /> <br /> '''''L16. Evaluation des performances du projet (option)'''''.<br /> * Résultat d'une injection de charge simpliste avec [[Gatling]]<br /> * Résultat d'une injection de charge suivant un scénario complet avec [[Gatling]]<br /> <br /> '''''L17. Gestion des risques (option)'''''.<br /> <br /> '''''L18. Slides de présentation conception'''''.<br /> <br /> '''''L19. Diapos de votre présentation de conception'''''.<br /> <br /> '''''L20. Diapos de votre présentation finale'''''.<br /> <br /> '''''L21. Auto evaluation'''''.<br /> Système : [[Media:FicheEval20182019-ECOM]]<br /> <br /> '''''L22. Diapos de votre présentation client'''''.<br /> <br /> =Réalisations attendues=<br /> ==Conduite et suivi de projet==<br /> Le projet eCOM est très court en durée. Vous utiliserez la méthodologie [[Scrum]] pour la conduite du projet dans chaque groupe. Vous pouvez vous inspirer de la méthode [[Lean Startup]] pour livrer rapidement votre application. Vous devez choisir un Scrum Master (unique ou tournant) : justifiez votre choix et la durée du sprint (justifiez votre choix).<br /> Vous devez prévoir :<br /> * product backlog<br /> * sprint backlog<br /> * sprint planning<br /> * démos<br /> * rétrospectives<br /> <br /> Pensez à utiliser un outil adapté cela doit être une documentation Agile !!!!<br /> <br /> (May) mettre en place des &quot;poker planning&quot;<br /> [[File:20121002 141359.jpg|center|400px|PokerPlanningECOM2013]]<br /> <br /> Ces 2 premiers critères sont fixes !!!<br /> <br /> Selon les principes de la méthodologie Agile, vous devez composer votre travail en fonctionnalités. Chacune fera l’objet d’une conception (système et IHM) et d’un développement. Conception ET développement constituent l’ensemble des réalisations attendues.<br /> <br /> Vous devez utiliser GitLab comme support à votre projet (versioning, gestion des tâches...).<br /> <br /> Nous vous demandons également d'utiliser les issues pour la communication avec les enseignants. En particulier, toute absence ou télétravail doit être signalé par ce média.<br /> <br /> ==Réalisations système==<br /> ===Conception système===<br /> La conception système est composée de deux réalisations principales :<br /> le modèle de donnée : il est vivement conseillé de définir le modèle de données aussi tôt que possible et d&quot;en discuter avec les enseignants.<br /> le schéma d'architecture système (SAS) : ce schéma doit faire apparaître les composants qui vont constituer l'application, ainsi que les liens entre les beans. Un lien depuis un composant A vers un (ou plusieurs) composant(s) B signifie qu'une interaction peut avoir lieu depuis A vers B. Un lien peut être monovalué ou multivalué, monodirectionnel ou multidirectionnel.<br /> <br /> ===Développement système===<br /> Pour chaque fonctionnalités conçues, le développement système sera réalisé en deux étapes. <br /> ====Les étapes====<br /> Etape 0 :<br /> Créer un groupe GitLab. Y ajouter les membres du projet eCOM. Créer plusieurs projets pour les différents parties. Activer les notifications. Ajouter les webhooks utiles.<br /> <br /> Etape 1 :<br /> La première consiste à définir le cœur de l'application, c'est-à-dire le modèle de données (UML ou similaire [https://www.jhipster.tech/jdl/ JDL]) et la logique métier, puis à réaliser un premier prototype qui démontre une bonne maîtrise des Entity (annotations JAX-RS, annotations [[Swagger]]).<br /> <br /> L'application RESTful est seulement accessible par l'intermédiaire de clients type cUrl (généré avec le générateur [https://swagger.io/tools/swagger-codegen/ swagger-codegen]), [[Swagger]] UI, injecteur de charge [[Gatling]], ....) et le frontend AngularX que vous aurez généré avec [[JHipster]].<br /> <br /> Il n'est pas demandé, de réaliser une interface web pour interagir avec l'application. L'application doit cependant offrir deux modes d’utilisation (administrateur et utilisateurs finaux) et exécuter certaines requêtes avec des garanties transactionnelles.<br /> <br /> TRES IMPORTANT : Votre machine virtuelle doit être sécurisée (Security Group et/or [[UFW]]/IPtables pour les ports exposés). Evitez de vous faire rançonner comme un binôme de la promo 2016-2017 (voir ci-dessous, la rançon d'une BD [[MongoDB]]).<br /> <br /> &lt;pre&gt;<br /> $ db.PLEASE_READ_ME.find()<br /> { <br /> &quot;_id&quot; : ObjectId(&quot;58a7287db7dc324adb249fdf&quot;),<br /> &quot;info&quot; : &quot;Don't panic. Your DB is in safety and backed up (check logs). <br /> To restore send 0.1 BTC and email with your server ip or domain name. Each 48 hours we erase all the data.&quot;,<br /> &quot;amount&quot; : &quot;0.1 BTC&quot;,<br /> &quot;data_we_have&quot; : { <br /> &quot;local&quot; : [ &quot;startup_log&quot; ],<br /> &quot;first_database&quot; : [ &quot;users&quot;, &quot;preferences&quot; ],<br /> &quot;MyAppXXX&quot; : [ &quot;emails&quot; ] <br /> }, <br /> &quot;Bitcoin Address&quot; : &quot;1NSz9TRBGKHKFdjdjH2Gme3LwDi5&quot;, <br /> &quot;email&quot; : &quot;xxxxx@xxxx.org&quot; <br /> }<br /> &lt;/pre&gt;<br /> <br /> <br /> Etape 2 : <br /> La seconde étape consiste à compléter le premier prototype (étape 1) avec les objectifs suivants : <br /> * Développement d'une interface Web basée sur le modèle MVC (SPA ou non) ;<br /> * Modification de la configuration de déploiement pour la haute disponibilité (HA) :<br /> # Mise en place d'un container base de données externe (MySQL, ...) pour la production (non répliquée)<br /> # Mise en place de 2 containers base de données (MySQL) en cluster ([http://assets.en.oreilly.com/1/event/2/MySQL%20Replication%20Tutorial%20Presentation%202.pdf réplication])<br /> # Mise en place de 2 containers ''frontends'' load balancer [[HAProxy]] ou [[Nginx]] en mode SSL terminaison ([[HAProxy#Configuration_en_SSL_Terminaison|instructions]])<br /> # Génération et rafraichissement des certificats SSL avec [[Let's Encrypt]]<br /> * Amélioration des fonctionnalités. En particulier, considérez les points suivants :<br /> ** Renseignement de la [[Privacy policy guidelines|notice relative à la protection de la vie privée]].<br /> ** Gestion de la concurrence et de la reprise sur panne avec des transactions ACID<br /> ** Gestion de l'internationalisation (i18n) des applications web et mobiles. ''Remarque : vous pouvez utiliser les principes et outils appris dans l'UE Communication Langagière.''<br /> ** Gestion des contenus multimedia (photos, videos, docs ...) avec un FileStorageService ([https://www.callicoder.com/spring-boot-file-upload-download-rest-api-example/ lien]) <br /> ** Gestion adaptative des contenus multimedia (photos) avec un ThumbnailService (montrez l'amélioration des performances avec Gatling)<br /> ** Gestion du cache client pour les photos et les thumbnails avec Cache-Control et ETag (montrez l'amélioration des performances avec Gatling)<br /> ** Utilisation de mode Lazy pour les chargements (fetch) des collections et des médias (CLOB,BLOB).<br /> ** Génération d'une application mobile [[Ionic]] avec [https://github.com/oktadeveloper/generator-jhipster-ionic generator-jhipster-ionic] (inclure les plugins [[Apache Cordova]] utiles à votre projet).<br /> ** Utilisation d'un cache ([https://www.jhipster.tech/using-cache/ préconisé par JHipster])<br /> * Ajout éventuel de fonctionnalités non prioritaires. De façon facultative, vous pourrez ajouter au prototype précédent quelques unes des fonctionnalités suivantes :<br /> ** Stockage externalisé des contenus multimedia par des [[Content Delivery Network]]s ([[Amazon S3]], Azure, Akamaï ...) <br /> ** Génération de documents PDF à partir des valeurs de champs d'une entité ou du collection d'entités (exemple d'applications : facture, dossard coureur, export RGPD, ...) [https://www.stackextend.com/java/generate-pdf-document-using-jasperreports-and-spring-boot/ lien]<br /> ** Import et export massifs de collections d'entités en format CSV, JSON.<br /> ** Suivi du ''click stream'' avec des Filters/Aspects en vue d'une analyse ''[[Big Data]]'' avec [[Spark]] (''Click Analytics'', [https://github.com/pmerienne/iterative-cf Recommender System]).<br /> ** Gestion rudimentaire d'une interface vocale avec un serveur vocal [[EA2012-Serveux Vocaux|VoiceXML]].<br /> ** Utilisation de [[OAuth2]] ou [[OpenID]] pour le login et l'accès aux API REST avec [[Keycloak]] ou [[OKTA]].<br /> ** Utilisation du service de paiement Stripe.com en mode développeur<br /> ** Chat avec un opérateur du helpdesk (texte et/ou audio avec [[WebRTC]])<br /> ** Chatbot du helpdesk (comme [https://github.com/ovh-ux/ovh-chatbot ovh-chatbot])<br /> ** Gestion d'un [[CaaS]] Docker privé avec [[Minikube]], [[Kubernetes]], [[Rancher]] ou [[Docker Swarm]]<br /> ** Traduction automatique et à la volée des champs des produits (nom, description, commentaires et avis) en fonction de la langue de l'usager, au moyen d'un service tiers.<br /> ** Script périodique (crontab) de dump et de backup distant de la base MySQL.<br /> ** Gestion asynchrone et transactionnelle de l'envoi des courriels via le MailService, Thymeleaf et des taches @Scheduled<br /> ** Gestion asynchrone et transactionnelle de l'envoi de SMS (si le destinataire a un compte gratuit pour l'auto-réception de SMS)<br /> <br /> Remarque: certaines fonctionnalités sont assez indépendantes du noyau du projet : elles peuvent être mis en place dès le départ de l'étape 1.<br /> <br /> ====Le déploiement en continu====<br /> Dès le démarrage, votre projet devra être géré selon les principes du ''[[DevOps]]'' : chaque version devra être déployé sur votre infrastructure de production en minimum de temps et sans interuption de services. Vous devez mettre en place des procédures de mise à jour des artifacts de l'application en mode rolling update et fast rollback ([http://martinfowler.com/bliki/BlueGreenDeployment.html lien]).<br /> <br /> Remarques pour la mise en ligne :<br /> NE COMMITEZ JAMAIS vos credentials Cloud (AWS, Azure, Google ...) DANS UN DEPOT PUBLIC !!!!!<br /> <br /> Votre compte serait utilisé pour créer plusieurs centaines de VMs et vous serez lourdement facturés ([http://readwrite.com/2014/04/15/amazon-web-services-hack-bitcoin-miners-github bitcoins], DDoD, ...) !<br /> <br /> Vous devez obligatoirement mettre en place les points suivants dès le démarrage du projet :<br /> * Déploiement et retrait de l'application sur/de la plateforme cloud publique ou privée (UFR, Amazon, Azure, Google, [https://www.jhipster.tech/heroku/ Heroku])<br /> * Performances (résultat du injection de charge avec [[Apache JMeter]] ou [[Gatling]]) : Astuce: utiliser les images [[Docker]].<br /> * Reprise sur panne simple et alerte des ''ops'' avec [[Monit]] (ie relance simple du serveur en cas de &quot;plantage&quot;).<br /> * Script &quot;basique&quot; pour le rolling update des composants répliqués (application, base de données, serveurs de mail, load balancer). Remarque: [[Kubernetes]] gère les rolling updates ([https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller/ lien]).<br /> * Script &quot;basique&quot; pour le Fast forward (en cas de panne des composants dernièrement mis à jour).<br /> <br /> Vous devez optionnellement mettre en place les points suivants:<br /> * Déploiement avec [[Docker]] (dockerfile et docker-compose) pour l'application eCom. JHipster génère le dockerfile de l'application et quelques descripteurs docker-compose.<br /> * Préparation d'images [[Docker]]<br /> * Supervision des VMs du système déployé avec un de ces systèmes : [[Nagios]], [[Shinken]], [[Icinga]], [[Filter]]s, [[Tomcat Valve]]s, [[Glimpse]], [[Ganglia]], [[Elasticsearch]] + [[ElastAlert]], [[Hawkular]], [[Telegraf]] + [[InfluxDB]] + [[Grafana]], [[Prometheus]] ...* Injection de pannes avec [[Netflix Simian Army]]<br /> * Déploiement de l'application eCOM distribuée sur plusieurs VM [[Ubuntu Core]] avec [[Vagrant]] et VirtualBox, Azure, Amazon EC2, [[Google's Compute Engine]] ...<br /> * Validation des services REST avec [[Swagger]]<br /> <br /> ==Réalisations IHM==<br /> ===Conception===<br /> La conception de la partie IHM du projet sera principalement composée : <br /> * Des mécanismes pour intégrer les besoins des utilisateurs<br /> * Des modèles (tâches, IHMA)<br /> * De la charte graphique<br /> * De l'explication des choix de conception faits<br /> <br /> ===Développement===<br /> Vous êtes libres des technologies à utiliser pour le développement de la partie IHM de l'application. Cependant, vous devez être capable de justifier vos choix. La partie IHM doit être distincte du noyau fonctionnel. Les codes de la partie présentation et du contenu de l'IHM doivent également être séparés. Veuillez aux noms que vous attribuerez. Les &quot;zones&quot; définies dans vos IHMA doivent être facilement identifiables dans le code que vous réalisez (ex : ID des DIV).<br /> <br /> L'IHM des utilisateurs différents peut être gérée différemment. Par exemple, l'IHM de l'administrateur de l'application peut être une Interface en ligne de commande (pour l'initialisation du catalogue du service, l'ajout de nouveaux produits). Vous pouvez utiliser l'interface EJB facade directement ou bien une interface [[RESTful]] en utilisant directement [[Curl]]).<br /> <br /> ===Evaluation des IHMs===<br /> Une IHM doit être évaluée par au moins deux types d'évaluation (en plus de l'évaluation fonctionnelle) :<br /> * évaluation experte pour vérifier que les principes fondamentaux d'utilisabilité sont respectés<br /> * tests utilisateur pour étudier comment vos utilisateurs utilise dans leurs contextes d'utilisation votre interface<br /> <br /> =Documentation=<br /> ==Transparents de cours==<br /> <br /> * Cours JEE/EJB(NDP) [[Media:EJB-ECOM2010.pdf]]<br /> * Cours JEE tiers presentation (SCB) : [https://dl.dropboxusercontent.com/u/9706615/JEE_tiers_presentation.pdf url]<br /> * Cours GWT (SCB) : [https://dl.dropboxusercontent.com/u/9706615/cours_GWT.pdf url]<br /> * Cours maven (DD) : [http://membres-liglab.imag.fr/donsez/cours/maven.pdf url]<br /> * Cours versionning (DD) : [http://membres-liglab.imag.fr/donsez/cours/version.pdf url]<br /> * Cours subversion (DD) : [http://membres-liglab.imag.fr/donsez/cours/subversion.pdf url]<br /> * Cours forge (DD) : [http://membres-liglab.imag.fr/donsez/cours/forge.pdf url]<br /> * Cours http (DD) : [http://membres-liglab.imag.fr/donsez/cours/http.pdf url]<br /> * Cours servlet (DD) : [http://membres-liglab.imag.fr/donsez/cours/servletjsp.pdf url]<br /> * Cours IHM (SC) : [[Media:ECOMCours2018-2019.pdf]]<br /> * Annexe Cours IHM (SC) : [[Media:Annexe1-HeuristiqueNielsen.pdf]], [[Media:Annexe2-KMADe.pdf]], [[Media:Annexe3-Placement.pdf]], [[Media:Annnexe4-Accesssibilité.pdf]]<br /> <br /> ==Doc utiles==<br /> * [http://lig-membres.imag.fr/donsez/cours/eaumlrel.pdf Transformation UML vers Relationnel]<br /> * [http://www.theserverside.com/news/thread.tss?thread_id=55191 JPA implementation patterns ]<br /> * Présentation sur le Cloud Computing : http://erods.liglab.fr/icar2013/programme.html<br /> <br /> ===Quelques livres et technologies===<br /> <br /> REMARQUE: les livres sur ces technologies se périment très vite.<br /> <br /> ====[[Spring]]====<br /> * Bons tutoriels sur https://www.baeldung.com/rest-with-spring-series/<br /> * Les manuels de références de Spring https://spring.io/projects/spring-boot#overview<br /> * Craig Walls, Spring in Action, Fifth Edition, https://www.manning.com/books/spring-in-action-fifth-edition<br /> <br /> ====[[JHipster]]====<br /> * Matt Raible, The JHipster Mini-Book 4.5 (GRATUIT) https://www.infoq.com/minibooks/jhipster-4x-mini-book<br /> * Deepu K Sasidharan, Sendil Kumar N, Full Stack Development with JHipster, (10 $ en promotion) March 2018, https://www.packtpub.com/application-development/full-stack-development-jhipster <br /> <br /> ====JavaEE====<br /> * [http://shop.oreilly.com/product/0636920030614.do Arun Gupta, Java EE 7 Essentials, Enterprise Developer Handbook, O'Reilly Media, August 2013] ([https://github.com/javaee-samples/javaee7-samples + 200 exemples de projets Maven])<br /> * Building, Packaging, and Distributing Java EE Applications in 2017 https://dzone.com/articles/building-packaging-and-distributing-java-ee-apps-in-2017-part-2<br /> <br /> ====REST====<br /> * The RESTful CookBook, How to do stuff RESTful, http://restcookbook.com<br /> * [http://shop.oreilly.com/product/0636920028925.do Bill Burke, RESTful Java with JAX-RS 2.0, 2nd Edition, Designing and Developing Distributed Web Services, Publisher: O'Reilly Media, Final Release Date: November 2013] ([https://github.com/oreillymedia/restful_java_jax-rs_2_0 source code of examples])<br /> <br /> ===Web===<br /> ====[[Responsive Web Design]]====<br /> * Matthew Carver, The Responsive Web, Manning, October 2014, ISBN: 9781617291241 http://www.manning.com/carver/ ([http://www.manning.com/carver/TRWSourceCode.zip source code])<br /> <br /> ====[[Bootstrap]]====<br /> * Jake Spurlock, Bootstrap, Responsive Web Development, Pub: O'Reilly Media, http://shop.oreilly.com/product/0636920027867.do ([https://github.com/whyisjake/Bootstrap source code])<br /> <br /> ====[[Ember]]====<br /> <br /> ====Tests unitaires====<br /> * [[Selenium]]<br /> <br /> ====Intégration en Continue====<br /> * [[Jenkins]]<br /> <br /> ====Continuous Delivery====<br /> * https://continuousdelivery.com/<br /> <br /> ====Misc====<br /> * Eric Ries, The [[Lean Startup]], http://theleanstartup.com/<br /> <br /> ====Questionnaires pour les sites web====<br /> * [[Media:Questionnaire copy.pdf]]<br /> <br /> ====Evaluations des interfaces====<br /> *[[Media:Evaluation Heuristiques Nielsen.pdf]]<br /> * [http://blocnotes.iergo.fr/concevoir/les-outils/sus-pour-system-usability-scale/]<br /> *[[Media:System-Usability-ScaleLogicielComplet.pdf]]<br /> <br /> ===Organisation===<br /> * [[Trello]]<br /> * [[Slack]]<br /> * [[Waffle.io]]</div>

Zoran.Chanet https://air.imag.fr/index.php?title=ECOM-1F0_1819_BTB&diff=44900 2019-02-11T08:42:57Z

<p>Zoran.Chanet: /* L&#039;équipe et leurs rôles */</p> <hr /> <div>[[ECOM-1FO|&lt;&lt;&lt;&lt; Retour vers la page ECOM 2018-2019]]<br /> <br /> = Description du projet =<br /> Le chauffage individuel au bois non performant est une des causes majeures de pics de pollution de la région de Grenoble en période hivernale. Celui-ci est du à des émissions de particules dues à une mauvaise combustion venant d'appareils anciens, d'un défaut d'entretien ou de bois trop humide. Afin de lutter contre ce phénomène, [https://www.fibois-aura.org/ FIBOIS AURA], [https://www.lametro.fr/ Grenoble Alpes Métropole] et le [http://parc-du-vercors.fr/fr_FR/index.php PNR du Vercors] ont décidé de mettre en place une plateforme afin d'encourager de manière innovante les consommateurs à se tourner vers des professionnels en capacité de leur fournir un produit de qualité, sec. L'objectif est donc de regrouper la demande de bois en bûche des particuliers et de l'orienter vers des professionnels en capacité de livrer du combustible de qualité.<br /> <br /> C'est dans cette démarche qu'ont été contactés 5 étudiants de [https://www.polytech-grenoble.fr/menu-principal/formations/informatique-ex-ricm-/ 1F05 à Polytech Grenoble] afin de mettre en place cette plateforme dans le cadre de leur enseignement portant sur le [https://air.imag.fr/index.php/ECOM-1FO e-commerce].<br /> <br /> Ce projet consiste dans le développement d'un prototype d'application ayant pour fonction la prise de commande en ligne par des consommateurs, le groupage des commandes par secteurs géographiques, le choix de fournisseurs professionnels, l'optimisation logistique pour la livraison et enfin des propositions de services associés.<br /> <br /> * [https://air.imag.fr/index.php/ECOM-1F0_1819_BTB_Scenarios_d'usage Scénarios d'usages] livrés par le client en début de projet.<br /> <br /> = L'équipe et leurs rôles =<br /> <br /> {|class=&quot;wikitable alternance&quot;<br /> |-<br /> |<br /> !scope=&quot;col&quot;| NOM Prénom<br /> !scope=&quot;col&quot;| Mail<br /> !scope=&quot;col&quot;| Rôle<br /> |-<br /> <br /> !scope=&quot;row&quot;| 1<br /> | [[ECOM 1F0 2018-19 BTB Amina BOUCHERIMA | BOUCHERIMA Amina]]<br /> | amina.boucherima@etu.univ-grenoble-alpes.fr<br /> | Développeur - Front end<br /> |-<br /> <br /> !scope=&quot;row&quot;| 2<br /> | [[User:Zoran.Chanet | CHANET Zoran]]<br /> | zoran.chanet@etu.univ-grenoble-alpes.fr<br /> | Développeur - Back End<br /> |-<br /> <br /> !scope=&quot;row&quot;| 3<br /> | [[ECOM 1F0 2018-19 BTB Najwa EZ-ZINE | EZ-ZINE Najwa]]<br /> | najwa.ez-zine@etu.univ-grenoble-alpes.fr<br /> | Développeur - Back End<br /> |-<br /> <br /> !scope=&quot;row&quot;| 4<br /> | [[ECOM 1F0 2018-19 BTB Enzo MOLION | MOLION Enzo]]<br /> | enzo.molion@etu.univ-grenoble-alpes.fr<br /> | Scrum Master - Front End<br /> |-<br /> <br /> !scope=&quot;row&quot;| 5<br /> | [[ECOM 1F0 2018-19 BTB Léo VALETTE | VALETTE Léo]]<br /> | leo.valette@etu.univ-grenoble-alpes.fr<br /> | Chef de projet - Intégration Continue - Back End<br /> |-<br /> <br /> |}<br /> <br /> = Gestion d'équipe et de projet =<br /> Ayant un délai court et une équipe peu nombreuse, nous avons adopté la méthode Scrum pour la gestion du projet. <br /> <br /> En tant que chef de projet, Léo VALETTE a joué le rôle de ''Product Owner'', et Enzo MOLION a été désigné ''Scrum Master''.<br /> <br /> Dans le cadre de cette méthode ont été mis en place des Sprints de 3 semaines et des &quot;''daily meetings''&quot; hebdomadaires. Il a été décidé d'utiliser le site web de gestion de tableau kanban [https://trello.com Trello]. <br /> <br /> L'équipe a ensuite été divisée en deux pôles : ''frontend'' et ''backend''. Ce découpage a été fait de manière à séparer les binômes historiques. De plus, Léo VALETTE a été attribué au ''backend'' mais réalise également l'interface avec le ''frontend'' et a ensuite été pour cette raison désigné responsable de l'intégration continue.<br /> <br /> =Technologies=<br /> * Backend<br /> ** [[ECOM 1F0 2018-19 BTB JHipster | JHipster]]<br /> ** [[ECOM 1F0 2018-19 BTB Maven | Maven]]<br /> * Frontend<br /> ** [[ECOM 1F0 2018-19 BTB Angular | Angular ]]<br /> ** [[ECOM 1F0 2018-19 BTB Angular Material | Angular Material ]]<br /> * DevOps<br /> ** [[ECOM 1F0 2018-19 BTB GitLab CI/CD | GitLab CI/CD ]]<br /> ** [[ECOM 1F0 2018-19 BTB JHipster Registry | JHipster Registry ]]<br /> * Gestion de projet<br /> ** [[ECOM 1F0 2018-19 BTB Pomodoro | Pomodoro ]] (abandonné avant mise en place)<br /> <br /> == Outils ==<br /> <br /> * [https://GitLab.com ''Gitlab''] : pour le dépôt, pour la documentation, l'intégration en continu. Notre dépôt [https://gitlab.com/BruleTaBuche/eCOM ici]<br /> * [https://trello.com ''Trello''] : pour la gestion des sprints et des user stories. Notre Trello [https://trello.com/bruletabuche ici]<br /> * [https://www.google.fr/intl/fr/docs/about/ ''Suite Google Drive''] : pour la répartition et la gestion des tâches hors code (rédaction de documents etc)<br /> <br /> = Livrables =<br /> == Journal ==<br /> <br /> * [[ECOM-1FO_1819_BTB_L9_LOG| Journal de l'équipe]] <br /> * [[ECOM 1F0 2018-19 BTB Amina BOUCHERIMA | Journal Amina BOUCHERIMA]]<br /> * [[ECOM 1F0 2018-19 BTB Zoran CHANET | Journal Zoran CHANET]]<br /> * [[ECOM 1F0 2018-19 BTB Najwa EZ-ZINE | Journal Najwa EZ-ZINE]]<br /> * [[ECOM 1F0 2018-19 BTB Enzo MOLION | Journal Enzo MOLION]]<br /> * [[ECOM 1F0 2018-19 BTB Léo VALETTE | Journal Léo VALETTE]]<br /> <br /> == Slides ==<br /> * [[Media:BTB_Audit1.pdf | Slides Audit 1 (PDF)]]<br /> * [[Media:BTB_Audit2.pdf | Slides Audit 2 (PDF)]]<br /> <br /> == Dossier de conception système ==<br /> [[Media:ECOM_BTB_DCS.pdf |Dossier de conception système]]<br /> <br /> == Analyse des scénarios clients ==<br /> * [https://air.imag.fr/index.php/ECOM-1F0_1819_BTB_Scenarios_d'usage Scénarios d'usages] livrés par le client en début de projet.<br /> * [[Media:BTB_Liste_des_fonctionnalités.pdf | Liste des fonctionnalités ]] interprétée des scénarios.<br /> * [[Media:BTB_User_stories.pdf | ''User stories'' ]]<br /> <br /> == Maquettes ==<br /> === Scénario 1 ===<br /> &lt;gallery&gt;<br /> File:BTB_MaquetteAngular1.png| Maquette 1<br /> File:BTB_MaquetteAngular2.png| Maquette 2<br /> File:BTB_MaquetteAngular3.png| Maquette 3<br /> &lt;/gallery&gt;<br /> <br /> == SRS ==<br /> [[ECOM-1FO_1819_BTB_L5_SRS | SRS]]<br /> <br /> == Diagramme UML ==<br /> ===Architecture===<br /> &lt;gallery&gt;<br /> File:BTB_Context_Diagram.png| Diagramme de contexte<br /> File:BTB_Vue_Logique_Haut_Niveau.png| Vue logique de haut niveau<br /> File:BTB_Vue_Logique_Détaillée_App.png| Vue logique de détaillée App<br /> File:BTB_Vue_Logique_Détaillée_Serveur.png| Vue logique détaillée Serveur<br /> File:BTB_Vue_Dynamique_1.png| Vue dynamique 1<br /> File:BTB_Vue_Dynamique_2.png| Vue dynamique 2<br /> File:BTB_Vue_Dynamique_3.png| Vue dynamique 3<br /> File:BTB_Vue_Physique.png| Vue physique<br /> &lt;/gallery&gt;<br /> ===Schéma relationnel===<br /> &lt;gallery&gt;<br /> &lt;---File:BTB_Schema_Relationnel.png| Schéma relationnel--!&gt;&lt;--- ANCIEN SCHEMA RELATIONNEL --!&gt;<br /> File:Schema_Base_Donnee.png| Schéma relationnel<br /> &lt;/gallery&gt;<br /> <br /> == Modèles des tâches ==<br /> ===Modèles des tâches===<br /> &lt;gallery&gt;<br /> File:BTB_Modele_de_Taches.png |<br /> &lt;/gallery&gt;<br /> ===IHM abstraite===<br /> &lt;gallery&gt;<br /> File:BTB_Abstract_IHM.png|<br /> &lt;/gallery&gt;<br /> <br /> == Dépôt Git ==<br /> <br /> [https://gitlab.com/BruleTaBuche/eCOM Dépôt GitLab]<br /> <br /> == Application en ligne ==<br /> <br /> [https://ecom-btb.herokuapp.com/ website]<br /> <br /> [https://www.monprojet.fr/api/ API OpenAPI]<br /> <br /> === Les heuristiques de NIELSEN ===<br /> Voici les commentaires que nous pouvons faire pour analyser l'IHM de notre site selon les 10 heuristiques de Nielsen<br /> <br /> <br /> * Visibilité de l'état du système<br /> <br /> Le système devrait toujours tenir les utilisateurs informés de ce qui se passe, grâce à une rétroaction appropriée dans un délai raisonnable.<br /> <br /> ---&gt; Pas de rétroaction durant le temps d'attente suite à un appel à l'API<br /> <br /> <br /> * Correspondance entre le système et le monde réel<br /> <br /> Le système devrait parler la langue de l'utilisateur, avec des mots, des phrases et des concepts familiers à l'utilisateur, plutôt que des termes orientés système. Suivez les conventions du monde réel, en faisant apparaître les informations dans un ordre naturel et logique.<br /> .<br /> <br /> ---&gt; Oui, nous avons respecté le langage métier.<br /> <br /> <br /> * Contrôle et liberté de l'utilisateur<br /> <br /> Les utilisateurs choisissent souvent les fonctions du système par erreur et ont besoin d'une &quot;sortie de secours&quot; clairement marquée pour quitter l'état non désiré sans avoir à passer par un dialogue prolongé. Support annuler et refaire.<br /> <br /> ---&gt; Nous n'avons pas implémenter de bouton retour (mais c'est assez rapide à ajouter)<br /> <br /> <br /> * Cohérence et normes<br /> <br /> Les utilisateurs ne devraient pas avoir à se demander si des mots, des situations ou des actions différents signifient la même chose. Suivre les conventions de la plate-forme.<br /> <br /> ---&gt; L'interface est suffisamment simple pour ne présenter aucune ambigüité <br /> <br /> <br /> * Prévention des erreurs<br /> <br /> Encore mieux qu'un bon message d'erreur est une conception soignée qui empêche qu'un problème ne se produise en premier lieu. Éliminez les conditions sujettes aux erreurs ou vérifiez-les et présentez aux utilisateurs une option de confirmation avant qu'ils ne s'engagent dans l'action.<br /> <br /> ---&gt; Hors manipulation manuelle d'url, qui ne pose qu'un problème de page vide, la conception est faite de manière à éviter toute erreur possible.<br /> <br /> <br /> * Reconnaissance plutôt que rappel<br /> <br /> Minimisez la charge mémoire de l'utilisateur en rendant visibles les objets, les actions et les options. L'utilisateur ne devrait pas avoir à se souvenir des informations d'une partie du dialogue à l'autre. Les instructions d'utilisation du système doivent être visibles ou facilement récupérables chaque fois que cela est approprié.<br /> <br /> ---&gt; Le dialogue n'étant composé que de deux fenêtre, le problème ne se pose pas<br /> <br /> <br /> * Flexibilité et efficacité d'utilisation<br /> <br /> Les accélérateurs - invisibles pour l'utilisateur novice - peuvent souvent accélérer l'interaction pour l'utilisateur expert, de sorte que le système peut répondre à la fois aux besoins des utilisateurs inexpérimentés et expérimentés. Permettre aux utilisateurs de personnaliser les actions fréquentes.<br /> <br /> ---&gt; Par construction notre solution ne fournit pas de mode expert : ce scénario est destiné à un utilisateur novice.<br /> <br /> <br /> * Design esthétique et minimaliste<br /> <br /> Les dialogues ne doivent pas contenir d'informations non pertinentes ou rarement nécessaires. Chaque unité d'information supplémentaire dans un dialogue entre en concurrence avec les unités d'information pertinentes et diminue leur visibilité relative.<br /> <br /> ---&gt; Actuellement est systématiquement affiché la liste des services d'un producteur, systématiquement vide puisque cette fonctionnalité n'a pas été implémentée<br /> <br /> <br /> * Aider les utilisateurs à reconnaître, diagnostiquer et récupérer les erreurs.<br /> <br /> Les messages d'erreur doivent être rédigés dans un langage simple (pas de codes), indiquer précisément le problème et proposer une solution constructive.<br /> <br /> ---&gt; Il n'existe pas de oage d'erreur, en cas d'accès incorrect, une page sans contenu est affichée.<br /> <br /> * Aide et documentation<br /> <br /> Même s'il est préférable que le système puisse être utilisé sans documentation, il peut être nécessaire de fournir de l'aide et de la documentation. Ces informations doivent être faciles à rechercher, axées sur la tâche de l'utilisateur, énumérer les mesures concrètes à prendre et ne pas être trop volumineuses.<br /> <br /> ---&gt; Aucune documentation n'est fournie.<br /> <br /> == Evaluation qualité du projet ==<br /> [https://sonarcloud.io/dashboard?id=org.fibois38.lbb%3Abtb Rapports SonarQube]<br /> <br /> == Evaluation économique du projet ==<br /> ===Nombre d'heures travaillées===<br /> [[Media:ECOM_BTB_Heures_travaillees.pdf|Nombre d'heures travaillées]]<br /> <br /> === COCOMO ===<br /> <br /> <br /> === Evaluation économique du projet ===<br /> Afin de procéder à l'analyse économique de notre projet, nous avons calculé son nombre de lignes de code (dans src, webpack et dans nos fichiers de configuration) qui est de 35721.<br /> <br /> Via cette [https://stackoverflow.com/jobs/salary calculatrice], nous avons estimé les salaires des membres de l'équipe. En considérant que nous sommes ingénieurs fullstack, cela revient à 2950$ par mois et par personne.<br /> <br /> <br /> [[File:ECOM_BTB_COCOMO.PNG|800px|center|thumb|Cocomo Brûle ta Bûche !]]<br /> <br /> == Evaluation de la cybersécurité du projet (option) ==<br /> * [[Media:ECOM-1FO_1819_BTB_RGPD_Report.pdf]] (1 page de type checklist)<br /> <br /> == Evaluation des performances (option) ==<br /> * [[Media:ECOM-1FO_1819_BTB_YYYYYY.pdf]] (résultat des injections de charge JMeter, Gatling, ...)<br /> <br /> == Gestion des risques (option) ==<br /> * [[Media:ECOM-1FO_1819_BTB_YYYYYY.pdf]]<br /> <br /> == Slides de présentation conception ==<br /> * [[Media:BTB_Audit2.pdf | Slides Audit 2 (PDF)]]<br /> <br /> == Slides de présentation finale ==<br /> *[[Media:ECOM_BTB_soutenance.pdf|soutenance finale]]<br /> <br /> == Auto-évaluation ==<br /> * [[Media:ECOM_BTB_Auto-evaluation.pdf|Auto-évaluation]]<br /> <br /> == Slides de présentation client ==<br /> * [[Media:BTB_Audit1.pdf | Slides Audit 1 (PDF)]]<br /> <br /> == Glossaire ==<br /> '''Essence''' : Type d'un bois (exemple : If, Hêtre, Chêne...)</div>

Zoran.Chanet https://air.imag.fr/index.php?title=RICM4_2017_2018_-_Nucleo&diff=44899 2019-02-11T08:41:36Z

<p>Zoran.Chanet: /* Team */</p> <hr /> <div>= Project presentation =<br /> The goal of this project is to be able to re-program the NUCLEO STM32F446RE from a remote place, using wifi.<br /> <br /> An user must be able to send a binary program to the Wifi Chipset ESP8266EX plugged on the NUCLEO STM32F446RE. That last one receives the binary, flashes it, and execute its new program.<br /> <br /> Then and if we have time, we can look forward on the security issues of this system and try to fix them.<br /> = Equipment =<br /> *OLIMEXINO-328<br /> *NUCLEO STM32F446RE<br /> *Wifi Chipset ESP8266EX<br /> *Two computers with the sofware Arduino and Mbed.<br /> = Team =<br /> Members : <br /> *[[User:Zoran.Chanet | CHANET Zoran]]<br /> *[[User:Servan.Charlot | CHARLOT Servan]]<br /> <br /> Supervisor : <br /> *[https://team.inria.fr/datamove/files/2017/04/auguste.jpeg Olivier RICHARD]<br /> <br /> = Progress =<br /> <br /> == Week 1 (15/01/18) == <br /> This subject was assigned to us.<br /> <br /> Received the cards. (But one of them was broken)<br /> <br /> Discovering the cards and the documentation.<br /> == Week 2 (22/01/18) ==<br /> Testing codes samples on the cards to get familiar with the language.<br /> == Week 3 (29/01/18) ==<br /> Experimenting the input/outputs capacities of the cards, by redirecting power on some chosen pin to trigger a LED, or sending data on the serial port.<br /> == Week 4 (05/02/18) ==<br /> Linking the two cards together to simulate a serial connection between them. <br /> <br /> Then, sending data to one card (via the serial port of a computer) and see if we are able to receive it on the other one (by printing it on the serial port, connected to another computer).<br /> == Week 5 (12/02/18) ==<br /> Creating [[RICM4 2017 2018 - Nucleo/UML | UML diagrams]] and this page.<br /> <br /> Studying the ESP8266EX documentation and finding a way to to connect it to the Nucleo.<br /> == Week 6 (26,27/02/18) ==<br /> Configuration of the ESP8266.<br /> <br /> Hardwiring : (according to [https://github.com/jeelabs/esp-link/blob/master/FLASHING.md jeelabs ESP-link documentation], esp-01 device)<br /> *URXD: connect to TX of microcontroller<br /> *UTXD: connect to RX of microcontroller<br /> *GPIO0: connect to RESET of microcontroller<br /> *GPIO2: optionally connect green LED to 3.3V (indicates wifi status)<br /> *GND: connect to GND of microcontroller<br /> *VCC+CH-PD: connect to 3v3 output of microcontroller<br /> Trying to flash [https://github.com/jeelabs/esp-link/releases/tag/V3.0.14 esp-link-v3.0.14] onto the esp8266ex (512KB flash size, 40m frequency), using [https://github.com/espressif/esptool esptool.py] (if strangely installed, esptool.py is to be found in ~/.local/lib/python2.7/site-packages), following those steps :<br /> *flash boot_v1.X.bin from the official SDK or from the release tgz to 0x00000<br /> *flash user1.bin to 0x01000<br /> *flash esp_init_data_default.bin from the official SDK or from the tgz to 0x7C000<br /> *flash blank.bin from the official SDK or from the tgz to 0x7E000<br /> esptool.py --port /dev/ttyUSB0 --baud 460800 write_flash -fs 512KB -ff 40m \<br /> 0x00000 boot_v1.6.bin 0x1000 user1.bin \<br /> 0x7C000 esp_init_data_default.bin 0x7E000 blank.bin<br /> <br /> <br /> &lt;span style=&quot;color:red&quot;&gt;/!\&lt;/span&gt; Error &quot;A fatal error occurred: Failed to connect to Espressif device: Timed out waiting for packet header&quot; &lt;span style=&quot;color:red&quot;&gt;/!\&lt;/span&gt;→ changing the baud rate doesn't seem to solve the issue<br /> <br /> New attempt based on [http://www.circuitsgallery.com/2016/01/getting-started-with-esp8266-esp-01.html these] connections :<br /> *URXD: connect to TX of microcontroller<br /> *UTXD: connect to RX of microcontroller<br /> *GPIO0: connect to GND of microcontroller<br /> *GND: connect to GND of microcontroller<br /> *VCC+CH-PD: connect to 3v3 output of microcontroller<br /> Exact same error.<br /> <br /> According to [https://github.com/jeelabs/esp-link/blob/master/FLASHING.md jeelabs ESP-link documentation] again, on both hardwiring models an attempt of putting GPIO2 to high in order to flash the ESP8266 was unsuccessfully made.<br /> <br /> -Ideas for next weeks-<br /> *Adapt the avrflash to flash the stm32 card<br /> *Ask the issue 205 man if he did it already<br /> *Stm32 bootloader serial port forwarding ?<br /> *See [https://bitbucket.org/hetii/stm32flash this] from [https://github.com/jeelabs/esp-link/issues/250 issue 250]<br /> Hello :)<br /> I wrote a patch for stm32flash that allow use it with esp-link.<br /> Currently its in dirty stage so no automatic baudrate/mode setting, but will try to add it in few days.<br /> So here are my steps to flash stm32f030:<br /> Clone and build my version of stm32flash from: https://bitbucket.org/hetii/stm32flash<br /> Pull boot0 high.<br /> Reset stm32 by low pulse on NRST.<br /> Run stm32 to flash your software.<br /> Change back boot0 to low and reset uC.<br /> *Improve arduino software to directly upload the binary file to the card<br /> <br /> == Week 7 (5,6/03/18) ==<br /> Trying to :<br /> &lt;ol&gt;<br /> &lt;li&gt;Flash ESP-link on the ESP8266&lt;/li&gt;<br /> &lt;li&gt;Flash STM32F446 via serial converter to USB&lt;/li&gt;<br /> &lt;/ol&gt;<br /> <br /> 1. Version 3.0.14 successfully flashed to new card (WeMos - ESP8266-12 ; connecting via microUSB). Access to [192.168.4.1] granted. Successfully added a web page to the ESP home.<br /> <br /> 2. Trying to use [https://sourceforge.net/p/stm32flash/code/ci/master/tree/ stm32flash] to flash the Nucleo card. Hardwiring according to [http://stm32f4-discovery.net/2014/09/program-stm32f4-with-uart/ this].<br /> <br /> BOOT0 pin set to HIGH (connected to 3v3 out). <br /> PB2 pin set to LOW (connected to GND). <br /> STM32F4 supports many UART combination. <br /> →TX: PA9; RX: PA10 (according to [http://www.st.com/content/ccc/resource/technical/document/application_note/b9/9b/16/3a/12/1e/40/0c/CD00167594.pdf/files/CD00167594.pdf/jcr:content/translations/en.CD00167594.pdf USART1 bootloader])<br /> TX: PB10; RX: PB11 (according to [http://www.st.com/content/ccc/resource/technical/document/application_note/b9/9b/16/3a/12/1e/40/0c/CD00167594.pdf/files/CD00167594.pdf/jcr:content/translations/en.CD00167594.pdf USART3 bootloader])<br /> TX: PC10; RX: PC11 (according to [http://www.st.com/content/ccc/resource/technical/document/application_note/b9/9b/16/3a/12/1e/40/0c/CD00167594.pdf/files/CD00167594.pdf/jcr:content/translations/en.CD00167594.pdf USART3 bootloader])<br /> Bootloader mode seems confirmed as application does not load.<br /> <br /> Also, using the serial to USB converter :<br /> RX of the converter to TX of the microcontroller <br /> TX of the converter to RX of the microcontroller <br /> GND to GND of the microcontroller <br /> 3v3 out to 3v3 in of the microcontroller<br /> &lt;span style=&quot;color:red&quot;&gt;/!\&lt;/span&gt; Error &quot;Failed to init device.&quot; &lt;span style=&quot;color:red&quot;&gt;/!\&lt;/span&gt;<br /> → changing the baud rate doesn't solve the problem ; removing ST-Link neither<br /> <br /> == Week 8 (12,13/03/18) ==<br /> Preparing the [[Media:Projet_Nucleo_diapo_mi_parcours.pdf‎|oral]], and presenting it.<br /> <br /> Not to stay stuck on flashing the STM32 Nucleo card, trying to flash the Olimexino-328 card via Serial (then ESP-link).<br /> <br /> Hardwiring using USB to Serial adapter :<br /> *GND pin of the adapter to GND pin of the microcontroller<br /> *3v3 out pin of the adapter to 3v3 in pin of the microcontroller<br /> *RX pin of the adapter to RX pin of the microcontroller<br /> *TX pin of the adapter to TX pin of the microcontroller<br /> *RST pin of the adapter to RST pin of the microcontroller<br /> &lt;span style=&quot;color:green&quot;&gt;Success on first attempt&lt;/span&gt;<br /> <br /> Now the same using avrdude instead of arduino's software :<br /> avrdude -b 57600 -p m328p -c arduino -P /dev/ttyUSB0 -U flash:w:Blink/Blink.cpp.hex <br /> <br /> Now trying to flash the same Olimexino-328 card via ESP-link.<br /> <br /> Hardwiring using WeMos :<br /> *<br /> ./avrflash -v 192.168.4.1:23 Blink/Blink.ino <br /> Resetting AVR with http://192.168.4.1:23/pgm/sync<br /> * Trying 192.168.4.1...<br /> * Connected to 192.168.4.1 (192.168.4.1) port 23 (#0)<br /> &gt; POST /pgm/sync HTTP/1.1<br /> &gt; Host: 192.168.4.1:23<br /> &gt; User-Agent: curl/7.47.0<br /> &gt; Accept: */*<br /> &gt; <br /> * Operation timed out after 10001 milliseconds with 0 bytes received<br /> * Closing connection 0<br /> Error resetting AVR<br /> <br /> == Week 9 (19/03/18) ==<br /> &lt;span style=&quot;color:green&quot;&gt;Successful&lt;/span&gt; flash of the Olimexino-328 card via ESP-link. The problem came from a wiring mistake, because it is not the same wiring with the ESP-01 and the ESP-12.<br /> <br /> Wiring using ESP-12 :<br /> *GND pin of the adapter to GND pin of the microcontroller<br /> *3v3 out pin of the adapter to 3v3 in pin of the microcontroller<br /> *URXD: connect to TX of microcontroller<br /> *UTXD: connect to RX of microcontroller<br /> *GPIO12: connect to RESET of microcontroller<br /> *GPIO13: connect to ISP of LPC/ARM microcontroller (not used with Arduino/AVR)<br /> <br /> The flashing doesn't work with avrflash so we did it with avrdude, using the following command :<br /> avrdude -b 57600 -p m328p -c arduino -P net:192.168.4.1:23 -U flash:w:Blink.cpp.hex<br /> <br /> Output :<br /> ioctl(&quot;TIOCMGET&quot;): Inappropriate ioctl for device<br /> ioctl(&quot;TIOCMGET&quot;): Inappropriate ioctl for device<br /> <br /> avrdude: AVR device initialized and ready to accept instructions <br /> <br /> Reading | ################################################## | 100% 0.01s<br /> <br /> avrdude: Device signature = 0x1e950f (probably m328p)<br /> avrdude: NOTE: &quot;flash&quot; memory has been specified, an erase cycle will be performed <br /> To disable this feature, specify the -D option.<br /> avrdude: erasing chip<br /> avrdude: reading input file &quot;blinkLent.cpp.hex&quot;<br /> avrdude: input file blinkLent.cpp.hex auto detected as Intel Hex<br /> avrdude: writing flash (1054 bytes):<br /> <br /> Writing | ################################################## | 100% 0.38s<br /> <br /> avrdude: 1054 bytes of flash written<br /> avrdude: verifying flash memory against blinkLent.cpp.hex:<br /> avrdude: load data flash data from input file blinkLent.cpp.hex:<br /> avrdude: input file blinkLent.cpp.hex auto detected as Intel Hex<br /> avrdude: input file blinkLent.cpp.hex contains 1054 bytes<br /> avrdude: reading on-chip flash data:<br /> <br /> Reading | ################################################## | 100% 0.58s<br /> <br /> avrdude: verifying ...<br /> avrdude: 1054 bytes of flash verified<br /> <br /> avrdude: safemode: Fuses OK (E:00, H:00, L:00)<br /> ioctl(&quot;TIOCMGET&quot;): Inappropriate ioctl for device<br /> <br /> avrdude done. Thank you.<br /> If ever the ESP8266 ain't working anymore, try<br /> esptool.py erase_flash<br /> then flash it again (see week 6)<br /> <br /> == Week 10 (26/03/18) ==<br /> &lt;span style=&quot;color:red&quot;&gt;/!\&lt;/span&gt;This week the action to flash the Olimexino with ESP is not working anymore. Even when we try to erase its memory with ''esptool.py erase_flash'' and flashing it again with an untouched version of esp-link.<br /> The wifi network is still working and we are able to connect to it, but the command using avrdude is not working anymore (and avrflash keeps on not working).<br /> Whe have the following error message :<br /> avrdude: stk500_recv(): programmer is not responding<br /> So we decided to let this part of the project on the side temporarly to focus on the STM32.<br /> Our goal here is first to flash the STM32 with the serial port, and then trying to understand how stm32flash works to implant it into esp-link or avrdude.<br /> Bu stm32flash doesn't work either, displaying the following error : <br /> ./stm32flash -w ../Nucleo/try_Code_STM32/STM32_Blink_lent.bin /dev/ttyUSB0 <br /> <br /> stm32flash 0.5<br /> <br /> http://stm32flash.sourceforge.net/<br /> <br /> Using Parser : Raw BINARY<br /> Interface serial_posix: 57600 8E1<br /> <br /> Failed to init device.<br /> <br /> == Week 11 (06/04/18) ==<br /> This week we tried flashing the Olimexino card with an older version of the esp-link ([https://github.com/jeelabs/esp-link/releases/tag/v2.2.3 2.2.3]) flashed on the WeMos :<br /> esptool.py --port /dev/ttyUSB0 --baud 460800 write_flash -fs 32m -ff 80m \<br /> 0x00000 boot_v1.5.bin 0x1000 user1.bin 0x3FE000 blank.bin<br /> Yet, we are confronted to the same error over and over again, regardless of the pin configuration.<br /> <br /> ----<br /> <br /> We tried &lt;span style=&quot;color: green&quot;&gt; and succeeded &lt;/span&gt; to flash the STM32, this time using the Olimexino as USB to TTL instead of the offical USB to TTL convertor (which doesn't seem to work with the STM32, only with the Arduino).<br /> <br /> Here is the output showed when it works.<br /> stm32flash 0.5<br /> <br /> http://stm32flash.sourceforge.net/<br /> <br /> Using Parser : Raw BINARY<br /> Interface serial_posix: 57600 8E1<br /> Version : 0x31<br /> Option 1 : 0x00<br /> Option 2 : 0x00<br /> Device ID : 0x0421 (STM32F446xx)<br /> - RAM : Up to 128KiB (12288b reserved by bootloader)<br /> - Flash : Up to 512KiB (size first sector: 1x16384)<br /> - Option RAM : 16b<br /> - System RAM : 30KiB<br /> Write to memory<br /> Erasing memory<br /> Wrote address 0x08006fe0 (100.00%) Done. <br /> <br /> Here are the steps to do so :<br /> <br /> * Connect RST of Olimexino to GND of Olimexino.<br /> * Connect 3.3v of Olimexino to 3.3v of STM32.<br /> * Connect GND of Olimexino to GND of STM32.<br /> * Connect RX (D0) of Olimexino to RX (PA10/D2) of STM32.<br /> * Connect TX (D1) of Olimexino to TX (PA9/D8) of STM32.<br /> * Make sure that on the STM32 you have the two jumpers on the ST-LINK.<br /> * Make sure that on the STM32 you have a jumper between E5V and PWR (because when you try to flash it via USB this jumper must be between PWR and U5V for the STM32 to execute its program).<br /> <br /> At this point if you power the Olimexino with the USB connection to your computer, the STM32 will behave normally (executing its program).<br /> <br /> Now you want to enter STM32's bootloader mode :<br /> * Connect the BOOT0 of the STM32 to the VCC of the STM32 (set BOOT0 to high).<br /> * Press the reset button of the STM32 and wait a little bit<br /> * Then you can flash your STM32 with a binary file using stm32flash (http://stm32flash.sourceforge.net/) by using the following command :<br /> sudo ./stm32flash -w ../Nucleo/try_Code_STM32/STM32_Blink.bin /dev/ttyUSB0<br /> * Set BOOT0 to low (disconnect BOOT0 of the STM32 from VCC).<br /> * Press the reset button one more time. The STM32 now behave normally and executes the flashed program.<br /> <br /> ----<br /> <br /> = Links =<br /> * [[Projets_2017-2018 | Projects list]]<br /> * [[RICM4_2017_2018_-_Nucleo/_SRS | SRS]]<br /> * [[RICM4_2017_2018_-_Nucleo/UML | UML]]<br /> * [[Deploiment_Nucleo | Documentation]]</div>

Zoran.Chanet https://air.imag.fr/index.php?title=VT2018_Thorntail_Demo&diff=44898 2019-02-11T08:40:47Z

<p>Zoran.Chanet: /* Introduction */</p> <hr /> <div>= Introduction =<br /> Auteur : [[User:Zoran.Chanet | CHANET Zoran]]&lt;br&gt;<br /> E-mail : [mailto:zoran.chanet@laposte.net zoran.chanet@laposte.net]&lt;br&gt;<br /> Technologie : [[Thorntail]]&lt;br&gt;<br /> Contexte : Démonstration effectuée à l'occasion de la [[Media:VT2018_XXX_presentation.pdf|présentation]] pendant le cours de [[VT2018|Veille Technologique et Stratégique]] du 19/11/2018<br /> <br /> = Prérequis =<br /> Les prérequis de la démonstration sont les mêmes que pour utiliser [[Thorntail]] :<br /> * [[Maven]] 3.2.5 ou supérieur<br /> * [[JavaEE|Java]] JDK8 ou supérieur<br /> <br /> = Base =<br /> [[File:Thorntail_Generator_Screenshot_VT2018.png|500px|thumbnail|right|Capture d'écran du générateur [[Thorntail]]]]<br /> Pour des questions de simplicité, nous allons utiliser le [https://thorntail.io/generator/ générateur Thorntail]. Nous créons un projet ayant comme nom de groupe vt2018.Thorntail.example et nom d'artifact demo. Nous retrouverons ces attributs plus tard, dans le pom.xml du projet généré. Nous choisissons comme fraction (dépendance) [[JAX-RS]], qui va nous permettre de former l'API nécessaire à notre démonstration. Pour le but de cette démonstration, il n'est pas besoin de choisir plus de fractions. Dans un projet réel, il est possible d'en cumuler autant que nécessaire.<br /> <br /> = Validation de la génération =<br /> Voici les section à observer dans le pom.xml.&lt;br&gt;<br /> Les ID demandés ont bien été pris en compte :<br /> &lt;source lang=&quot;XML&quot; line start=&quot;5&quot;&gt;<br /> &lt;groupId&gt;vt2018.Thorntail.example&lt;/groupId&gt;<br /> &lt;artifactId&gt;demo&lt;/artifactId&gt;<br /> &lt;name&gt;Thorntail Example&lt;/name&gt;<br /> &lt;/source&gt;<br /> La référence au BOM a été créée :<br /> &lt;source lang=&quot;XML&quot; line start=&quot;19&quot;&gt;<br /> &lt;dependencyManagement&gt;<br /> &lt;dependencies&gt;<br /> &lt;dependency&gt;<br /> &lt;groupId&gt;io.thorntail&lt;/groupId&gt;<br /> &lt;artifactId&gt;bom-all&lt;/artifactId&gt;<br /> &lt;version&gt;${version.thorntail}&lt;/version&gt;<br /> &lt;scope&gt;import&lt;/scope&gt;<br /> &lt;type&gt;pom&lt;/type&gt;<br /> &lt;/dependency&gt;<br /> &lt;/dependencies&gt;<br /> &lt;/dependencyManagement&gt;<br /> &lt;/source&gt;<br /> Le plugin ''io.thorntail'' pour [[Maven]] est bien importé :<br /> &lt;source lang=&quot;XML&quot; line start=&quot;34&quot;&gt;<br /> &lt;plugin&gt;<br /> &lt;groupId&gt;io.thorntail&lt;/groupId&gt;<br /> &lt;artifactId&gt;thorntail-maven-plugin&lt;/artifactId&gt;<br /> &lt;version&gt;${version.thorntail}&lt;/version&gt;<br /> <br /> &lt;executions&gt;<br /> &lt;execution&gt;<br /> &lt;goals&gt;<br /> &lt;goal&gt;package&lt;/goal&gt;<br /> &lt;/goals&gt;<br /> &lt;/execution&gt;<br /> &lt;/executions&gt;<br /> &lt;/plugin&gt;<br /> &lt;/source&gt;<br /> La fraction [[JAX-RS]] est bien utilisée :<br /> &lt;source lang=&quot;XML&quot; line start=&quot;52&quot;&gt;<br /> &lt;dependency&gt;<br /> &lt;groupId&gt;io.thorntail&lt;/groupId&gt;<br /> &lt;artifactId&gt;jaxrs&lt;/artifactId&gt;<br /> &lt;/dependency&gt;<br /> &lt;/source&gt;<br /> <br /> = Création de l'API =<br /> Maintenant que notre projet [[Thorntail]] a bien été créé, à notre tour de produire l'API que nous souhaitons. Pour cela, nous allons déclarer un premier fichier, ''RestApplication.java'', dans les sources de l'application (à l'emplacement src/main/java/demo).&lt;br&gt;<br /> ''src/main/java/demo/RestApplication.java'' :<br /> &lt;source lang=&quot;Java&quot; line start=&quot;1&quot;&gt;<br /> package demo;<br /> <br /> import javax.ws.rs.core.Application;<br /> import javax.ws.rs.ApplicationPath;<br /> <br /> @ApplicationPath(&quot;/thorntail-demo&quot;)<br /> public class RestApplication extends Application {<br /> }<br /> &lt;/source&gt;<br /> Ce fichier déclare simplement une API à l'adresse ''/thorntail-demo'' (ligne 8) du server sur lequel elle sera déployé. Donnons maintenant un comportement à notre API. Pour cela, créons le fichier ''demoGET2.java''.&lt;br&gt;<br /> ''src/main/java/demo/demoGET2.java'' :<br /> &lt;source lang=&quot;Java&quot; line start=&quot;1&quot;&gt;<br /> package demo;<br /> <br /> import javax.ws.rs.Path;<br /> import javax.ws.rs.GET;<br /> import javax.ws.rs.Produces;<br /> import javax.ws.rs.core.Response;<br /> <br /> @Path(&quot;/Cool_VT_Demo&quot;)<br /> public class demoGet2{<br /> <br /> @GET<br /> @Produces(&quot;text/html&quot;)<br /> public Response doGet() {<br /> return Response.ok(&quot;&lt;h2&gt;What a cool demo.&lt;/h2&gt;&quot;).build();<br /> }<br /> <br /> }<br /> &lt;/source&gt;<br /> Ce fichier produit une réponse html à une requête GET (lignes 11 et 12) lancée à l'adresse ''/Cool_VT_Demo'' (ligne 8) &lt;strong&gt;de l'application&lt;/strong&gt;, soit à l'adresse ''/thorntail-demo/Cool_VT_Demo'' du serveur sur lequel l'API sera déployée. Enfin, pour rajouter un peu d'interactivité et prouver l'usage de l'html, créons le fichier ''demoGET.java''.&lt;br&gt;<br /> ''src/main/java/demoGET.java'' :<br /> &lt;source lang=&quot;Java&quot; line start=&quot;1&quot;&gt;<br /> package demo;<br /> <br /> import javax.ws.rs.Path;<br /> import javax.ws.rs.GET;<br /> import javax.ws.rs.Produces;<br /> import javax.ws.rs.core.Response;<br /> <br /> @Path(&quot;/index&quot;)<br /> public class demoGet{<br /> <br /> @GET<br /> @Produces(&quot;text/html&quot;)<br /> public Response doGet() {<br /> return Response.ok(&quot;&lt;h2&gt;&lt;a href=\&quot;Cool_VT_Demo\&quot;&gt;Clic to see a cool demo&lt;/a&gt;&lt;/h2&gt;&quot;).build();<br /> }<br /> <br /> }<br /> &lt;/source&gt;<br /> Ce fichier produit une réponse html à une requête GET (lignes 11 et 12) lancée à l'adresse ''/index'' (ligne 8) &lt;strong&gt;de l'application&lt;/strong&gt;, soit à l'adresse ''/thorntail-demo/index'' du serveur sur lequel l'API sera déployée. La réponse sera un lien cliquable renvoyant sur l'adresse ''/Cool_VT_Demo'' de l'application, soit ''demoGET2''.<br /> <br /> = Démonstration =<br /> [[File:VT2018_Thorntail_Demo1.png|500px|thumbnail|right|fig.1 : Capture d'écran de l'API de démonstration (1)]]<br /> [[File:VT2018_Thorntail_Demo2.png|470px|thumbnail|right|fig.2 : Capture d'écran de l'API de démonstration (2)]]<br /> Enfin, voyons à quoi ressemble notre API. Pour cela, nous allons provoquer la création par [[Thorntail]] de l'UberJAR exécutable et son exécution sur l'adresse locale par une seule commande :<br /> mvn thorntail:run<br /> Si aucune erreur n'est produite, notre API est maintenant disponible à l'adresse [http://http://localhost:8080/thorntail-demo/index localhost:8080/thorntail-demo/index] (fig.1), et nous permet bien d'accéder à [http://http://localhost:8080/thorntail-demo/index localhost:8080/thorntail-demo/Cool_VT_Demo] (fig.2) en cliquant sur le lien.&lt;br&gt;<br /> De plus, nous pouvons constater l'apparition dans le dossier ''target'' de ''demo.war'', contenant les composants de l'application, et de l'UberJAR ''demo-thorntail.jar'' (que nous pouvons également exécuter par la commande classique, ''java -jar demo-thorntail.jar'').</div>

Zoran.Chanet https://air.imag.fr/index.php?title=User:Zoran.Chanet&diff=44897 2019-02-11T08:36:52Z

<p>Zoran.Chanet: </p> <hr /> <div>= Contact =<br /> Profil LinkedIn : [https://www.linkedin.com/in/zoran-chanet Zoran CHANET]&lt;br&gt;<br /> Profil GitHub : [https://github.com/ProfesseurSid ProfesseurSid]&lt;br&gt;<br /> Profil GitLab : [https://gitlab.com/CHANET_Zoran CHANET_Zoran]&lt;br&gt;<br /> Profil gricad.gitlab : [https://gricad-gitlab.univ-grenoble-alpes.fr/chanetz chanetz]&lt;br&gt;<br /> E-mail : [mailto:zoran.chanet@etu.univ-grenoble-alpes.fr zoran.chanet@etu.univ-grenoble-alpes.fr] (expire en 2020)<br /> <br /> = Projets =<br /> == 2017-2018 ==<br /> [[RICM4 2017 2018 - Nucleo]] <br /> <br /> == 2018-2019 ==<br /> [[VT2018 Thorntail]]&lt;br&gt;<br /> [[ECOM-1F0 1819 BTB]] &lt;br&gt;<br /> [[PROJET-INFO5 1819 EDCampus]]<br /> <br /> = Articles =<br /> Diverses pages de technologies du projet [[ECOM-1F0 1819 BTB#Technologies | ECOM]]&lt;br&gt;<br /> [[VT2018 Thorntail]]&lt;br&gt;<br /> [[VT2018 Thorntail Demo]]&lt;br&gt;<br /> [[SonarQube Scanner]]&lt;br&gt;<br /> [[GitLab Runners]]&lt;br&gt;<br /> [[GitLab CI/CD]]&lt;br&gt;<br /> [[Apache mod_rewrite]]&lt;br&gt;</div>

Zoran.Chanet https://air.imag.fr/index.php?title=PROJET-INFO5_1819_EDCampus&diff=44896 2019-02-11T08:25:06Z

<p>Zoran.Chanet: /* Zoran */</p> <hr /> <div>[[File:Logo_EDCampus.png|thumb|right| Logo EDCampus]]<br /> = Le projet en quelques mots =<br /> La plateforme [[Contributions open-source au projet Eclipse EdCampus | EDCampus]] est une plateforme de gestion de projet développé par Disrupt Campus Grenoble. La plateforme est actuellement en train d’être soumis à la fondation Eclipse afin d’être mise en open source sous licence Eclipse. Dans le cadre du projet Disrupt Campus, les étudiants sont invités à contribuer à la plateforme. Dans le cadre de vos formations c’est une vraie plus value de contribuer à de réels projets plutôt qu’à des projets one-shot qui seront mis à la poubelle sitôt votre soutenance terminée. EDCampus est donc une opportunité de contribuer au logiciel libre et à la fondation Eclipse (et de s'assurer une jolie ligne sur son CV plutôt qu'un projet qui sera aussi vite oublié que l'ECOM !). <br /> <br /> = L'équipe et leurs rôles =<br /> <br /> * GEOURJON Anthony - Chef de projet (EXT)<br /> * [[User:Servan.Charlot | CHARLOT Servan]] - Chef de groupe<br /> * [[User:Zoran.Chanet | CHANET Zoran]] - Responsable DevOps<br /> <br /> = Roadmap =<br /> * '''20-22 février 2019 :''' Hack Ton Campus, la plateforme EDCampus sera utilisée pour la gestion des défis.<br /> * '''Avril 2019 :''' Projet pilote, un projet mêlant une entreprise, l'UGA et des étudiants servira de test à la plateforme.<br /> * '''Septembre 2019 :''' Mise en production globale.<br /> <br /> = Carnet de bord =<br /> <br /> == Semaine 1 ==<br /> <br /> === 28/01/19 ===<br /> <br /> Assignation du sujet [[Contributions open-source au projet Eclipse EdCampus | EDCampus]].<br /> <br /> === 29/01/19 ===<br /> <br /> * Rencontre avec Anthony au [http://fabmstic.liglab.fr/ Fablab], presentation du sujet, des enjeux, et de la roadmap<br /> * Installation du projet<br /> ** Difficultés dues au DNS des réseaux universitaires (impossible de télécharger le contenu nécessaire depuis les containers)<br /> <br /> === 30/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $scope._getProjectParent()&lt;/code&gt; qui ne marchait pas du tout. Il y avait une faute dans la plupart des variables qui s'appelaient &lt;code&gt;currentParentProject&lt;/code&gt; au lieu de &lt;code&gt;currentProjectParent&lt;/code&gt;.<br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $rootScope._checkProject()&lt;/code&gt; qui oubliait un paramètre dans son appel à &lt;code&gt;$scope._setProject()&lt;/code&gt;.<br /> <br /> ==== Zoran ====<br /> * Assignation d'une première tâche : réparer la création d'un projet indépendant<br /> * Découverte du code du projet<br /> * Poursuite de l'arborescence des appels depuis le bouton jusqu'à l'appel à la base de données<br /> <br /> === 01/02/19 ===<br /> ==== Servan ====<br /> <br /> * Assignation de la tâche consistant à réparer le système de fichier.<br /> * Exploration du systeme de fichier et son implementation.<br /> <br /> ==== Zoran ====<br /> * Production d'une méthode permettant des logs personnalisés<br /> * Recherches sur le rewriting d'URL<br /> * Correction du problème (lié au rewriting)<br /> * Production d'une fiche explicative de la solution<br /> <br /> == Semaine 2 ==<br /> <br /> === 04/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction des bugs suivants :<br /> <br /> * Affichage des fichiers du portefeuille père ssi il y a au moins un fichier présent dans le projet fils.<br /> ** Dans le backend, la fonction qui get les fichiers exécutait un &lt;code&gt;return false&lt;/code&gt; avant de get les fichiers parents dans le cas ou il n'y avait pas de fichier à la base.<br /> * N'actualise pas la liste des fichiers si on supprime le dernier fichier.<br /> * Tous les dossiers sont affichés comme des fichiers. Lors de la première sélection à la souris, si on sélectionne le fichier-dossier, il se transforme en dossier et on peut y accéder. Rien ne se passe pour les sélections suivantes.<br /> ** Dans le backend, un paramètre était traité comme chaîne de caractère alors qu'il représentait un booléen. Le résultat de ça est que l'on entrait dans la mauvaise partie d'un if, qui exécutait la mauvaise requête SQL nous privant de l'information concernant le type de fichier lu (un dossier est un type de fichier).<br /> * Le bouton qui permet de revenir en arrière, sortir du dossier ne fonctionne pas.<br /> * On ne peut pas entrer dans un dossier hérité.<br /> <br /> ==== Zoran ====<br /> * Assignation de la mise en place de techniques DevOps<br /> * Recherches sur la mise en place de pipeline dans GitLab : voir [[GitLab CI/CD | compte-rendu]]<br /> * Mise en place d'un pipeline à chaque push<br /> * Production d'un tutoriel de création de runner GitLab : voir [[GitLab Runners | tutoriel]]<br /> * Recherches sur SonarQube et les tests unitaires<br /> ** Priorisation de SonarQube<br /> <br /> === 05/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug qui faisait que lors de la suppression d'un dossier, les fichiers à l'intérieur ne sont pas supprimés (le champ statut dans le BDD ne passe pas à 0).<br /> ** La fonctionnalité de suppression récursive n'était pas implémentée dans &lt;code&gt;File.php&lt;/code&gt;.<br /> * Début de l'analyse du système de droit des utilisateurs (Administrateur/Tuteur/Elève) sur les fichiers et dossiers (hérités ou non).<br /> <br /> ==== Zoran ====<br /> * Compréhension des scanners sonar : voir [[SonarQube Scanner | compte-rendu]]<br /> * Mise en place d'un scan dans le pipeline<br /> ** Nécessité d'un serveur sonar exposé<br /> ** Décision d'utiliser SonarCloud<br /> ** Configuration du scanner pour envoyer le rapport dans le bon projet sonarcloud<br /> ** Réussite du premier scan<br /> <br /> === 06/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Suite de la correction du système de droits des fichiers/dossiers.<br /> <br /> * Correction d'un bug qui faisait que les utilisateurs ne peuvent pas entrer dans les dossiers hérites (ou télécharger les fichiers hérites).<br /> ** Le check de droit se fait dans une fonction qui check d'abord le &lt;code&gt;ownerId&lt;/code&gt;, puis le &lt;code&gt;projectId&lt;/code&gt; et puis enfin si le fichier appartient à un parent. Pour cela elle fait appel à la base pour récupérer la relation d’héritage. IL y avait une erreur de comparaison entre le résultat de la requête et les information fichier (erreur de type parce que PHP).<br /> * Analyse complète du système de droit création d'un tableau explicatif de l'état actuel et l'état voulu.<br /> [[File:EDCampus_2019_Tableau_de_droits.png|center]]<br /> * Suite au tableau, mise en place de la protection des fichiers hérités.<br /> ** Ajout d'une vérification sur le &lt;code&gt;projectId&lt;/code&gt;, empêchant les utilisateurs non propriétaires du fichier de le supprimer, renommer ou déplacer.<br /> <br /> ==== Zoran ====<br /> * Extension du scan sonar dans le pipeline à toutes les sections du projet<br /> * Affichage de badges d'état du pipeline sur la page de présentation de chaque section du projet<br /> * Reprise des recherches concernant les tests unitaires<br /> * Tentative de systématisation des tests dans le pipeline<br /> ** Difficulté : les tests nécessitent des fichiers de configurations qui ne sont pas présents sur le repository git<br /> * Recherche de contournement pour ne pas exposer des configurations privées dans le projet public<br /> <br /> === 08/02/19 ===<br /> <br /> ==== Servan ====<br /> Suppression de la vue pour les non membres et correction partielle du système de droits.<br /> * Lorsque qu'une commande est envoyée par le front-end vers le back-end, elle passe dans une fonction qui vérifie les droits (&lt;code&gt;Right.php checkRights($command)&lt;/code&gt;). La fonction compare la commande utilisée par l'utilisateur aux commandes que cet utilisateur a en général le droit d'utiliser. Le problème était que le tableau de commandes au sein de la fonction (permettant la comparaison) contenait des commandes mal formatées. J'ai donc corrigé celle qui m'intéressais pour empêcher les non membres d'un projet à consulter les fichiers, et j'en ai profiter pour corriger toutes les autres.<br /> <br /> ==== Zoran ====<br /> * Configuration des scanners sonar dans le pipeline (redirection vers une branche du projet sonarcloud nommée selon la branche GitLab sur laquelle le pipeline est lancé)<br /> * Aide à la correction du système de droits<br /> * Réalisation de tâches mineures importantes pour le Hackaton<br /> ** Retirer la vidéo Waza de l'accueil de la plateforme<br /> ** Redirection de l'utilisateur vers la plateforme lorsqu'il accède à l'url du dossier : [[Apache mod_rewrite]]<br /> ** Correction de l'url donné lors de l'appel au service de mails pour la validation de compte<br /> <br /> == Semaine 3 ==<br /> <br /> === 12/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====<br /> <br /> === 13/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====<br /> <br /> === 14/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====<br /> <br /> === 15/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====</div>

Zoran.Chanet https://air.imag.fr/index.php?title=Apache_mod_rewrite&diff=44895 2019-02-11T08:23:10Z

<p>Zoran.Chanet: Created page with &quot;= Auteur = CHANET Zoran = mod_rewrite = Le module Apache de rewriting d’url se nomme mod_rewrite. Il permet d’indiquer simplement des règles de r...&quot;</p> <hr /> <div>= Auteur =<br /> [[User:Zoran.Chanet | CHANET Zoran]]<br /> <br /> = mod_rewrite =<br /> Le module Apache de rewriting d’url se nomme mod_rewrite. Il permet d’indiquer simplement des règles de réécriture, selon l’url demandé par l’utilisateur. Cela se fera dans le fichier [[Apache mod_rewrite#Fichier .htaccess | .htaccess]].&lt;br&gt;<br /> Pour l’activer, il faut ajouter ces quelques lignes dans le fichier &lt;code&gt;/etc/apache2/apache2.conf&lt;/code&gt; (si elles n’y sont pas déjà) :<br /> &lt;ifModule mod_rewrite.c&gt;<br /> RewriteEngine On<br /> &lt;/ifModule&gt;<br /> Il faut alors redémarrer le serveur Apache :<br /> sudo /etc/init.d/apache2 restart<br /> <br /> = Diagnostic =<br /> * Si le module rewrite est présent, un fichier &lt;code&gt;mod_rewrite.so&lt;/code&gt; doit exister. Cela se vérifie par la commande suivante :<br /> ls -l /usr/lib/apache2/modules/<br /> * Cette commande permet de recréer les liens entre Apache et le mod_rewrite :<br /> sudo a2enmod rewrite<br /> <br /> = Fichier .htaccess =<br /> * Le mode rewriting est d’abord activé avec &lt;code&gt;RewriteEngine on&lt;/code&gt;.<br /> * ''^'' correspond au début d’une expression rationnelle, ''$'' à la fin de celle-ci. Les symboles utilisés sont décrits sur cette page : [https://httpd.apache.org/docs/2.2/fr/rewrite/intro.html#regex].<br /> * Les drapeaux de réécriture sont décrits ici : [https://httpd.apache.org/docs/2.2/fr/rewrite/flags.html].<br /> * Les différentes directives utilisables sont recensées dans la documentation : [https://httpd.apache.org/docs/2.2/fr/mod/mod_rewrite.html#Solutions].<br /> * &lt;code&gt;%{&lt;NOM_DE_VARIABLE}&lt;/code&gt; permet d'accéder aux variables de serveur.<br /> <br /> == Exemple ==<br /> Nous allons explorer l'exemple d'une règle de redirection à l'aide des directives RewriteCond et RewriteRule, utilisées comme suit : <br /> RewriteCond &lt;chaîne de test&gt; &lt;expression de comparaison&gt;<br /> RewriteRule &lt;modèle&gt; &lt;substitution&gt; [&lt;Drapeaux&gt;]<br /> ''.htaccess :''<br /> RewriteEngine on<br /> RewriteCond %{REQUEST_URI} ^/$<br /> RewriteRule (.*) /app [R=301,L]<br /> * On active d’abord le moteur de redirection.<br /> * Ensuite, on définit une condition d’accès à la règle, &lt;code&gt;%{REQUEST_URI}&lt;/code&gt; indiquant la variable serveur correspondant à l'uri auquel on essaie d'accéder, l’uri spécifié étant &lt;code&gt;/&lt;/code&gt; (par l'expression rationelle &lt;code&gt;^/$&lt;/code&gt;).<br /> * Enfin, la règle de réécriture s’applique à tout l’uri (&lt;code&gt;.*&lt;/code&gt;), et le remplace par &lt;code&gt;/app&lt;/code&gt;. Une redirection est alors performée en indiquant un code de retour 301 (&lt;code&gt;R=301&lt;/code&gt;). Cette règle est indiquée comme la dernière à appliquer par le flag &lt;code&gt;L&lt;/code&gt;.<br /> * Si ce fichier &lt;code&gt;.htaccess&lt;/code&gt; est utilisé pour un serveur hébergé à l'adresse &lt;code&gt;monsite.fr&lt;/code&gt;, tout accès à &lt;code&gt;monsite.fr/&lt;/code&gt; sera redirigé vers &lt;code&gt;monsite.fr/app&lt;/code&gt;.<br /> <br /> = Sources =<br /> [1] https://httpd.apache.org/docs/2.2/fr/rewrite/intro.html#regex&lt;br&gt;<br /> [2] https://httpd.apache.org/docs/2.2/fr/rewrite/flags.html&lt;br&gt;<br /> [3] https://httpd.apache.org/docs/2.2/fr/mod/mod_rewrite.html#Solutions&lt;br&gt;<br /> [4] https://httpd.apache.org/docs/2.2/fr/rewrite/intro.html&lt;br&gt;<br /> [5] https://itx-technologies.com/fr/blog/28-installer-et-activer-le-module-mod_rewrite-sur-apache-et-ubuntu</div>

Zoran.Chanet https://air.imag.fr/index.php?title=GitLab_CI/CD&diff=44884 2019-02-08T12:58:02Z

<p>Zoran.Chanet: /* Astuces */</p> <hr /> <div>= Auteur =<br /> [[User:Zoran.Chanet | CHANET Zoran]]<br /> <br /> = Prérequis =<br /> * Version Gitlab &gt;= 8.0 ou utiliser GitLab.com<br /> * &lt;code&gt;Settings -&gt; General -&gt; Permissions -&gt; Pipelines&lt;/code&gt; (''Only team members'' ou ''Everyone with access'')<br /> * Au moins un runner configuré pour le projet (ou shared runner) (voir &lt;code&gt;Settings -&gt; CI/CD -&gt; Runners&lt;/code&gt;) (''Enable shared runners on this project'' pour avoir accès aux shared runners)<br /> <br /> = Activation =<br /> Définir un fichier &lt;code&gt;.gitlab-ci.yml&lt;/code&gt; valide à la racine du projet<br /> <br /> = Runners =<br /> * Sont des VM isolées<br /> * Peuvent être ''shared'' entre les projets<br /> * Idéalement sur une autre machine que le projet GitLab<br /> * Configurés par le fichier &lt;code&gt;.gitlab-ci.yml&lt;/code&gt; pour définir des étapes (build, test, deploy…)<br /> * &lt;code&gt;Settings -&gt; CI/CD -&gt; Runners&lt;/code&gt; (pour voir lesquels sont assignés au projet)<br /> <br /> = Astuces =<br /> * &lt;code&gt;.gitlab-ci.yml&lt;/code&gt; est dépendant de la version (donc branche)<br /> * Format du fichier &lt;code&gt;.gitlab-ci.yml&lt;/code&gt; :<br /> stages:<br /> - &lt;étape&gt;<br /> - &lt;étape&gt;<br /> - ...<br /> <br /> before_script:<br /> - &lt;commande&gt;<br /> - &lt;commande&gt;<br /> - … <br /> <br /> &lt;job1-name&gt;:<br /> stage: &lt;étape&gt;<br /> script:<br /> - &lt;commande&gt;<br /> - &lt;commande&gt;<br /> - …<br /> <br /> &lt;job2-name&gt;:<br /> stage: &lt;étape&gt;<br /> script:<br /> - &lt;commande&gt;<br /> - &lt;commande&gt;<br /> - …<br /> <br /> …<br /> * &lt;span style=&quot;color:red&quot;&gt;/!\&lt;/span&gt; Les espaces doivent rester des espaces (pas des tabulations)<br /> * &lt;span style=&quot;color:red&quot;&gt;/!\&lt;/span&gt; &lt;code&gt;script&lt;/code&gt; est un mot-clé obligatoire pour chaque job<br /> * &lt;code&gt;before_script&lt;/code&gt; est optionnel et exécuté avant chaque &lt;code&gt;script&lt;/code&gt;<br /> * Les balises &lt;code&gt;stages&lt;/code&gt; et &lt;code&gt;stage&lt;/code&gt; sont optionnelles mais structurent le pipeline<br /> * &lt;code&gt;CI/CD -&gt; Pipelines -&gt; CI LINT&lt;/code&gt; (bouton) permet de tester la validité du fichier &lt;code&gt;.gitlab-ci.yml&lt;/code&gt;<br /> * ''stuck'' signifie qu’aucun runner n’est configuré pour prendre en charge le job<br /> * Si des runners sont actifs et affiliés au projet (voir &lt;code&gt;Settings -&gt; CI/CD -&gt; Runners&lt;/code&gt;) mais que le pipeline indique ''stuck'', il peut être nécessaire d'autoriser les runners à accepter les jobs sans tags<br /> * Examples de &lt;code&gt;.gitlab_ci.yml&lt;/code&gt; : [https://gricad-gitlab.univ-grenoble-alpes.fr/help/ci/examples/README.md https://gricad-gitlab.univ-grenoble-alpes.fr/help/ci/examples/README.md]<br /> <br /> = Fonctionnement =<br /> * Activation du pipeline à chaque push sur une branche disposant du fichier &lt;code&gt;.gitlab-ci.yml&lt;/code&gt;<br /> * Au lancement, chaque job est réalisé par un runner dans son propre environnement<br /> <br /> = Sources =<br /> [https://gricad-gitlab.univ-grenoble-alpes.fr/help/ci/quick_start/README Getting started with GitLab CI/CD]&lt;br&gt;<br /> [https://gricad-gitlab.univ-grenoble-alpes.fr/help/ci/enable_or_disable_ci.md How to enable or disable GitLab CI/CD]</div>

Zoran.Chanet https://air.imag.fr/index.php?title=SonarQube_Scanner&diff=44882 2019-02-08T12:30:34Z

<p>Zoran.Chanet: /* Configuration */</p> <hr /> <div>= Auteur =<br /> [[User:Zoran.Chanet | CHANET Zoran]]<br /> <br /> = Introduction =<br /> Cette page explique rapidement le fonctionnement des scanners SonarQube, et en explique la configuration afin qu'il analyse un projet au sein d'un pipeline d'intégration continue [[GitLab CI/CD]] et envoie les données récoltées à [https://sonarcloud.io/ SonarCloud]. Il est également possible d'installer un server SonarQube et de configurer le scanner pour qu'il envoie les informations sur ce server (&lt;code&gt;sonar.host.url&lt;/code&gt;). Pour l'installation d'un tel serveur, voir [[SonarQube]].<br /> <br /> = Scanner =<br /> Le scanner est celui qui nous permettra de parcourir les fichiers et de relever les erreurs. Il doit être installé sur la machine qui l’utilise. Dans le cas de l'intégration continue [[GitLab CI/CD]], il doit donc être installé sur le runner qui exécute le job correspondant. Afin d’éviter de devoir contrôler précisément quels runners sont utilisés pour le job, et de devoir synchroniser les installations sur tous les runners du projet, il est possible de télécharger et installer le scanner au début du script dans le fichier &lt;code&gt;.gitlab-ci.yml&lt;/code&gt; qui définit le pipeline.<br /> <br /> = Serveur =<br /> Le scanner se contente d’analyser le code. Pour obtenir le bel affichage auquel nous a habitué [https://www.sonarqube.org/ SonarQube], le résultat de cette analyse doit être envoyé à un serveur. Dans le cas de l'intégration continue [[GitLab CI/CD]], puisque le scan tourne sur le runner, il faut que le serveur soit actif et exposé (si le serveur sonar était installé sur le runner et lancé en local avant le scan, il serait détruit à l’arrêt du runner). Il est possible d'utiliser [https://sonarcloud.io/ SonarCloud], un serveur sonar public et gratuit pour les projets opensource. Il faut alors configurer le projet scanné pour que l’analyse soit envoyée à SonarCloud, en renseignant le bon projet, la bonne compagnie et le bon token d’authentification (il faut que l’utilisateur ait le droit de lancer une analyse).<br /> <br /> = Configuration =<br /> Afin que le runner nouvellement installé bénéficie simplement de la configuration décidée en amont, cette configuration est faite pour le projet, dans le fichier &lt;code&gt;sonar-project.properties&lt;/code&gt; dans le dossier racine du projet. Ce fichier spécifie la configuration utilisée par le scanner pour l’analyse du projet.&lt;br&gt;<br /> Comme expliqué dans la page dédiée à [[GitLab CI/CD]], le fichier &lt;code&gt;.gitlab-ci.yml&lt;/code&gt; définit le comportement du pipeline. Ici, il nous est donc utile à télécharger, installer et utiliser le scanner.&lt;br&gt;<br /> Le fichier &lt;code&gt;sonar-project.properties&lt;/code&gt; définit les variables de configuration utilisées par le scanner. Il est également possible de configurer le scanner en ligne de commande, en ajoutant les options sous la forme &lt;code&gt;-D &lt;property-name&gt;=&lt;property-value&gt;&lt;/code&gt; lors de l'appel au scanner.<br /> <br /> == .gitlab-ci.yml ==<br /> &lt;span style=&quot;color:red&quot;&gt;/!\&lt;/span&gt; Ce fichier est un &lt;code&gt;.yml&lt;/code&gt;, l’identation (avec des espaces et non des tabulations) est '''importante'''.&lt;br&gt;<br /> Le script sonar-analysis télécharge d'abord une archive de scanner (ici, la version '3.3.0.1492'), puis l'extrait (au cas où le scanner ne puisse utiliser unzip, un fichier python est défini pour extraire l'archive). Après avoir donné au runner les droits d'exécution du scanner, l'analyse est lancée.<br /> stages:<br /> - test<br /> <br /> sonar-analysis:<br /> stage: test<br /> script:<br /> - wget &quot;https://binaries.sonarsource.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-3.3.0.1492-linux.zip&quot;<br /> - echo &quot;import zipfile&quot; &gt; unzip.py<br /> - echo &quot;&quot; &gt;&gt; unzip.py<br /> - echo &quot;with zipfile.ZipFile('sonar-scanner-cli-3.3.0.1492-linux.zip', \&quot;r\&quot;) as z:&quot; &gt;&gt; unzip.py<br /> - echo &quot; z.extractall(\&quot;.\&quot;)&quot; &gt;&gt; unzip.py<br /> - python unzip.py<br /> - rm unzip.py<br /> - rm sonar-scanner-cli-3.3.0.1492-linux.zip<br /> - chmod -R +x sonar-scanner-3.3.0.1492-linux/<br /> - sonar-scanner-3.3.0.1492-linux/bin/sonar-scanner<br /> <br /> == sonar-project.properties ==<br /> # sonarqube server<br /> sonar.host.url=https://sonarcloud.io<br /> <br /> # Required metadata<br /> # must be unique in a given SonarQube instance<br /> sonar.projectKey=&lt;project-key&gt;<br /> sonar.organization=&lt;organization&gt;<br /> sonar.login=&lt;authentication-token&gt;<br /> sonar.projectVersion=1.0<br /> <br /> # Optional metadata<br /> # Default: master<br /> # sonar.branch.name=&lt;branch-name&gt;<br /> <br /> # Comma-separated paths to directories with sources (required)<br /> # Path is relative to the sonar-project.properties file. Replace &quot;\&quot; by &quot;/&quot; on Windows.<br /> # This property is optional if sonar.modules is set.<br /> sonar.sources=.<br /> sonar.exclusions=sonar-scanner-3.3.0.1492-linux/**,&lt;paths-to-exclude-from-scan&gt;<br /> <br /> # Language<br /> #sonar.language=javascript<br /> sonar.c.file.suffixes=-<br /> sonar.cpp.file.suffixes=-<br /> sonar.objc.file.suffixes=-<br /> <br /> # Encoding of the source code. Default is default system encoding<br /> sonar.sourceEncoding=UTF-8<br /> <br /> = Sources =<br /> [https://docs.sonarqube.org/latest/setup/get-started-2-minutes/ https://docs.sonarqube.org/latest/setup/get-started-2-minutes/]&lt;br&gt;<br /> [https://docs.sonarqube.org/latest/analysis/analysis-parameters/ https://docs.sonarqube.org/latest/analysis/analysis-parameters/]&lt;br&gt;<br /> [https://docs.sonarqube.org/latest/project-administration/narrowing-the-focus/ https://docs.sonarqube.org/latest/project-administration/narrowing-the-focus/]</div>

Zoran.Chanet https://air.imag.fr/index.php?title=SonarQube_Scanner&diff=44873 2019-02-08T10:36:27Z

<p>Zoran.Chanet: /* sonar-project.properties */</p> <hr /> <div>= Auteur =<br /> [[User:Zoran.Chanet | CHANET Zoran]]<br /> <br /> = Introduction =<br /> Cette page explique rapidement le fonctionnement des scanners SonarQube, et en explique la configuration afin qu'il analyse un projet au sein d'un pipeline d'intégration continue [[GitLab CI/CD]] et envoie les données récoltées à [https://sonarcloud.io/ SonarCloud]. Il est également possible d'installer un server SonarQube et de configurer le scanner pour qu'il envoie les informations sur ce server (&lt;code&gt;sonar.host.url&lt;/code&gt;). Pour l'installation d'un tel serveur, voir [[SonarQube]].<br /> <br /> = Scanner =<br /> Le scanner est celui qui nous permettra de parcourir les fichiers et de relever les erreurs. Il doit être installé sur la machine qui l’utilise. Dans le cas de l'intégration continue [[GitLab CI/CD]], il doit donc être installé sur le runner qui exécute le job correspondant. Afin d’éviter de devoir contrôler précisément quels runners sont utilisés pour le job, et de devoir synchroniser les installations sur tous les runners du projet, il est possible de télécharger et installer le scanner au début du script dans le fichier &lt;code&gt;.gitlab-ci.yml&lt;/code&gt; qui définit le pipeline.<br /> <br /> = Serveur =<br /> Le scanner se contente d’analyser le code. Pour obtenir le bel affichage auquel nous a habitué [https://www.sonarqube.org/ SonarQube], le résultat de cette analyse doit être envoyé à un serveur. Dans le cas de l'intégration continue [[GitLab CI/CD]], puisque le scan tourne sur le runner, il faut que le serveur soit actif et exposé (si le serveur sonar était installé sur le runner et lancé en local avant le scan, il serait détruit à l’arrêt du runner). Il est possible d'utiliser [https://sonarcloud.io/ SonarCloud], un serveur sonar public et gratuit pour les projets opensource. Il faut alors configurer le projet scanné pour que l’analyse soit envoyée à SonarCloud, en renseignant le bon projet, la bonne compagnie et le bon token d’authentification (il faut que l’utilisateur ait le droit de lancer une analyse).<br /> <br /> = Configuration =<br /> Afin que le runner nouvellement installé bénéficie simplement de la configuration décidée en amont, cette configuration est faite pour le projet, dans le fichier &lt;code&gt;sonar-project.properties&lt;/code&gt; dans le dossier racine du projet. Ce fichier spécifie la configuration utilisée par le scanner pour l’analyse du projet.&lt;br&gt;<br /> Comme expliqué dans la page dédiée à [[GitLab CI/CD]], le fichier &lt;code&gt;.gitlab-ci.yml&lt;/code&gt; définit le comportement du pipeline. Ici, il nous est donc utile à télécharger, installer et utiliser le scanner.&lt;br&gt;<br /> Le fichier &lt;code&gt;sonar-project.properties&lt;/code&gt; définit les variables de configuration utilisées par le scanner.<br /> <br /> == .gitlab-ci.yml ==<br /> &lt;span style=&quot;color:red&quot;&gt;/!\&lt;/span&gt; Ce fichier est un &lt;code&gt;.yml&lt;/code&gt;, l’identation (avec des espaces et non des tabulations) est '''importante'''.&lt;br&gt;<br /> Le script sonar-analysis télécharge d'abord une archive de scanner (ici, la version '3.3.0.1492'), puis l'extrait (au cas où le scanner ne puisse utiliser unzip, un fichier python est défini pour extraire l'archive). Après avoir donné au runner les droits d'exécution du scanner, l'analyse est lancée.<br /> stages:<br /> - test<br /> <br /> sonar-analysis:<br /> stage: test<br /> script:<br /> - wget &quot;https://binaries.sonarsource.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-3.3.0.1492-linux.zip&quot;<br /> - echo &quot;import zipfile&quot; &gt; unzip.py<br /> - echo &quot;&quot; &gt;&gt; unzip.py<br /> - echo &quot;with zipfile.ZipFile('sonar-scanner-cli-3.3.0.1492-linux.zip', \&quot;r\&quot;) as z:&quot; &gt;&gt; unzip.py<br /> - echo &quot; z.extractall(\&quot;.\&quot;)&quot; &gt;&gt; unzip.py<br /> - python unzip.py<br /> - rm unzip.py<br /> - rm sonar-scanner-cli-3.3.0.1492-linux.zip<br /> - chmod -R +x sonar-scanner-3.3.0.1492-linux/<br /> - sonar-scanner-3.3.0.1492-linux/bin/sonar-scanner<br /> <br /> == sonar-project.properties ==<br /> # sonarqube server<br /> sonar.host.url=https://sonarcloud.io<br /> <br /> # Required metadata<br /> # must be unique in a given SonarQube instance<br /> sonar.projectKey=&lt;project-key&gt;<br /> sonar.organization=&lt;organization&gt;<br /> sonar.login=&lt;authentication-token&gt;<br /> sonar.projectVersion=1.0<br /> <br /> # Optional metadata<br /> # Default: master<br /> # sonar.branch.name=&lt;branch-name&gt;<br /> <br /> # Comma-separated paths to directories with sources (required)<br /> # Path is relative to the sonar-project.properties file. Replace &quot;\&quot; by &quot;/&quot; on Windows.<br /> # This property is optional if sonar.modules is set.<br /> sonar.sources=.<br /> sonar.exclusions=sonar-scanner-3.3.0.1492-linux/**,&lt;paths-to-exclude-from-scan&gt;<br /> <br /> # Language<br /> #sonar.language=javascript<br /> sonar.c.file.suffixes=-<br /> sonar.cpp.file.suffixes=-<br /> sonar.objc.file.suffixes=-<br /> <br /> # Encoding of the source code. Default is default system encoding<br /> sonar.sourceEncoding=UTF-8<br /> <br /> = Sources =<br /> [https://docs.sonarqube.org/latest/setup/get-started-2-minutes/ https://docs.sonarqube.org/latest/setup/get-started-2-minutes/]&lt;br&gt;<br /> [https://docs.sonarqube.org/latest/analysis/analysis-parameters/ https://docs.sonarqube.org/latest/analysis/analysis-parameters/]&lt;br&gt;<br /> [https://docs.sonarqube.org/latest/project-administration/narrowing-the-focus/ https://docs.sonarqube.org/latest/project-administration/narrowing-the-focus/]</div>

Zoran.Chanet https://air.imag.fr/index.php?title=SonarQube_Scanner&diff=44872 2019-02-08T10:36:10Z

<p>Zoran.Chanet: /* sonar-project.properties */</p> <hr /> <div>= Auteur =<br /> [[User:Zoran.Chanet | CHANET Zoran]]<br /> <br /> = Introduction =<br /> Cette page explique rapidement le fonctionnement des scanners SonarQube, et en explique la configuration afin qu'il analyse un projet au sein d'un pipeline d'intégration continue [[GitLab CI/CD]] et envoie les données récoltées à [https://sonarcloud.io/ SonarCloud]. Il est également possible d'installer un server SonarQube et de configurer le scanner pour qu'il envoie les informations sur ce server (&lt;code&gt;sonar.host.url&lt;/code&gt;). Pour l'installation d'un tel serveur, voir [[SonarQube]].<br /> <br /> = Scanner =<br /> Le scanner est celui qui nous permettra de parcourir les fichiers et de relever les erreurs. Il doit être installé sur la machine qui l’utilise. Dans le cas de l'intégration continue [[GitLab CI/CD]], il doit donc être installé sur le runner qui exécute le job correspondant. Afin d’éviter de devoir contrôler précisément quels runners sont utilisés pour le job, et de devoir synchroniser les installations sur tous les runners du projet, il est possible de télécharger et installer le scanner au début du script dans le fichier &lt;code&gt;.gitlab-ci.yml&lt;/code&gt; qui définit le pipeline.<br /> <br /> = Serveur =<br /> Le scanner se contente d’analyser le code. Pour obtenir le bel affichage auquel nous a habitué [https://www.sonarqube.org/ SonarQube], le résultat de cette analyse doit être envoyé à un serveur. Dans le cas de l'intégration continue [[GitLab CI/CD]], puisque le scan tourne sur le runner, il faut que le serveur soit actif et exposé (si le serveur sonar était installé sur le runner et lancé en local avant le scan, il serait détruit à l’arrêt du runner). Il est possible d'utiliser [https://sonarcloud.io/ SonarCloud], un serveur sonar public et gratuit pour les projets opensource. Il faut alors configurer le projet scanné pour que l’analyse soit envoyée à SonarCloud, en renseignant le bon projet, la bonne compagnie et le bon token d’authentification (il faut que l’utilisateur ait le droit de lancer une analyse).<br /> <br /> = Configuration =<br /> Afin que le runner nouvellement installé bénéficie simplement de la configuration décidée en amont, cette configuration est faite pour le projet, dans le fichier &lt;code&gt;sonar-project.properties&lt;/code&gt; dans le dossier racine du projet. Ce fichier spécifie la configuration utilisée par le scanner pour l’analyse du projet.&lt;br&gt;<br /> Comme expliqué dans la page dédiée à [[GitLab CI/CD]], le fichier &lt;code&gt;.gitlab-ci.yml&lt;/code&gt; définit le comportement du pipeline. Ici, il nous est donc utile à télécharger, installer et utiliser le scanner.&lt;br&gt;<br /> Le fichier &lt;code&gt;sonar-project.properties&lt;/code&gt; définit les variables de configuration utilisées par le scanner.<br /> <br /> == .gitlab-ci.yml ==<br /> &lt;span style=&quot;color:red&quot;&gt;/!\&lt;/span&gt; Ce fichier est un &lt;code&gt;.yml&lt;/code&gt;, l’identation (avec des espaces et non des tabulations) est '''importante'''.&lt;br&gt;<br /> Le script sonar-analysis télécharge d'abord une archive de scanner (ici, la version '3.3.0.1492'), puis l'extrait (au cas où le scanner ne puisse utiliser unzip, un fichier python est défini pour extraire l'archive). Après avoir donné au runner les droits d'exécution du scanner, l'analyse est lancée.<br /> stages:<br /> - test<br /> <br /> sonar-analysis:<br /> stage: test<br /> script:<br /> - wget &quot;https://binaries.sonarsource.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-3.3.0.1492-linux.zip&quot;<br /> - echo &quot;import zipfile&quot; &gt; unzip.py<br /> - echo &quot;&quot; &gt;&gt; unzip.py<br /> - echo &quot;with zipfile.ZipFile('sonar-scanner-cli-3.3.0.1492-linux.zip', \&quot;r\&quot;) as z:&quot; &gt;&gt; unzip.py<br /> - echo &quot; z.extractall(\&quot;.\&quot;)&quot; &gt;&gt; unzip.py<br /> - python unzip.py<br /> - rm unzip.py<br /> - rm sonar-scanner-cli-3.3.0.1492-linux.zip<br /> - chmod -R +x sonar-scanner-3.3.0.1492-linux/<br /> - sonar-scanner-3.3.0.1492-linux/bin/sonar-scanner<br /> <br /> == sonar-project.properties ==<br /> # sonarqube server<br /> sonar.host.url=https://sonarcloud.io<br /> <br /> # Required metadata<br /> # must be unique in a given SonarQube instance<br /> sonar.projectKey=&lt;project-key&gt;<br /> sonar.organization=&lt;organization&gt;<br /> sonar.login=&lt;authentication-token&gt;<br /> sonar.projectVersion=1.0<br /> <br /> # Optional metadata<br /> # Default: master<br /> # sonar.branch.name=&lt;branch-name&gt;<br /> <br /> # Comma-separated paths to directories with sources (required)<br /> # Path is relative to the sonar-project.properties file. Replace &quot;\&quot; by &quot;/&quot; on Windows.<br /> # This property is optional if sonar.modules is set.<br /> sonar.sources=.<br /> sonar.exclusions=sonar-scanner-3.3.0.1492-linux/**,&lt;paths-to-exclude-from-scan&gt;<br /> <br /> # Language<br /> #sonar.language=javascript<br /> sonar.c.file.suffixes=-<br /> sonar.cpp.file.suffixes=-<br /> sonar.objc.file.suffixes=-<br /> <br /> # Encoding of the source code. Default is default system encoding<br /> sonar.sourceEncoding=UTF-8<br /> <br /> = Sources =<br /> [https://docs.sonarqube.org/latest/setup/get-started-2-minutes/ https://docs.sonarqube.org/latest/setup/get-started-2-minutes/]&lt;br&gt;<br /> [https://docs.sonarqube.org/latest/analysis/analysis-parameters/ https://docs.sonarqube.org/latest/analysis/analysis-parameters/]&lt;br&gt;<br /> [https://docs.sonarqube.org/latest/project-administration/narrowing-the-focus/ https://docs.sonarqube.org/latest/project-administration/narrowing-the-focus/]</div>

Zoran.Chanet https://air.imag.fr/index.php?title=PROJET-INFO5_1819_EDCampus&diff=44852 2019-02-07T10:26:19Z

<p>Zoran.Chanet: /* Zoran */</p> <hr /> <div>[[File:Logo_EDCampus.png|thumb|right| Logo EDCampus]]<br /> = Le projet en quelques mots =<br /> La plateforme [[Contributions open-source au projet Eclipse EdCampus | EDCampus]] est une plateforme de gestion de projet développé par Disrupt Campus Grenoble. La plateforme est actuellement en train d’être soumis à la fondation Eclipse afin d’être mise en open source sous licence Eclipse. Dans le cadre du projet Disrupt Campus, les étudiants sont invités à contribuer à la plateforme. Dans le cadre de vos formations c’est une vraie plus value de contribuer à de réels projets plutôt qu’à des projets one-shot qui seront mis à la poubelle sitôt votre soutenance terminée. EDCampus est donc une opportunité de contribuer au logiciel libre et à la fondation Eclipse (et de s'assurer une jolie ligne sur son CV plutôt qu'un projet qui sera aussi vite oublié que l'ECOM !). <br /> <br /> = L'équipe et leurs rôles =<br /> <br /> * GEOURJON Anthony - Chef de projet (EXT)<br /> * [[User:Servan.Charlot | CHARLOT Servan]] - Chef de groupe<br /> * [[User:Zoran.Chanet | CHANET Zoran]] - Responsable DevOps<br /> <br /> = Roadmap =<br /> * '''20-22 février 2019 :''' Hack Ton Campus, la plateforme EDCampus sera utilisée pour la gestion des défis.<br /> * '''Avril 2019 :''' Projet pilote, un projet mêlant une entreprise, l'UGA et des étudiants servira de test à la plateforme.<br /> * '''Septembre 2019 :''' Mise en production globale.<br /> <br /> = Carnet de bord =<br /> <br /> == Semaine 1 ==<br /> <br /> === 28/01/19 ===<br /> <br /> Assignation du sujet [[Contributions open-source au projet Eclipse EdCampus | EDCampus]].<br /> <br /> === 29/01/19 ===<br /> <br /> * Rencontre avec Anthony au [http://fabmstic.liglab.fr/ Fablab], presentation du sujet, des enjeux, et de la roadmap<br /> * Installation du projet<br /> ** Difficultés dues au DNS des réseaux universitaires (impossible de télécharger le contenu nécessaire depuis les containers)<br /> <br /> === 30/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $scope._getProjectParent()&lt;/code&gt; qui ne marchait pas du tout. Il y avait une faute dans la plupart des variables qui s'appelaient &lt;code&gt;currentParentProject&lt;/code&gt; au lieu de &lt;code&gt;currentProjectParent&lt;/code&gt;.<br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $rootScope._checkProject()&lt;/code&gt; qui oubliait un paramètre dans son appel à &lt;code&gt;$scope._setProject()&lt;/code&gt;.<br /> <br /> ==== Zoran ====<br /> * Assignation d'une première tâche : réparer la création d'un projet indépendant<br /> * Découverte du code du projet<br /> * Poursuite de l'arborescence des appels depuis le bouton jusqu'à l'appel à la base de données<br /> <br /> === 01/02/19 ===<br /> ==== Servan ====<br /> <br /> * Assignation de la tâche consistant à réparer le système de fichier.<br /> * Exploration du systeme de fichier et son implementation.<br /> <br /> ==== Zoran ====<br /> * Production d'une méthode permettant des logs personnalisés<br /> * Recherches sur le rewriting d'URL<br /> * Correction du problème (lié au rewriting)<br /> * Production d'une fiche explicative de la solution<br /> <br /> == Semaine 2 ==<br /> <br /> === 04/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction des bugs suivants :<br /> <br /> * Affichage des fichiers du portefeuille père ssi il y a au moins un fichier présent dans le projet fils.<br /> ** Dans le backend, la fonction qui get les fichiers exécutait un &lt;code&gt;return false&lt;/code&gt; avant de get les fichiers parents dans le cas ou il n'y avait pas de fichier à la base.<br /> * N'actualise pas la liste des fichiers si on supprime le dernier fichier.<br /> * Tous les dossiers sont affichés comme des fichiers. Lors de la première sélection à la souris, si on sélectionne le fichier-dossier, il se transforme en dossier et on peut y accéder. Rien ne se passe pour les sélections suivantes.<br /> ** Dans le backend, un paramètre était traité comme chaîne de caractère alors qu'il représentait un booléen. Le résultat de ça est que l'on entrait dans la mauvaise partie d'un if, qui exécutait la mauvaise requête SQL nous privant de l'information concernant le type de fichier lu (un dossier est un type de fichier).<br /> * Le bouton qui permet de revenir en arrière, sortir du dossier ne fonctionne pas.<br /> * On ne peut pas entrer dans un dossier hérité.<br /> <br /> ==== Zoran ====<br /> * Assignation de la mise en place de techniques DevOps<br /> * Recherches sur la mise en place de pipeline dans GitLab : voir [[GitLab CI/CD | compte-rendu]]<br /> * Mise en place d'un pipeline à chaque push<br /> * Production d'un tutoriel de création de runner GitLab : voir [[GitLab Runners | tutoriel]]<br /> * Recherches sur SonarQube et les tests unitaires<br /> ** Priorisation de SonarQube<br /> <br /> === 05/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug qui faisait que lors de la suppression d'un dossier, les fichiers à l'intérieur ne sont pas supprimés (le champ statut dans le BDD ne passe pas à 0).<br /> ** La fonctionnalité de suppression récursive n'était pas implémentée dans &lt;code&gt;File.php&lt;/code&gt;.<br /> * Début de l'analyse du système de droit des utilisateurs (Administrateur/Tuteur/Elève) sur les fichiers et dossiers (hérités ou non).<br /> <br /> ==== Zoran ====<br /> * Compréhension des scanners sonar : voir [[SonarQube Scanner | compte-rendu]]<br /> * Mise en place d'un scan dans le pipeline<br /> ** Nécessité d'un serveur sonar exposé<br /> ** Décision d'utiliser SonarCloud<br /> ** Configuration du scanner pour envoyer le rapport dans le bon projet sonarcloud<br /> ** Réussite du premier scan<br /> <br /> === 06/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Suite de la correction du système de droits des fichiers/dossiers.<br /> <br /> * Correction d'un bug qui faisait que les utilisateurs ne peuvent pas entrer dans les dossiers hérites (ou télécharger les fichiers hérites).<br /> ** Le check de droit se fait dans une fonction qui check d'abord le &lt;code&gt;ownerId&lt;/code&gt;, puis le &lt;code&gt;projectId&lt;/code&gt; et puis enfin si le fichier appartient à un parent. Pour cela elle fait appel à la base pour récupérer la relation d’héritage. IL y avait une erreur de comparaison entre le résultat de la requête et les information fichier (erreur de type parce que PHP).<br /> * Analyse complète du système de droit création d'un tableau explicatif de l'état actuel et l'état voulu.<br /> [[File:EDCampus_2019_Tableau_de_droits.png|center]]<br /> * Suite au tableau, mise en place de la protection des fichiers hérités.<br /> ** Ajout d'une vérification sur le &lt;code&gt;projectId&lt;/code&gt;, empêchant les utilisateurs non propriétaires du fichier de le supprimer, renommer ou déplacer.<br /> <br /> ==== Zoran ====<br /> * Extension du scan sonar dans le pipeline à toutes les sections du projet<br /> * Affichage de badges d'état du pipeline sur la page de présentation de chaque section du projet<br /> * Reprise des recherches concernant les tests unitaires<br /> * Tentative de systématisation des tests dans le pipeline<br /> ** Difficulté : les tests nécessitent des fichiers de configurations qui ne sont pas présents sur le repository git<br /> * Recherche de contournement pour ne pas exposer des configurations privées dans le projet public<br /> <br /> === 08/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====</div>

Zoran.Chanet https://air.imag.fr/index.php?title=SonarQube_Scanner&diff=44851 2019-02-07T10:26:08Z

<p>Zoran.Chanet: Created page with &quot;= Auteur = CHANET Zoran = Introduction = Cette page explique rapidement le fonctionnement des scanners SonarQube, et en explique la configuration afin...&quot;</p> <hr /> <div>= Auteur =<br /> [[User:Zoran.Chanet | CHANET Zoran]]<br /> <br /> = Introduction =<br /> Cette page explique rapidement le fonctionnement des scanners SonarQube, et en explique la configuration afin qu'il analyse un projet au sein d'un pipeline d'intégration continue [[GitLab CI/CD]] et envoie les données récoltées à [https://sonarcloud.io/ SonarCloud]. Il est également possible d'installer un server SonarQube et de configurer le scanner pour qu'il envoie les informations sur ce server (&lt;code&gt;sonar.host.url&lt;/code&gt;). Pour l'installation d'un tel serveur, voir [[SonarQube]].<br /> <br /> = Scanner =<br /> Le scanner est celui qui nous permettra de parcourir les fichiers et de relever les erreurs. Il doit être installé sur la machine qui l’utilise. Dans le cas de l'intégration continue [[GitLab CI/CD]], il doit donc être installé sur le runner qui exécute le job correspondant. Afin d’éviter de devoir contrôler précisément quels runners sont utilisés pour le job, et de devoir synchroniser les installations sur tous les runners du projet, il est possible de télécharger et installer le scanner au début du script dans le fichier &lt;code&gt;.gitlab-ci.yml&lt;/code&gt; qui définit le pipeline.<br /> <br /> = Serveur =<br /> Le scanner se contente d’analyser le code. Pour obtenir le bel affichage auquel nous a habitué [https://www.sonarqube.org/ SonarQube], le résultat de cette analyse doit être envoyé à un serveur. Dans le cas de l'intégration continue [[GitLab CI/CD]], puisque le scan tourne sur le runner, il faut que le serveur soit actif et exposé (si le serveur sonar était installé sur le runner et lancé en local avant le scan, il serait détruit à l’arrêt du runner). Il est possible d'utiliser [https://sonarcloud.io/ SonarCloud], un serveur sonar public et gratuit pour les projets opensource. Il faut alors configurer le projet scanné pour que l’analyse soit envoyée à SonarCloud, en renseignant le bon projet, la bonne compagnie et le bon token d’authentification (il faut que l’utilisateur ait le droit de lancer une analyse).<br /> <br /> = Configuration =<br /> Afin que le runner nouvellement installé bénéficie simplement de la configuration décidée en amont, cette configuration est faite pour le projet, dans le fichier &lt;code&gt;sonar-project.properties&lt;/code&gt; dans le dossier racine du projet. Ce fichier spécifie la configuration utilisée par le scanner pour l’analyse du projet.&lt;br&gt;<br /> Comme expliqué dans la page dédiée à [[GitLab CI/CD]], le fichier &lt;code&gt;.gitlab-ci.yml&lt;/code&gt; définit le comportement du pipeline. Ici, il nous est donc utile à télécharger, installer et utiliser le scanner.&lt;br&gt;<br /> Le fichier &lt;code&gt;sonar-project.properties&lt;/code&gt; définit les variables de configuration utilisées par le scanner.<br /> <br /> == .gitlab-ci.yml ==<br /> &lt;span style=&quot;color:red&quot;&gt;/!\&lt;/span&gt; Ce fichier est un &lt;code&gt;.yml&lt;/code&gt;, l’identation (avec des espaces et non des tabulations) est '''importante'''.&lt;br&gt;<br /> Le script sonar-analysis télécharge d'abord une archive de scanner (ici, la version '3.3.0.1492'), puis l'extrait (au cas où le scanner ne puisse utiliser unzip, un fichier python est défini pour extraire l'archive). Après avoir donné au runner les droits d'exécution du scanner, l'analyse est lancée.<br /> stages:<br /> - test<br /> <br /> sonar-analysis:<br /> stage: test<br /> script:<br /> - wget &quot;https://binaries.sonarsource.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-3.3.0.1492-linux.zip&quot;<br /> - echo &quot;import zipfile&quot; &gt; unzip.py<br /> - echo &quot;&quot; &gt;&gt; unzip.py<br /> - echo &quot;with zipfile.ZipFile('sonar-scanner-cli-3.3.0.1492-linux.zip', \&quot;r\&quot;) as z:&quot; &gt;&gt; unzip.py<br /> - echo &quot; z.extractall(\&quot;.\&quot;)&quot; &gt;&gt; unzip.py<br /> - python unzip.py<br /> - rm unzip.py<br /> - rm sonar-scanner-cli-3.3.0.1492-linux.zip<br /> - chmod -R +x sonar-scanner-3.3.0.1492-linux/<br /> - sonar-scanner-3.3.0.1492-linux/bin/sonar-scanner<br /> <br /> == sonar-project.properties ==<br /> # sonarqube server<br /> sonar.host.url=https://sonarcloud.io<br /> <br /> # Required metadata<br /> # must be unique in a given SonarQube instance<br /> sonar.projectKey=&lt;project-key&gt;<br /> sonar.organization=&lt;organization&gt;<br /> <br /> sonar.login=&lt;authentication-token&gt;<br /> sonar.projectVersion=1.0<br /> <br /> # Comma-separated paths to directories with sources (required)<br /> # Path is relative to the sonar-project.properties file. Replace &quot;\&quot; by &quot;/&quot; on Windows.<br /> # This property is optional if sonar.modules is set.<br /> sonar.sources=.<br /> sonar.exclusions=sonar-scanner-3.3.0.1492-linux/**,&lt;paths-to-exclude-from-scan&gt;<br /> <br /> # Language<br /> #sonar.language=javascript<br /> sonar.c.file.suffixes=-<br /> sonar.cpp.file.suffixes=-<br /> sonar.objc.file.suffixes=-<br /> <br /> # Encoding of the source code. Default is default system encoding<br /> sonar.sourceEncoding=UTF-8<br /> <br /> = Sources =<br /> [https://docs.sonarqube.org/latest/setup/get-started-2-minutes/ https://docs.sonarqube.org/latest/setup/get-started-2-minutes/]&lt;br&gt;<br /> [https://docs.sonarqube.org/latest/analysis/analysis-parameters/ https://docs.sonarqube.org/latest/analysis/analysis-parameters/]&lt;br&gt;<br /> [https://docs.sonarqube.org/latest/project-administration/narrowing-the-focus/ https://docs.sonarqube.org/latest/project-administration/narrowing-the-focus/]</div>

Zoran.Chanet https://air.imag.fr/index.php?title=GitLab_Runners&diff=44850 2019-02-07T09:49:21Z

<p>Zoran.Chanet: /* Introduction */</p> <hr /> <div>= Auteur =<br /> [[User:Zoran.Chanet | CHANET Zoran]]<br /> <br /> = Introduction =<br /> Cette page de tutoriel explique comment installer simplement sur linux un runner utilisable pour un projet hébergé sur un serveur GitLab. Ces runners sont utilisés dans le cadre de [[GitLab CI/CD | l'intégration continue sur GitLab]]. Bien entendu, il existe de nombreuses configurations différentes et même plusieurs types de runners. Ici, nous viserons l'installation la plus simple, c'est à dire un runner spécifique éxécuté par shell, donc avec les caractéristiques de la machine sur laquelle le runner est installé. Pour d'autres configurations, n'hésitez pas à parcourir [[GitLab Runners#Sources | les sources]].&lt;br&gt;<br /> La documentation du runner officiel de GitLab se trouve ici : [https://docs.gitlab.com/runner/ https://docs.gitlab.com/runner/].<br /> <br /> = Installation =<br /> # Linux x86-64<br /> sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64<br /> <br /> '''OU'''<br /> <br /> # Linux x86<br /> sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-386<br /> <br /> '''OU'''<br /> <br /> # Linux arm<br /> sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-arm<br /> <br /> '''PUIS'''<br /> <br /> sudo chmod +x /usr/local/bin/gitlab-runner<br /> sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash<br /> sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner<br /> sudo gitlab-runner start<br /> <br /> = Configuration =<br /> <br /> sudo gitlab-runner register<br /> L'URL et le token à spécifier pour configurer le runner se trouvent dans les options du projet GitLab sous &lt;code&gt;Settings -&gt; CI/CD -&gt; Runners&lt;/code&gt;, dans la section ''Set up a specific Runner manually''<br /> <br /> = Astuces =<br /> * Afficher les runners existants : sudo gitlab-runner list<br /> * Afficher l’état des runners : sudo gitlab-runner verify<br /> * Supprimer les runners retirés de GitLab : sudo gitlab-runner verify --delete<br /> * Retirer un runner :<br /> ** par url &amp; token : gitlab-runner unregister --url &lt;url&gt; --token &lt;token&gt;<br /> ** par nom (le premier du nom sera retiré) : gitlab-runner unregister --name &lt;name&gt;<br /> ** tous : gitlab-runner unregister --all-runners<br /> <br /> = Sources =<br /> [https://gricad-gitlab.univ-grenoble-alpes.fr/help/ci/runners/README.md Configurer un runner]&lt;br&gt;<br /> [https://gricad-gitlab.univ-grenoble-alpes.fr/help/ci/quick_start/README#configuring-a-runner Configurer les runners du projet]&lt;br&gt;<br /> [https://docs.gitlab.com/runner/ Documentation du runner GitLab]&lt;br&gt;<br /> [https://docs.gitlab.com/runner/install/ Installation du runner GitLab]&lt;br&gt;<br /> [https://docs.gitlab.com/runner/install/linux-manually.html Installation du runner sous Linux]&lt;br&gt;<br /> [https://docs.gitlab.com/runner/executors/ Explication des executeurs]&lt;br&gt;</div>

Zoran.Chanet https://air.imag.fr/index.php?title=GitLab_CI/CD&diff=44849 2019-02-07T09:48:05Z

<p>Zoran.Chanet: </p> <hr /> <div>= Auteur =<br /> [[User:Zoran.Chanet | CHANET Zoran]]<br /> <br /> = Prérequis =<br /> * Version Gitlab &gt;= 8.0 ou utiliser GitLab.com<br /> * &lt;code&gt;Settings -&gt; General -&gt; Permissions -&gt; Pipelines&lt;/code&gt; (''Only team members'' ou ''Everyone with access'')<br /> * Au moins un runner configuré pour le projet (ou shared runner) (voir &lt;code&gt;Settings -&gt; CI/CD -&gt; Runners&lt;/code&gt;) (''Enable shared runners on this project'' pour avoir accès aux shared runners)<br /> <br /> = Activation =<br /> Définir un fichier &lt;code&gt;.gitlab-ci.yml&lt;/code&gt; valide à la racine du projet<br /> <br /> = Runners =<br /> * Sont des VM isolées<br /> * Peuvent être ''shared'' entre les projets<br /> * Idéalement sur une autre machine que le projet GitLab<br /> * Configurés par le fichier &lt;code&gt;.gitlab-ci.yml&lt;/code&gt; pour définir des étapes (build, test, deploy…)<br /> * &lt;code&gt;Settings -&gt; CI/CD -&gt; Runners&lt;/code&gt; (pour voir lesquels sont assignés au projet)<br /> <br /> = Astuces =<br /> * &lt;code&gt;.gitlab-ci.yml&lt;/code&gt; est dépendant de la version (donc branche)<br /> * Format du fichier &lt;code&gt;.gitlab-ci.yml&lt;/code&gt; :<br /> stages:<br /> - &lt;étape&gt;<br /> - &lt;étape&gt;<br /> - ...<br /> <br /> before_script:<br /> - &lt;commande&gt;<br /> - &lt;commande&gt;<br /> - … <br /> <br /> &lt;job1-name&gt;:<br /> stage: &lt;étape&gt;<br /> script:<br /> - &lt;commande&gt;<br /> - &lt;commande&gt;<br /> - …<br /> <br /> &lt;job2-name&gt;:<br /> stage: &lt;étape&gt;<br /> script:<br /> - &lt;commande&gt;<br /> - &lt;commande&gt;<br /> - …<br /> <br /> …<br /> * &lt;span style=&quot;color:red&quot;&gt;/!\&lt;/span&gt; Les espaces doivent rester des espaces (pas des tabulations)<br /> * &lt;span style=&quot;color:red&quot;&gt;/!\&lt;/span&gt; &lt;code&gt;script&lt;/code&gt; est un mot-clé obligatoire pour chaque job<br /> * &lt;code&gt;before_script&lt;/code&gt; est optionnel et exécuté avant chaque &lt;code&gt;script&lt;/code&gt;<br /> * Les balises &lt;code&gt;stages&lt;/code&gt; et &lt;code&gt;stage&lt;/code&gt; sont optionnelles mais structurent le pipeline<br /> * &lt;code&gt;CI/CD -&gt; Pipelines -&gt; CI LINT&lt;/code&gt; (bouton) permet de tester la validité du fichier &lt;code&gt;.gitlab-ci.yml&lt;/code&gt;<br /> * ''stuck'' signifie qu’aucun runner n’est configuré pour prendre en charge le job<br /> * Examples de &lt;code&gt;.gitlab_ci.yml&lt;/code&gt; : [https://gricad-gitlab.univ-grenoble-alpes.fr/help/ci/examples/README.md https://gricad-gitlab.univ-grenoble-alpes.fr/help/ci/examples/README.md]<br /> <br /> <br /> = Fonctionnement =<br /> * Activation du pipeline à chaque push sur une branche disposant du fichier &lt;code&gt;.gitlab-ci.yml&lt;/code&gt;<br /> * Au lancement, chaque job est réalisé par un runner dans son propre environnement<br /> <br /> = Sources =<br /> [https://gricad-gitlab.univ-grenoble-alpes.fr/help/ci/quick_start/README Getting started with GitLab CI/CD]&lt;br&gt;<br /> [https://gricad-gitlab.univ-grenoble-alpes.fr/help/ci/enable_or_disable_ci.md How to enable or disable GitLab CI/CD]</div>

Zoran.Chanet https://air.imag.fr/index.php?title=PROJET-INFO5_1819_EDCampus&diff=44848 2019-02-07T09:36:34Z

<p>Zoran.Chanet: /* Zoran */</p> <hr /> <div>[[File:Logo_EDCampus.png|thumb|right| Logo EDCampus]]<br /> = Le projet en quelques mots =<br /> La plateforme [[Contributions open-source au projet Eclipse EdCampus | EDCampus]] est une plateforme de gestion de projet développé par Disrupt Campus Grenoble. La plateforme est actuellement en train d’être soumis à la fondation Eclipse afin d’être mise en open source sous licence Eclipse. Dans le cadre du projet Disrupt Campus, les étudiants sont invités à contribuer à la plateforme. Dans le cadre de vos formations c’est une vraie plus value de contribuer à de réels projets plutôt qu’à des projets one-shot qui seront mis à la poubelle sitôt votre soutenance terminée. EDCampus est donc une opportunité de contribuer au logiciel libre et à la fondation Eclipse (et de s'assurer une jolie ligne sur son CV plutôt qu'un projet qui sera aussi vite oublié que l'ECOM !). <br /> <br /> = L'équipe et leurs rôles =<br /> <br /> * GEOURJON Anthony - Chef de projet (EXT)<br /> * [[User:Servan.Charlot | CHARLOT Servan]] - Chef de groupe<br /> * [[User:Zoran.Chanet | CHANET Zoran]] - Responsable DevOps<br /> <br /> = Roadmap =<br /> * '''20-22 février 2019 :''' Hack Ton Campus, la plateforme EDCampus sera utilisée pour la gestion des défis.<br /> * '''Avril 2019 :''' Projet pilote, un projet mêlant une entreprise, l'UGA et des étudiants servira de test à la plateforme.<br /> * '''Septembre 2019 :''' Mise en production globale.<br /> <br /> = Carnet de bord =<br /> <br /> == Semaine 1 ==<br /> <br /> === 28/01/19 ===<br /> <br /> Assignation du sujet [[Contributions open-source au projet Eclipse EdCampus | EDCampus]].<br /> <br /> === 29/01/19 ===<br /> <br /> * Rencontre avec Anthony au [http://fabmstic.liglab.fr/ Fablab], presentation du sujet, des enjeux, et de la roadmap<br /> * Installation du projet<br /> ** Difficultés dues au DNS des réseaux universitaires (impossible de télécharger le contenu nécessaire depuis les containers)<br /> <br /> === 30/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $scope._getProjectParent()&lt;/code&gt; qui ne marchait pas du tout. Il y avait une faute dans la plupart des variables qui s'appelaient &lt;code&gt;currentParentProject&lt;/code&gt; au lieu de &lt;code&gt;currentProjectParent&lt;/code&gt;.<br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $rootScope._checkProject()&lt;/code&gt; qui oubliait un paramètre dans son appel à &lt;code&gt;$scope._setProject()&lt;/code&gt;.<br /> <br /> ==== Zoran ====<br /> * Assignation d'une première tâche : réparer la création d'un projet indépendant<br /> * Découverte du code du projet<br /> * Poursuite de l'arborescence des appels depuis le bouton jusqu'à l'appel à la base de données<br /> <br /> === 01/02/19 ===<br /> ==== Servan ====<br /> <br /> * Assignation de la tâche consistant à réparer le système de fichier.<br /> * Exploration du systeme de fichier et son implementation.<br /> <br /> ==== Zoran ====<br /> * Production d'une méthode permettant des logs personnalisés<br /> * Recherches sur le rewriting d'URL<br /> * Correction du problème (lié au rewriting)<br /> * Production d'une fiche explicative de la solution<br /> <br /> == Semaine 2 ==<br /> <br /> === 04/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction des bugs suivants :<br /> <br /> * Affichage des fichiers du portefeuille père ssi il y a au moins un fichier présent dans le projet fils.<br /> ** Dans le backend, la fonction qui get les fichiers exécutait un &lt;code&gt;return false&lt;/code&gt; avant de get les fichiers parents dans le cas ou il n'y avait pas de fichier à la base.<br /> * N'actualise pas la liste des fichiers si on supprime le dernier fichier.<br /> * Tous les dossiers sont affichés comme des fichiers. Lors de la première sélection à la souris, si on sélectionne le fichier-dossier, il se transforme en dossier et on peut y accéder. Rien ne se passe pour les sélections suivantes.<br /> ** Dans le backend, un paramètre était traité comme chaîne de caractère alors qu'il représentait un booléen. Le résultat de ça est que l'on entrait dans la mauvaise partie d'un if, qui exécutait la mauvaise requête SQL nous privant de l'information concernant le type de fichier lu (un dossier est un type de fichier).<br /> * Le bouton qui permet de revenir en arrière, sortir du dossier ne fonctionne pas.<br /> * On ne peut pas entrer dans un dossier hérité.<br /> <br /> ==== Zoran ====<br /> * Assignation de la mise en place de techniques DevOps<br /> * Recherches sur la mise en place de pipeline dans GitLab : voir [[GitLab CI/CD | compte-rendu]]<br /> * Mise en place d'un pipeline à chaque push<br /> * Production d'un tutoriel de création de runner GitLab : voir [[GitLab Runners | tutoriel]]<br /> * Recherches sur SonarQube et les tests unitaires<br /> ** Priorisation de SonarQube<br /> <br /> === 05/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug qui faisait que lors de la suppression d'un dossier, les fichiers à l'intérieur ne sont pas supprimés (le champ statut dans le BDD ne passe pas à 0).<br /> ** La fonctionnalité de suppression récursive n'était pas implémentée dans &lt;code&gt;File.php&lt;/code&gt;.<br /> * Début de l'analyse du système de droit des utilisateurs (Administrateur/Tuteur/Elève) sur les fichiers et dossiers (hérités ou non).<br /> <br /> ==== Zoran ====<br /> * Compréhension des scanners sonar<br /> * Mise en place d'un scan dans le pipeline<br /> ** Nécessité d'un serveur sonar exposé<br /> ** Décision d'utiliser SonarCloud<br /> ** Configuration du scanner pour envoyer le rapport dans le bon projet sonarcloud<br /> ** Réussite du premier scan<br /> <br /> === 06/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Suite de la correction du système de droits des fichiers/dossiers.<br /> <br /> * Correction d'un bug qui faisait que les utilisateurs ne peuvent pas entrer dans les dossiers hérites (ou télécharger les fichiers hérites).<br /> ** Le check de droit se fait dans une fonction qui check d'abord le &lt;code&gt;ownerId&lt;/code&gt;, puis le &lt;code&gt;projectId&lt;/code&gt; et puis enfin si le fichier appartient à un parent. Pour cela elle fait appel à la base pour récupérer la relation d’héritage. IL y avait une erreur de comparaison entre le résultat de la requête et les information fichier (erreur de type parce que PHP).<br /> * Analyse complète du système de droit création d'un tableau explicatif de l'état actuel et l'état voulu.<br /> [[File:EDCampus_2019_Tableau_de_droits.png|center]]<br /> * Suite au tableau, mise en place de la protection des fichiers hérités.<br /> ** Ajout d'une vérification sur le &lt;code&gt;projectId&lt;/code&gt;, empêchant les utilisateurs non propriétaires du fichier de le supprimer, renommer ou déplacer.<br /> <br /> ==== Zoran ====<br /> * Extension du scan sonar dans le pipeline à toutes les sections du projet<br /> * Affichage de badges d'état du pipeline sur la page de présentation de chaque section du projet<br /> * Reprise des recherches concernant les tests unitaires<br /> * Tentative de systématisation des tests dans le pipeline<br /> ** Difficulté : les tests nécessitent des fichiers de configurations qui ne sont pas présents sur le repository git<br /> * Recherche de contournement pour ne pas exposer des configurations privées dans le projet public<br /> <br /> === 08/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====</div>

Zoran.Chanet https://air.imag.fr/index.php?title=GitLab_Runners&diff=44847 2019-02-07T09:36:23Z

<p>Zoran.Chanet: Created page with &quot;= Auteur = CHANET Zoran = Introduction = Cette page de tutoriel explique comment installer simplement sur linux un runner utilisable pour un projet h...&quot;</p> <hr /> <div>= Auteur =<br /> [[User:Zoran.Chanet | CHANET Zoran]]<br /> <br /> = Introduction =<br /> Cette page de tutoriel explique comment installer simplement sur linux un runner utilisable pour un projet hébergé sur un serveur GitLab. Ces runners sont utilisés dans le cadre de [[GitLab CI/CD | l'intégration continue sur GitLab]]. Bien entendu, il existe de nombreuses configurations différentes et même plusieurs types de runners. Ici, nous viserons l'installation la plus simple, c'est à dire un runner spécifique éxécuté par shell, donc avec les caractéristiques de la machine sur laquelle le runner est installé. Pour d'autres configurations, n'hésitez pas à parcourir les sources.&lt;br&gt;<br /> La documentation du runner officiel de GitLab se trouve ici : [https://docs.gitlab.com/runner/ https://docs.gitlab.com/runner/].<br /> <br /> = Installation =<br /> # Linux x86-64<br /> sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64<br /> <br /> '''OU'''<br /> <br /> # Linux x86<br /> sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-386<br /> <br /> '''OU'''<br /> <br /> # Linux arm<br /> sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-arm<br /> <br /> '''PUIS'''<br /> <br /> sudo chmod +x /usr/local/bin/gitlab-runner<br /> sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash<br /> sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner<br /> sudo gitlab-runner start<br /> <br /> = Configuration =<br /> <br /> sudo gitlab-runner register<br /> L'URL et le token à spécifier pour configurer le runner se trouvent dans les options du projet GitLab sous &lt;code&gt;Settings -&gt; CI/CD -&gt; Runners&lt;/code&gt;, dans la section ''Set up a specific Runner manually''<br /> <br /> = Astuces =<br /> * Afficher les runners existants : sudo gitlab-runner list<br /> * Afficher l’état des runners : sudo gitlab-runner verify<br /> * Supprimer les runners retirés de GitLab : sudo gitlab-runner verify --delete<br /> * Retirer un runner :<br /> ** par url &amp; token : gitlab-runner unregister --url &lt;url&gt; --token &lt;token&gt;<br /> ** par nom (le premier du nom sera retiré) : gitlab-runner unregister --name &lt;name&gt;<br /> ** tous : gitlab-runner unregister --all-runners<br /> <br /> = Sources =<br /> [https://gricad-gitlab.univ-grenoble-alpes.fr/help/ci/runners/README.md Configurer un runner]&lt;br&gt;<br /> [https://gricad-gitlab.univ-grenoble-alpes.fr/help/ci/quick_start/README#configuring-a-runner Configurer les runners du projet]&lt;br&gt;<br /> [https://docs.gitlab.com/runner/ Documentation du runner GitLab]&lt;br&gt;<br /> [https://docs.gitlab.com/runner/install/ Installation du runner GitLab]&lt;br&gt;<br /> [https://docs.gitlab.com/runner/install/linux-manually.html Installation du runner sous Linux]&lt;br&gt;<br /> [https://docs.gitlab.com/runner/executors/ Explication des executeurs]&lt;br&gt;</div>

Zoran.Chanet https://air.imag.fr/index.php?title=PROJET-INFO5_1819_EDCampus&diff=44846 2019-02-07T09:11:31Z

<p>Zoran.Chanet: /* Semaine 2 */</p> <hr /> <div>[[File:Logo_EDCampus.png|thumb|right| Logo EDCampus]]<br /> = Le projet en quelques mots =<br /> La plateforme [[Contributions open-source au projet Eclipse EdCampus | EDCampus]] est une plateforme de gestion de projet développé par Disrupt Campus Grenoble. La plateforme est actuellement en train d’être soumis à la fondation Eclipse afin d’être mise en open source sous licence Eclipse. Dans le cadre du projet Disrupt Campus, les étudiants sont invités à contribuer à la plateforme. Dans le cadre de vos formations c’est une vraie plus value de contribuer à de réels projets plutôt qu’à des projets one-shot qui seront mis à la poubelle sitôt votre soutenance terminée. EDCampus est donc une opportunité de contribuer au logiciel libre et à la fondation Eclipse (et de s'assurer une jolie ligne sur son CV plutôt qu'un projet qui sera aussi vite oublié que l'ECOM !). <br /> <br /> = L'équipe et leurs rôles =<br /> <br /> * GEOURJON Anthony - Chef de projet (EXT)<br /> * [[User:Servan.Charlot | CHARLOT Servan]] - Chef de groupe<br /> * [[User:Zoran.Chanet | CHANET Zoran]] - Responsable DevOps<br /> <br /> = Roadmap =<br /> * '''20-22 février 2019 :''' Hack Ton Campus, la plateforme EDCampus sera utilisée pour la gestion des défis.<br /> * '''Avril 2019 :''' Projet pilote, un projet mêlant une entreprise, l'UGA et des étudiants servira de test à la plateforme.<br /> * '''Septembre 2019 :''' Mise en production globale.<br /> <br /> = Carnet de bord =<br /> <br /> == Semaine 1 ==<br /> <br /> === 28/01/19 ===<br /> <br /> Assignation du sujet [[Contributions open-source au projet Eclipse EdCampus | EDCampus]].<br /> <br /> === 29/01/19 ===<br /> <br /> * Rencontre avec Anthony au [http://fabmstic.liglab.fr/ Fablab], presentation du sujet, des enjeux, et de la roadmap<br /> * Installation du projet<br /> ** Difficultés dues au DNS des réseaux universitaires (impossible de télécharger le contenu nécessaire depuis les containers)<br /> <br /> === 30/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $scope._getProjectParent()&lt;/code&gt; qui ne marchait pas du tout. Il y avait une faute dans la plupart des variables qui s'appelaient &lt;code&gt;currentParentProject&lt;/code&gt; au lieu de &lt;code&gt;currentProjectParent&lt;/code&gt;.<br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $rootScope._checkProject()&lt;/code&gt; qui oubliait un paramètre dans son appel à &lt;code&gt;$scope._setProject()&lt;/code&gt;.<br /> <br /> ==== Zoran ====<br /> * Assignation d'une première tâche : réparer la création d'un projet indépendant<br /> * Découverte du code du projet<br /> * Poursuite de l'arborescence des appels depuis le bouton jusqu'à l'appel à la base de données<br /> <br /> === 01/02/19 ===<br /> ==== Servan ====<br /> <br /> * Assignation de la tâche consistant à réparer le système de fichier.<br /> * Exploration du systeme de fichier et son implementation.<br /> <br /> ==== Zoran ====<br /> * Production d'une méthode permettant des logs personnalisés<br /> * Recherches sur le rewriting d'URL<br /> * Correction du problème (lié au rewriting)<br /> * Production d'une fiche explicative de la solution<br /> <br /> == Semaine 2 ==<br /> <br /> === 04/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction des bugs suivants :<br /> <br /> * Affichage des fichiers du portefeuille père ssi il y a au moins un fichier présent dans le projet fils.<br /> ** Dans le backend, la fonction qui get les fichiers exécutait un &lt;code&gt;return false&lt;/code&gt; avant de get les fichiers parents dans le cas ou il n'y avait pas de fichier à la base.<br /> * N'actualise pas la liste des fichiers si on supprime le dernier fichier.<br /> * Tous les dossiers sont affichés comme des fichiers. Lors de la première sélection à la souris, si on sélectionne le fichier-dossier, il se transforme en dossier et on peut y accéder. Rien ne se passe pour les sélections suivantes.<br /> ** Dans le backend, un paramètre était traité comme chaîne de caractère alors qu'il représentait un booléen. Le résultat de ça est que l'on entrait dans la mauvaise partie d'un if, qui exécutait la mauvaise requête SQL nous privant de l'information concernant le type de fichier lu (un dossier est un type de fichier).<br /> * Le bouton qui permet de revenir en arrière, sortir du dossier ne fonctionne pas.<br /> * On ne peut pas entrer dans un dossier hérité.<br /> <br /> ==== Zoran ====<br /> * Assignation de la mise en place de techniques DevOps<br /> * Recherches sur la mise en place de pipeline dans GitLab : voir [[GitLab CI/CD | compte-rendu]]<br /> * Mise en place d'un pipeline à chaque push<br /> * Production d'un tutoriel de création de runner GitLab<br /> * Recherches sur SonarQube et les tests unitaires<br /> ** Priorisation de SonarQube<br /> <br /> === 05/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug qui faisait que lors de la suppression d'un dossier, les fichiers à l'intérieur ne sont pas supprimés (le champ statut dans le BDD ne passe pas à 0).<br /> ** La fonctionnalité de suppression récursive n'était pas implémentée dans &lt;code&gt;File.php&lt;/code&gt;.<br /> * Début de l'analyse du système de droit des utilisateurs (Administrateur/Tuteur/Elève) sur les fichiers et dossiers (hérités ou non).<br /> <br /> ==== Zoran ====<br /> * Compréhension des scanners sonar<br /> * Mise en place d'un scan dans le pipeline<br /> ** Nécessité d'un serveur sonar exposé<br /> ** Décision d'utiliser SonarCloud<br /> ** Configuration du scanner pour envoyer le rapport dans le bon projet sonarcloud<br /> ** Réussite du premier scan<br /> <br /> === 06/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Suite de la correction du système de droits des fichiers/dossiers.<br /> <br /> * Correction d'un bug qui faisait que les utilisateurs ne peuvent pas entrer dans les dossiers hérites (ou télécharger les fichiers hérites).<br /> ** Le check de droit se fait dans une fonction qui check d'abord le &lt;code&gt;ownerId&lt;/code&gt;, puis le &lt;code&gt;projectId&lt;/code&gt; et puis enfin si le fichier appartient à un parent. Pour cela elle fait appel à la base pour récupérer la relation d’héritage. IL y avait une erreur de comparaison entre le résultat de la requête et les information fichier (erreur de type parce que PHP).<br /> * Analyse complète du système de droit création d'un tableau explicatif de l'état actuel et l'état voulu.<br /> [[File:EDCampus_2019_Tableau_de_droits.png|center]]<br /> * Suite au tableau, mise en place de la protection des fichiers hérités.<br /> ** Ajout d'une vérification sur le &lt;code&gt;projectId&lt;/code&gt;, empêchant les utilisateurs non propriétaires du fichier de le supprimer, renommer ou déplacer.<br /> <br /> ==== Zoran ====<br /> * Extension du scan sonar dans le pipeline à toutes les sections du projet<br /> * Affichage de badges d'état du pipeline sur la page de présentation de chaque section du projet<br /> * Reprise des recherches concernant les tests unitaires<br /> * Tentative de systématisation des tests dans le pipeline<br /> ** Difficulté : les tests nécessitent des fichiers de configurations qui ne sont pas présents sur le repository git<br /> * Recherche de contournement pour ne pas exposer des configurations privées dans le projet public<br /> <br /> === 08/02/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====</div>

Zoran.Chanet https://air.imag.fr/index.php?title=PROJET-INFO5_1819_EDCampus&diff=44845 2019-02-07T09:05:19Z

<p>Zoran.Chanet: /* L&#039;équipe et leurs rôles */</p> <hr /> <div>[[File:Logo_EDCampus.png|thumb|right| Logo EDCampus]]<br /> = Le projet en quelques mots =<br /> La plateforme [[Contributions open-source au projet Eclipse EdCampus | EDCampus]] est une plateforme de gestion de projet développé par Disrupt Campus Grenoble. La plateforme est actuellement en train d’être soumis à la fondation Eclipse afin d’être mise en open source sous licence Eclipse. Dans le cadre du projet Disrupt Campus, les étudiants sont invités à contribuer à la plateforme. Dans le cadre de vos formations c’est une vraie plus value de contribuer à de réels projets plutôt qu’à des projets one-shot qui seront mis à la poubelle sitôt votre soutenance terminée. EDCampus est donc une opportunité de contribuer au logiciel libre et à la fondation Eclipse (et de s'assurer une jolie ligne sur son CV plutôt qu'un projet qui sera aussi vite oublié que l'ECOM !). <br /> <br /> = L'équipe et leurs rôles =<br /> <br /> * GEOURJON Anthony - Chef de projet (EXT)<br /> * [[User:Servan.Charlot | CHARLOT Servan]] - Chef de groupe<br /> * [[User:Zoran.Chanet | CHANET Zoran]] - Responsable DevOps<br /> <br /> = Roadmap =<br /> * '''20-22 février 2019 :''' Hack Ton Campus, la plateforme EDCampus sera utilisée pour la gestion des défis.<br /> * '''Avril 2019 :''' Projet pilote, un projet mêlant une entreprise, l'UGA et des étudiants servira de test à la plateforme.<br /> * '''Septembre 2019 :''' Mise en production globale.<br /> <br /> = Carnet de bord =<br /> <br /> == Semaine 1 ==<br /> <br /> === 28/01/19 ===<br /> <br /> Assignation du sujet [[Contributions open-source au projet Eclipse EdCampus | EDCampus]].<br /> <br /> === 29/01/19 ===<br /> <br /> * Rencontre avec Anthony au [http://fabmstic.liglab.fr/ Fablab], presentation du sujet, des enjeux, et de la roadmap<br /> * Installation du projet<br /> ** Difficultés dues au DNS des réseaux universitaires (impossible de télécharger le contenu nécessaire depuis les containers)<br /> <br /> === 30/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $scope._getProjectParent()&lt;/code&gt; qui ne marchait pas du tout. Il y avait une faute dans la plupart des variables qui s'appelaient &lt;code&gt;currentParentProject&lt;/code&gt; au lieu de &lt;code&gt;currentProjectParent&lt;/code&gt;.<br /> * Correction de la fonction &lt;code&gt;app/shared/main.js $rootScope._checkProject()&lt;/code&gt; qui oubliait un paramètre dans son appel à &lt;code&gt;$scope._setProject()&lt;/code&gt;.<br /> <br /> ==== Zoran ====<br /> * Assignation d'une première tâche : réparer la création d'un projet indépendant<br /> * Découverte du code du projet<br /> * Poursuite de l'arborescence des appels depuis le bouton jusqu'à l'appel à la base de données<br /> <br /> === 01/02/19 ===<br /> ==== Servan ====<br /> <br /> * Assignation de la tâche consistant à réparer le système de fichier.<br /> * Exploration du systeme de fichier et son implementation.<br /> <br /> ==== Zoran ====<br /> * Production d'une méthode permettant des logs personnalisés<br /> * Recherches sur le rewriting d'URL<br /> * Correction du problème (lié au rewriting)<br /> * Production d'une fiche explicative de la solution<br /> <br /> == Semaine 2 ==<br /> <br /> === 04/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Correction des bugs suivants :<br /> <br /> * Affichage des fichiers du portefeuille père ssi il y a au moins un fichier présent dans le projet fils.<br /> ** Dans le backend, la fonction qui get les fichiers exécutait un &lt;code&gt;return false&lt;/code&gt; avant de get les fichiers parents dans le cas ou il n'y avait pas de fichier à la base.<br /> * N'actualise pas la liste des fichiers si on supprime le dernier fichier.<br /> * Tous les dossiers sont affichés comme des fichiers. Lors de la première sélection à la souris, si on sélectionne le fichier-dossier, il se transforme en dossier et on peut y accéder. Rien ne se passe pour les sélections suivantes.<br /> ** Dans le backend, un paramètre était traité comme chaîne de caractère alors qu'il représentait un booléen. Le résultat de ça est que l'on entrait dans la mauvaise partie d'un if, qui exécutait la mauvaise requête SQL nous privant de l'information concernant le type de fichier lu (un dossier est un type de fichier).<br /> * Le bouton qui permet de revenir en arrière, sortir du dossier ne fonctionne pas.<br /> * On ne peut pas entrer dans un dossier hérité.<br /> <br /> ==== Zoran ====<br /> * Assignation de la mise en place de techniques DevOps<br /> * Recherches sur la mise en place de pipeline dans GitLab : voir [[GitLab CI/CD | compte-rendu]]<br /> * Mise en place d'un pipeline à chaque push<br /> * Production d'un tutoriel de création de runner GitLab<br /> * Recherches sur SonarQube et les tests unitaires<br /> ** Priorisation de SonarQube<br /> <br /> === 05/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> * Correction d'un bug qui faisait que lors de la suppression d'un dossier, les fichiers à l'intérieur ne sont pas supprimés (le champ statut dans le BDD ne passe pas à 0).<br /> ** La fonctionnalité de suppression récursive n'était pas implémentée dans &lt;code&gt;File.php&lt;/code&gt;.<br /> * Début de l'analyse du système de droit des utilisateurs (Administrateur/Tuteur/Elève) sur les fichiers et dossiers (hérités ou non).<br /> <br /> ==== Zoran ====<br /> * Compréhension des scanners sonar<br /> * Mise en place d'un scan dans le pipeline<br /> ** Nécessité d'un serveur sonar exposé<br /> ** Décision d'utiliser SonarCloud<br /> ** Configuration du scanner pour envoyer le rapport dans le bon projet sonarcloud<br /> ** Réussite du premier scan<br /> <br /> === 06/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> Suite de la correction du système de droits des fichiers/dossiers.<br /> <br /> * Correction d'un bug qui faisait que les utilisateurs ne peuvent pas entrer dans les dossiers hérites (ou télécharger les fichiers hérites).<br /> ** Le check de droit se fait dans une fonction qui check d'abord le &lt;code&gt;ownerId&lt;/code&gt;, puis le &lt;code&gt;projectId&lt;/code&gt; et puis enfin si le fichier appartient à un parent. Pour cela elle fait appel à la base pour récupérer la relation d’héritage. IL y avait une erreur de comparaison entre le résultat de la requête et les information fichier (erreur de type parce que PHP).<br /> * Analyse complète du système de droit création d'un tableau explicatif de l'état actuel et l'état voulu.<br /> [[File:EDCampus_2019_Tableau_de_droits.png|center]]<br /> * Suite au tableau, mise en place de la protection des fichiers hérités.<br /> ** Ajout d'une vérification sur le &lt;code&gt;projectId&lt;/code&gt;, empêchant les utilisateurs non propriétaires du fichier de le supprimer, renommer ou déplacer.<br /> <br /> ==== Zoran ====<br /> * Extension du scan sonar dans le pipeline à toutes les sections du projet<br /> * Affichage de badges d'état du pipeline sur la page de présentation de chaque section du projet<br /> * Reprise des recherches concernant les tests unitaires<br /> * Tentative de systématisation des tests dans le pipeline<br /> ** Difficulté : les tests nécessitent des fichiers de configurations qui ne sont pas présents sur le repository git<br /> * Recherche de contournement pour ne pas exposer des configurations privées dans le projet public<br /> <br /> === 08/01/19 ===<br /> <br /> ==== Servan ====<br /> <br /> ==== Zoran ====</div>

Zoran.Chanet https://air.imag.fr/index.php?title=User:Zoran.Chanet&diff=44844 2019-02-07T09:05:07Z

<p>Zoran.Chanet: /* 2018-2019 */</p> <hr /> <div>= Contact =<br /> Profil LinkedIn : [https://www.linkedin.com/in/zoran-chanet Zoran CHANET]&lt;br&gt;<br /> Profil GitHub : [https://github.com/ProfesseurSid ProfesseurSid]&lt;br&gt;<br /> Profil GitLab : [https://gitlab.com/CHANET_Zoran CHANET_Zoran]&lt;br&gt;<br /> Profil gricad.gitlab : [https://gricad-gitlab.univ-grenoble-alpes.fr/chanetz chanetz]&lt;br&gt;<br /> E-mail : [mailto:zoran.chanet@etu.univ-grenoble-alpes.fr zoran.chanet@etu.univ-grenoble-alpes.fr] (expire en 2020)<br /> <br /> = Projets =<br /> == 2017-2018 ==<br /> [[RICM4 2017 2018 - Nucleo]] <br /> <br /> == 2018-2019 ==<br /> [[VT2018 Thorntail]]&lt;br&gt;<br /> [[ECOM-1F0 1819 BTB]] &lt;br&gt;<br /> [[PROJET-INFO5 1819 EDCampus]]</div>

Zoran.Chanet https://air.imag.fr/index.php?title=ECOM_1F0_2018-19_BTB_Zoran_CHANET&diff=44843 2019-02-07T09:04:02Z

<p>Zoran.Chanet: /* Présentation */</p> <hr /> <div>== Présentation ==<br /> [[User:Zoran.Chanet | CHANET Zoran]], Back-end, lead developer<br /> <br /> Projet : [https://air.imag.fr/index.php/ECOM_1F0_2018-19_BTB Brûle ta bûche !]<br /> <br /> == Journal de bord ==<br /> = Semaine du 25 - Sprint 1 =<br /> * Assignation des rôles<br /> * Choix des technologies utilisées pour le projet (Slack, Trello, Google Drive, GitLab, draw.io)<br /> * Apprentissage des méthodes de modèle des tâches, IHM abstraite, IHM concrète<br /> * Création du Trello<br /> * Création et configuration du serveur Slack<br /> ** Création du lien Trello-Slack (bot Trello dans le serveur Slack)<br /> ** Création du lien GitLab-Slack (notifications GitLab dans le serveur Slack)<br /> * Participation à la définition de l'arbre des tâches<br /> * Participation à la définition de l'IHM abstraite<br /> <br /> = Semaine du 2 =<br /> * Recherches concernant le fonctionnement et l'utilisation de JHipster, principalement son lien avec la génération, la modification et l'utilisation des bases de données<br /> * Ajout d'un résumé des recherche sur la page air globale, création à cet effet de l'espace &quot;Technologies&quot;<br /> * Recherches concernant le filtrage des champ des entités par JPA<br /> * Participation à la réalisation du diaporama pour la soutenance du 09 Octobre<br /> <br /> = Semaine du 9 =<br /> * Soutenance professeurs + clients<br /> * Production et ajout à la fiche JHipster d'un tutoriel d'installation basique par npm<br /> * Production et ajout à la page AIR d'un tutoriel d'installation Maven<br /> * Installation des technologies<br /> * Harmonisation des versions installées au sein de l'équipe<br /> <br /> = Semaine du 16 =<br /> * Génération de l'application monolithique avec JHipster app<br /> ** Choix des technologies utilisées pour la génération<br /> ** Test local de l'application serveur<br /> ** Test local de l'application client<br /> * Pull request de l'application sur le [https://gitlab.com/BruleTaBuche/eCOM/ repository GitLab]<br /> * Réflexion autour des entités nécessaires à la base de données<br /> <br /> = Semaine du 23 =<br /> * Nouvelle génération du projet JHipster<br /> ** Retour à la version par défaut (générée par Jipster) du .gitignore<br /> ** Annulation du choix de JHipster Registry (d'autres groupes ont rapporté des erreurs liées lors du déploiement)<br /> * Conception de la base de données<br /> <br /> = Semaine du 30 - Interruptions pédagogiques =<br /> * Recherches sur le déploiement<br /> <br /> = Semaine du 6 =<br /> * Tentative de déploiement de la base<br /> ** Installation de Docker CE<br /> ** Installation de Docker Compose<br /> ** Production du tutoriel d'installation<br /> ** Tentative (&lt;span style=&quot;color:red&quot;&gt;échouée&lt;/span&gt;) de création de l'image docker<br /> <br /> = Semaine du 12 =<br /> * Poursuite de la tentative de déploiement<br /> * &lt;span style=&quot;color:green&quot;&gt;Réussite&lt;/span&gt; du déploiement de l'image Docker<br /> ** Utilisation du stage release dans le fichier [https://gitlab.com/BruleTaBuche/eCOM/blob/devCI/.gitlab-ci.yml ''.gitlab-ci.yml'']<br /> ** Depuis la branche [https://gitlab.com/BruleTaBuche/eCOM/tree/devCI devCI] (base de données non intégrée)<br /> ** Hébergement dans le [https://gitlab.com/BruleTaBuche/eCOM/container_registry registry GitLab]<br /> * Production d'un tutoriel d'installation des programmes requis (Docker CE, Docker compose) et de déploiement<br /> <br /> = Semaine du 20 - Sprint 2 =<br /> * Tentative de déploiement d'une image depuis la branche [https://gitlab.com/BruleTaBuche/eCOM/tree/integration_JDL Integration_JDL] (base de données intégrée)<br /> ** &lt;span style=&quot;color:red&quot;&gt;De nombreux échecs&lt;/span&gt;<br /> ** De nombreux patchs &quot;à la main&quot; (prise en compte des changelogs liquibase dans le [https://gitlab.com/BruleTaBuche/eCOM/blob/integration_JDL/src/main/resources/config/liquibase/master.xml ''master.xml''], ajout des entités dans [https://gitlab.com/BruleTaBuche/eCOM/blob/integration_JDL/src/main/java/org/fibois38/lbb/config/CacheConfiguration.java ''CacheConfiguration.java'']...)<br /> <br /> = Semaine du 27 =<br /> * Poursuite de la tentative de déploiement<br /> * Mise à jour du modèle de données<br /> ** Village devient Commune<br /> ** De nombreuses suppressions &quot;à la main&quot; pour faire disparaître l'entité indésirable<br /> * &lt;span style=&quot;color:green&quot;&gt;Réussite &lt;strong&gt;partielle&lt;/strong&gt;&lt;/span&gt; du déploiement<br /> ** Certaines entités apparaîssent<br /> ** Certaines entités n'apparaîssent pas<br /> * &lt;span style=&quot;color:green&quot;&gt;Réussite &lt;strong&gt;totale&lt;/strong&gt;&lt;/span&gt; du déploiement<br /> ** Toutes les entités apparaîssent<br /> ** Le lien front-end - back-end est enfin completé<br /> * Merge des branches nécessaires<br /> <br /> = Semaine du 4 =<br /> * Conjointement avec Najwa, définition de l'API selon les demandes du front-end<br /> ** Réalisation des requêtes nécessaires pour le scénario 1<br /> ** Test desdites requêtes<br /> * Merge du front-end et du backend en vue du déploiement<br /> <br /> = Semaine du 11 =<br /> * Conjointement avec Enzo, mise en place des appels à l'API par le front-end<br /> ** Remplacement des appels à la BD mockée par de vrai appels<br /> ** Création si nécessaire des arguments pour requêtes GET<br /> * Dans le même but, ajustement du backend<br /> ** Correction du mapping entité vers DTO pour correspondre aux attentes du front-end<br /> * Participation à la préparation de l'audit final<br /> * Remplissage de la base de données en ligne<br /> * (Re-)Correction du déploiement</div>

Zoran.Chanet