Réunion du 24 janvier 2012

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)

Organisation du groupe de travail

Il a été décidé de découper ce groupe en plusieurs thématique afin d'avancer en parallèle :

• Grouper : branchement de Grouper sur l'ENT
• Shibboleth : utilisation de Shibboleth pour l'authentification de l'ENT
• Mobile : en lien avec le groupe de travail esup-mobile, traitant de la partie portail mobile (pas forcément des développements par exemple)
• Packaging : manière de réaliser le(s) package(s) eSup portail
• IHM : réalisation de thèmes graphique, de notice d'adaptation, ergonomie
• Migration de données : récupération de données des versions précédentes de packages
• Traductions : traduction du package

Il a été décidé de faire un visioconférence tous les 15 jours, de préférence les jeudi matin pour une durée d'une heure. Des autres points pourront être fait sur des parties plus spécifiques.

IHM

Nous avons un gros travail à faire de ce côté, que ça soit en terme graphique visuel, ergonomique et performance.
Il est impératif de se rapprocher de Jean Michel Doublet sur cette partie.

Thèmes graphique

Il faudra réaliser des thèmes graphiques (« skin ») pour ce faire :

• Il faudra essayer d'utiliser ce qui est déjà existant dans le portail (pas de librairie javascript supplémentaire, réutilisation de fluid)
• Essayé tant que possible de ne travailler que au niveau CSS
• Imaginer peut être :
  • un thème graphique minimale (pas de bandeau, mise e avant de canaux)
  • un thème onglet en ligne
  • un thème onglet en colonne
• La réalisation de ces thèmes amènera à réaliser un guide aussi simple que possible sur la manière de s'approprier ces thèmes et de les adapter.

Appel à sous-traitance ?

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. Il faut donc essayer de trouver ces petites entreprises.
Il y a aussi la possibilité de développé ceci en interne (esup).
Christian C. s'est proposé pour suivre cette partie de plus prêt.
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.
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.
De même on peut 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é (voir la diffusion du rapport de Témésis ?)

Utilisation de Grouper

L'utilisation de grouper dans le portail doit être facilité par esup !

Les versions de grouper ?

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.

Branchement de grouper

Rappel des techniques possible de branchement de grouper avec le portail :

• GroupStore RECIA :
  • cette technique offre une vision arborescente (hiérarchique) des groupes dans le portail
  • Elle utilise l'API Grouper (ce qui veut dire au final accès directe à la base Grouper et au LDAP)
  • Un problème est que pour faire cette implémentation il faut ajouter des jar grouper qui viennent avec leurs dépendance (spring, log4j, ...) il faut donc valider le bon fonctionnement en version uP4
  • Apporte une grande souplesse car aucun redémarrage n'est nécessaire lors de modifications/création de groupe
• GroupStore Internet2 :
  • devrait être bientôt redéveloppé
  • Utilise le WS natif grouper
  • nécessite de la patcher pour un bon fonctionnement
  • affiche tous les groupes a plats !
• GroupStore LDAP : il semble ne pas exister de solution parfaite de ce coté, mais l'idée est d'utiliser directement l'OU Groups du LDAP généré par Grouper (peut être a développer, quantifié le temps et voir l'intérêt) (modification des PAGS ?)

La portelt esco-grouper

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 recommander 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).

Intégré ?

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é, on risque d'avoir des performances hasardeuse.

Documentation

Il faudrait peut-être essayé d'épurer la documentation pour faire un document d'installation plus synthétique, il faudrait repartir du tutoriel pour faire cette documentation.

Structure de groupe

Nous pourrons essayer de proposer un structure de base pour le groupe portail gérer dans grouper. Julien M a émis l'idée de faire un groupe par canal, de donner les droit de vision du canal a 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)

Utilisation de Shibboleth

Le but est de facilité l'utilisation de Shibboleth dans ce 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 être 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 :

