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), Ludovic Auxépaules (UPMC)

Objectifs

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é.

Organisation du groupe de travail

Il a été décidé de découper ce groupe en plusieurs thématiques 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 graphiques, de notices 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 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.

IHM

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.

Thèmes graphiques

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 et de jQuery UI et des Css de jQuery UI theme roller)
• Essayer si possible de ne travailler qu'au niveau CSS
  • Une règle non négociable pour ces nouveaux thèmes sera que les thèmes "uPortal3", "Ivy", "Coal" et "HightContrast" livrés de base avec uPortal4 devront rester fonctionnels, une fois implémentés dans esup (comme cela, on est sûrs que les modifications auront lieu sur les css uniquement...).
• Imaginer peut être :
  • un thème graphique minimal (pas de bandeau, mise en 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.
• Il faut fournir la liste des OS/navigateur/version qui seront supportés et anticiper les phases de tests avant recette.

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

Utilisation de Grouper

L’utilisation de grouper dans le portail doit être facilitée 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 modification/création de groupe
  • La procédure d'intégration sur uportal 3.2.4 est documentée : Intégration RECIA Grouper-Portail
• 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 à 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 à développer, quantifier 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 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).

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ées, on risque d’avoir des performances hasardeuses.

Documentation

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.

Structure de groupe

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)

Utilisation de Shibboleth

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 :

• L’utilisateur arrive sur le portail
• Demande à s’authentifier
• Et renvoyé vers son WAYF, puis vers son CAS d’établissement, puis vers son IDP et enfin vers son portail authentifié
• Le patch intervient à 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é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

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 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 :

• Fragment layout
• Profils utilisateurs
• 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ée 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/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.

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

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

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 ê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 ?

Mobile

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 :

• On installe une application native mobile (compilée selon la plateforme IOS / Android)
• Cette application native va discuter -entre autre...- avec le portail en JSON (Url/<Context>/layout.json) et CAS/Shibboleth

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 :

• Évaluation de uMobile
• Possibilité de personnalisation
• Modalité de déploiement des applications dédiés mobile dans AppleStore et AndroidMarket
• Développement dans ce cadre (portlet) - en utilisant la uMobile Portlet Archetype mais aussi esup-commons
• Développement de Native Module, Native Webview Module dans l'application native

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

Développement

(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 :

• 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 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.

• 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 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.

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 terme d’infrastructures liées à l’ENT. Celles-ci pourraient recouvrir :

• infrastructure matérielle (nombre de serveurs, taillage)
• des préconisations logicielles
• montrer des solutions de load balancing
• réplication en ferme de serveurs
• 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’initier une démarche dans ce sens qui est restée sans réponse.