Je pense intéressant de refaire le tour de ces modifications de voir si certaines ne seraient pas directement intégrables dans le portail (de manière optionnelles).
Liste des présents : Christian Cousquer (UPMC), Raymond Bourges (Rennes 1), Vincent Repain (INSA Rennes), Odile Germes (Rennes 1), Arnaud Deman (Aix-Marseille), Mathilde Guerin (La Rochelle), Cyrus Rezvani (UNPIDF), Pascal Rigaux (Paris1), Céline Didier (Lorraine), Julien Gribonvald (RECIA), Anli Abdouroihamane (Paris1), Vincent Bonamy (Rouen), Romain Legrand (Cergy), Yves Deschamps (Lille1), Florent Fareneau (Valenciennes), Guillaume Deudon (Valenciennes), Eric Doual (Lille3), Mathieu HETRU (Lille3), Julien Marchal (Lorraine), Ludovic Auxépaules (UPMC)
Nous avons pour objectif de sortir un package eSup basé sur uPortal 4 pour le mois d'Avril.
Ce package devra faciliter l'utilisation de grouper, shibboleth, des plateformes mobiles.
Il faut que ce package soit utilisable pour l'été si certains établissements souhaitent l'installer pour l'été.
Il a été décidé de découper ce groupe en plusieurs thématiques afin d’avancer en parallèle :
Il a été décidé de faire une visioconférence tous les 15 jours, de préférence les jeudis matin pour une durée d’une heure. Des autres points pourront être faits sur des parties plus spécifiques.
Nous avons un gros travail à faire de ce côté, que ça soit en terme graphique visuel, ergonomique et performances.
Il est impératif de se rapprocher de Jean-Michel Doublet sur cette partie.
Il faudra réaliser des thèmes graphiques (« skin »), pour ce faire :
On peut envisager l’appel à sous-traitance pour les réalisations graphiques.
Bull a fait un excellent travail sur la portlet esup-filemanager (mais s'ils ont un marché sur l'aspect purement graphique et assez sophistiqué ils feront appel à de la sous-traitance). Il semble plus souhaitable de passer par de petite entreprise très compétente en CSS/webDesign. Il faut donc essayer de trouver ces petites entreprises. (Christian C : Alsacreations serait idéal)
Il y a aussi la possibilité de développer ceci en interne (esup).
Christian C. s’est proposé pour, soit suivre cette partie en cas de sous traitance, et/ou soit développer en interne en sachant que quoiqu'il arrive à l'UPMC le développement sera en interne.
Vincent R a quant à lui déjà fait un premier jet de cahier des charges pour des entreprise ça pourrait être une base de travail (Christian C la partie rédaction du CDC, m'intéresse aussi.)
Dans le cas de sous-traitance il a été évoqué de faire plusieurs lots, le premier étant le portail (tout l’enrobage), un second pourrait être les portlets au cas par cas. Il a été aussi évoqué de prévoir des jeux d’icône (plusieurs) qu’on pourrait utiliser a travers nos différentes portlets et un troisième Lot Full Html5 (voir Adaptations XSL)
De même, il faut s’engager à mettre à disposition du prestataire un portail avec un certain nombre de portlet (a définir)
NB: A garder en mémoire dans le cadre mobile chaque portlet doit arriver avec des icônes la symbolisant.
NB: Il faudra aussi travailler sur l’ergonomie (pas abordé pendant la journée) et l’accessibilité (Christian C, cela m'intéresse aussi, je suis expert Accessiweb2) (voir la diffusion du rapport de Témésis ? au prestataire ? - une diffusion au minimum au groupe de travail IHM est la moindre des choses...)
L’utilisation de grouper dans le portail doit être facilitée par esup !
La dernière version de grouper est la 2 à ce jour. Il semble que pour l’instant il y a des problèmes de performances sur cette version. Pour l’instant la portlet esup-esco-grouper ne fonctionne pas sur la version 2 de grouper, il faut donc utiliser l’interface native (d’où une grande perte d’intérêt). Pour l’instant il nous semble judicieux de préconiser encore la version 1.6 de grouper.
Rappel des techniques possible de branchement de grouper avec le portail :
Esco-grouper nous semble indispensable pour utiliser au mieux Grouper !
Fonctionne sur le grouper 1.6 (pas en 2).
Ce développement peut fonctionner en portlet ou en servlet, il est recommandé pour l’instant de l’utiliser en mode servlet (plus souple, moins d’adhérence au portail, de plus il reste des bugs en cours de correction dans la portlet).
Nous nous somme posé la question de savoir si grouper devait être packagé avec le portail. La réponse est non car trop difficile de gérer les montées des versions décalées, on risque d’avoir des performances hasardeuses.
Il faudrait peut-être essayer d’épurer la documentation pour faire un document d’installation plus synthétique, il faudrait repartir du tutoriel pour faire cette documentation.
Nous pourrons essayer de proposer un structure de base pour le groupe portail géré dans grouper. Julien M a émis l’idée de faire un groupe par canal, de donner les droit de vision du canal à ce groupe, et ensuite de gérer l’intérieur du groupe (ce qui veut dire plus de modification des pubchan, plus souple, plus rapide)
Le but est de faciliter l’utilisation de Shibboleth dans cette nouvelle version. Beaucoup d’universités utilisent ou souhaitent utiliser Shibboleth pour répondre à des problématiques d’UNR et des personnalités extérieures aux établissements.
De par le fonctionnement de Shibboleth il faudra surtout faire un effort de documentation. La configuration devra se faire dans le(s) serveur apache en frontal du portail (le packaging n’interviendra pas dans cette partie), mais aussi dans la partie de récupération des attributs.
L’intégration Shibboleth a tout de même une forte conséquence sur le fonctionnement du portail. Avant l’utilisation de CAS permettait d’avoir un fonctionnement proxy CAS : le portail pouvait donc utiliser des services sous-jacents (imap, ftp, …) en propageant l’authentification de la personne. Avec Shibboleth ceci ne fonctionne plus !
Vincent Bonamy a fait une modification dans son UNR pour pallier ce problème :
Nous prendrons comme options de réaliser des documentations en français (déjà disponible en anglais), d’intégrer des exemples de configuration en commentaire dans les fichiers distribués.
Il sera surement intéressant de données une liste d’attribut type (extrait de supann) pour l’utilisation dans le cadre du portail.
NB Question soulevée par Raymond: Comment on fait si on utilise un portail avec grouper et du Shibboleth ? en fait comment attacher des personnes qui ne sont pas dans notre ldap dans des groupes de notre grouper ? Peut être une piste « Grouper external subjects » https://spaces.internet2.edu/display/Grouper/Grouper+external+subjects
Le but est d’étudier les possibilités de migrations de données des versions précédentes de portail.
Il est clair qu’il faut regarder la migration de données des Versions 3.x vers 4 par contre les versions 2.x ne seront étudiées qu’en second temps voire pas étudiées.
Il faudra s’attarder sur la migration des éléments suivants :
Des outils fournis par le JA-SIG sont disponible en version 4, il faudra étudier leur pertinence, leurs limitations et les documenter
L’occasion va être donnée de refondre complétement le packaging esup car celui n’est plus adapté aux technologies actuelles.
Le choix de la gestion de versionning s’oriente fortement vers GIT (il faut prendre contact avec le support SourceSup support-sourcesup@support.renater.fr car il semble qu’on ne peut pas avoir un projet SourceSup qui fait du SVN et du GIT).
Git est déjà utiliser par le JA-SIG.
Le fait de faire ce changement va nous permettre d’incorporer nos modifications/personnalisations directement dans le code JA-SIG (disparition des dossiers update/custom) et via des commande GIT de retrouver ce que nous avons modifié par rapport au JA-SIG, et l’exploitant retrouvera ce qu’il a modifié par rapport à ESUP et au JA-SIG.
Actuellement le package eSup essaye de faire le grand écart, car il conserve un grand nombre d’options (authentification ldap ou pas, utilisation de CAS ou pas, …). Il faut faire des choix par défaut pour simplifier le package et documenter le changement des comportements ayant disparu.
L’idée d’utiliser des variables d’environnement de la JVM a été pressenti pour faire un partie de la configuration du portail. Cela apporte l’avantage de se faire au runtime et de ne pas être obligé de passer par une phase de « init »
Exemple
export JAVA_OPTS="$JAVA_OPTS -Dnancy2.syslog.host=syslog.univ-nancy2.fr"
export JAVA_OPTS="$JAVA_OPTS -Dnancy2.syslog.facility=LOCAL5"
export JAVA_OPTS="$JAVA_OPTS -Dnancy2.syslog.facility.stats=LOCAL6"
NB : Vincent Repain Pour info, le package uPortal 4 de base utilise maintenant des filtres maven (https://wiki.jasig.org/pages/viewpage.action?pageId=42696767)
On va gérer un seul package celui de prod qui ne contiendra donc que les sources du portail.
On générera ensuite un « livrable » quickstart depuis le package de prod (prod + tomcat + portlet AJ-SIG + portlet ESUP + CAS), il faudra surement se rapprocher du JA-SIG pour savoir comment ils génèrent leur package de quickstart (et s’en inspirer fortement). Le quickstart au final ne devrait nécessiter qu’une JVM préinstallée et devrait pouvoir fonctionner en moins de 15min.
news, esup-lecture, filemanger, annuaire, imap, helpdesk, web-proxy-portet configuré, esco-grouper (en servlet), portlet calendar,…
On sent bien que pour intégrer ces portlets facilement dans le quickstart il faudrait peut être un prérequis : disponibilité en maven
Peut être ne pas aller trop loin, on ne peut intégrer que ce qui n'a pas d'autre lien que le portail, le LDAP et une base (pas de apogée, moodle, etc…)
NB: Le besoin de documenter la manière de contribuer au projet est apparu dans la réunion. (cf https://wiki.jasig.org/display/UPC/Contributing)
S’est posée la question de déveloper une interface graphique pour générer la configuration du package (build.properties et config.properties actuellement), on a décidé que ça ne valait pas le coup.
NB: Revoir les portlet de test (cas test, canal info, …) pour les passer en V4.NB: Voir si on peut intégrer des portlets ayant un lien avec LDAP ?
La nouvelle version du portail amène une couche mobile plus évoluée.
Le portail dispose maintenant d’une vue mobile adaptée (donc avec un simple navigateur web mobile) mais aussi de la possibilité d’utiliser une application cliente sur les périphériques mobile.
Le principe de fonctionnement de cette seconde est le suivant :
L’intérêt de l’application dédiée par rapport a la vue mobile via un navigateur a été soulevée sans remporter un franc consensus. (Christian C : ça remonte à Alain Mayeur pour validation.)
On voit sur cette partie, comme cela l’a été évoqué en groupe esup-mobile, qu’un travail doit être mené sur le serveur CAS afin d’éviter la ré-authentification trop fréquente des clients mobiles
Les points a traiter dans cette partie :
(Non traité dans la journée)
Nous disposons déjà sur le site eSup-Portail de « HOW-TO » référençant des modifications de comportement du portail qui ont un impact sur les XSL (exemple : afficher un seul canal à la fois par onglet, ajout de bouton d’ouverture d’iframe, etc…).
Je pense intéressant de refaire le tour de ces modifications de voir si certaines ne seraient pas directement intégrables dans le portail (de manière optionnelles).
A voir s'il est judicieux de tenter un Proof Of Concept d’une interface uPortal complétement revue en HTML5 (voir sur de la sous-traitance) (en cas de sous-traitance à une boîte de type Alsacréation on peut imaginer un Lot "Faites vous please, Guys!!" c'est à dire modifs XSL XHTML5, ARIA, ajout jQuery UI, responsive design - toutes documentées avec un support unique de IE9+/Firefox9+/Chrome+/Safari5.1+, bien-sur ce lot n'est accessible que si le premier lot livraison de skin "portail" est recetté - comme ça on a affaire à de gars qui connaissent le rendering du portail).
(Non traité dans la journée)
Cette partie a pour but d’essayer de faciliter le développement de portlet dans le portail mais aussi de faciliter les adaptations du portail lui-même
Il faut peut-être :
Le portail va inclure, grâce à l’utilisation de portlet V2, un moteur de recherche transversal. Celui-ci sera capable de lancer une recherche dans chaque portlet et ce sont les portlets elles-mêmes qui renverront les résultats. Il faudrait étudier ces pistes pour les exposer dans le cadre esup-commons.
Sur le même principe le portail V4 va mettre à disposition un mécanisme de notification qu’il serait intéressant d’étudier pour en faire un retour aux développeurs.
Il y a des enjeux dans les établissements notamment pour l'offre de formation :
- ROF a pris du retard ;
- SOF est un vieux canal de type iChannel ;
(Non traité dans la journée)
On voit l’obligation de trouver des prestataires extérieurs capables d’accompagner les établissements dans leur installation/déploiement. eSup n’a pas les forces nécessaires pour suivre ces demandes.
Il faudra être capable d’identifier des prestataire capables de répondre dans ce cadre, l’idéal serait d’arriver à établir des prestations type et peut-être une négociation de tarifs.
(Non traité dans la journée)
A l’occasion de la réalisation de ce nouveau package, il serait intéressant de consacrer du temps à la réalisation de documentation sur des préconisations en terme d’infrastructures liées à l’ENT. Celles-ci pourraient recouvrir :
(Non traité dans la journée)
Il est nécessaire de refaire la traduction du portail, il semble que le JA-SIG utilise des outils de traduction automatique (fiabilité ?)
Il est primordial de mettre en place un dialogue pérenne avec le JA-SIG sur ce point. Vincent Bonamy a tenté d’initier une démarche dans ce sens qui est restée sans réponse.