• L'utilisateur arrive sur le portail
• Demande a s'authentifié
• Et renvoyé vers son WAYF, puis vers son CAS d'établissement, puis vers son IDP et enfin vers son portail authentifié
• Le patch intervient a partir d'ici
• Le portail regarde la provenance de la personne (son établissement), le portail a un mapping établissement ?serveur CAS
• Le portail renvoie l'utilisateur vers son serveur CAS et lui disant de revenir vers le portail
• Ainsi le portail peut initialiser un ticket CAS et donc un mécanisme de proxy

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é par Raymond : Comment fait si on utilise un portail avec grouper et du Shibboleth ? en fait comment attaché des personnes qui ne sont pas dans notre ldap dans des groupe de notre grouper ? Peut être une piste « Grouper external subjects » https://spaces.internet2.edu/display/Grouper/Grouper+external+subjects

Migration de données

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 Version 3.x vers 4 par contre les versions 2.x ne seront étudiées qu'en second temps voir pas étudiée.
Il faudra s'attarder sur la migration des éléments suivants :

• Fragment layout
• Profils utilisateur
• Définition de canaux

Des outils fournis par le JA-SIG sont disponible en version 4, il faudra étudier leur pertinence, leurs limitations et les documenter

Packaging

L'occasion va être donné de refondre complétement le packaging esup car celui n'est plus adapté aux technologies actuelles.

Versionning

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/personnalisation 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.

Configuration

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 variable d'environnement de la JVM a été pressentit pour faire un partie de la configuration du portail. Cela apporte l'avantage de se faire au runtime et de ne pas etre 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"

Package de DEV et de PROD ?

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 reprocher du JA-SIG pour savoir comment il génère leur package de quickstart (et s'en inspirer fortement). Le quickstart au final ne devrait nécessiter qu'une JVM préinstallé et devrait pouvoir fonctionner en moins de 15min.

Portlet a intégrer dans la quickstart ?

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 etre un prérequis : disponibilité en maven
Peut être ne pas aller trop loin on ne peut integrer que si qui n'as pas d'autre lien que le portail , le LDAP et un 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)
C'est posé la question de développé 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 ?

Mobile

La nouvelle version du portail amène une couche mobile plus évolué.
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 :

• On installe une application dédié mobile (compiler selon la plateforme)
• Cette application va disuter avec le portail en JSON (/uPortal/layout.json)

L'intérêt de l'application dédié par rapport a la vue mobile via un navigateur a été soulevé sans remporter un franc consensus.
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 traité dans cette partie :

• Evaluation de uMobile
• Possibilité de personnalisation
• Modalité de déploiement des applications dédié mobile
• Développement dans ce cadre (portlet)

Adaptation des XSL

(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égrable dans le portail (de manière optionnelles).
A voir si il est judicieux de tenter un Proof Of Concept d'une interface uPortal complétement revue en HTML5 (voir sur de la sous-traitance)

Développement

(Non traité dans la journée)

Cette partie a pour but d'essayer de faciliter le développement de porlet dans le portail mais aussi de faciliter les adaptations du portail lui même
Il faut peut-être :

• envisager un passage en mode « debug » du portail plus facile
• Faire des préconisations d'outils pour le développement XSL/java/css

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 se sont le porltet elles même 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 a disposition un mécanisme de notification qu'il serait intéressant d'étudier pour en faire un retour aux développeur.

• aborder les canaux qui ne fonctionneront pas en V4 (tout ce qui n'est pas portlet : anciens canaux de type iChannel) :

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 ;

Accompagnement dans l'installation et le paramétrage dans les établissements

(Non traité dans la journée)

On voit l'obligation de trouver des prestataires extérieurs capable d'accompagné les établissements dans leur installation/déploiement. eSup n'a pas les forces nécessaire pour suivre ces demandes.
Il faudra être capable d'identifié des prestataire capable de répondre dans ce cadre, l'idéal serait d'arriver a établir des prestation type et peut être un négociation de tarif.

Infrastructure

(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 termes d'infrastructure lié à l'ENT. Celles-ci pourraient recouvrir :

• infrastructure matérielle (nombre de serveur, taillage)
• de préconisation logicielle
• montrer des solutions de load balancing
• réplication en ferme de serveur
• métrologie / surveillance

Traductions

(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'initié une démarche dans ce sens qui est resté sans réponse.