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 (UNPIDFParis1), Vincent Bonamy (Rouen), Romain Legrand (Cergy), Yves Deschamps (LilleLille1), Florent Fareneau (Valenciennes), Guillaume Deudon (Valenciennes), Eric Doual (LilleLille3), Mathieu HETRU (Lille3), Julien Marchal (Lorraine), Ludovic Auxépaules (UPMC)

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 :

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
• 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 graphiquegraphiques, de notice d'adaptationnotices 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 une visioconférence tous les 15 jours, de préférence les jeudi jeudis matin pour une durée d'une d’une heure. Des autres points pourront être fait 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 performanceperformances.
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 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)
• Essayé tant que Essayer si possible de ne travailler que 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
  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 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 l’appel à sous-traitance pour les réalisations graphiques.
Bull a fait un excellent travail sur la portlet esup-filemanager (mais il semble qus'ils ont eux-mêmes sous-traité le travail purement graphiqueun 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éveloppé développer ceci en interne (esup).
Christian C. s'est s’est proposé pour, soit suivre cette partie de plus prêt.
Vincent R a quant à 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'enrobagel’enrobage), un second pourrait être les portlets au cas par cas. Il a été aussi évoqué de prévoir des jeux d'icône d’icône (plusieurs) qu'on qu’on pourrait utiliser a travers nos différentes portlets .
De même on peut s'engager 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 l’ergonomie (pas abordé pendant la journée) et l'accessibilité l’accessibilité (Christian C, cela m'intéresse aussi, je suis expert Accessiweb2) (voir la diffusion du rapport de Témésis ? )

Utilisation de Grouper

au prestataire ? - une diffusion au minimum au groupe de travail IHM est la moindre des choses...)

Utilisation de Grouper

L’utilisation L'utilisation de grouper dans le portail doit être facilité 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 l’instant il y a des problèmes de performances sur cette version. Pour l'instant l’instant la portlet esup-esco-grouper ne fonctionne pas sur la version 2 de grouper, il faut donc utiliser l'interface l’interface native (d'où d’où une grande perte d'intérêtd’intérêt). Pour l'instant 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 :

• GroupStore RECIA RECIA  :
  • cette technique offre une vision arborescente (hiérarchique) des groupes dans le portail
  • Elle utilise l'API 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’est nécessaire lors de modificationsmodification/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 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 l’idée est d’utiliser directement l’OU Groups du LDAP généré par Grouper (peut être a à développer, quantifié quantifier le temps et voir l'intérêtl’intérêt) (modification des PAGS ?)

...

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 recommandé pour l'instant de l'utiliser l’instant de l’utiliser en mode servlet (plus souple, moins d'adhérence 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 . La réponse est non car trop difficile de gérer les montées des versions décalédécalées, on risque d'avoir d’avoir des performances hasardeusehasardeuses.

Documentation

Il faudrait peut-être essayé d'épurer essayer d’épurer la documentation pour faire un document d'installation 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érer géré dans grouper. Julien M a émis l'idée 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 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 faciliter l’utilisation de Shibboleth dans ce cette nouvelle version. Beaucoup d'universités d’universités utilisent ou souhaitent utiliser Shibboleth pour répondre à des problématiques d'UNR 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 n’interviendra pas dans cette partie), mais aussi dans la partie de récupération des attributs.
L'intégration L’intégration Shibboleth a tout de même une forte conséquence sur le fonctionnement du portail. Avant l'utilisation l’utilisation de CAS permettait d'avoir d’avoir un fonctionnement proxy CAS : le portail pouvait donc utiliser des services sous-jacents (imap, ftp, ...…) en propageant l'authentification 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 L’utilisateur arrive sur le portail
• Demande a s'authentifiéà s’authentifier
• Et renvoyé vers son WAYF, puis vers son CAS d'établissementd’établissement, puis vers son IDP et enfin vers son portail authentifié
• Le patch intervient a à partir d'icid’ici
• Le portail regarde la provenance de la personne (son établissement), le portail a un mapping établissement ?serveur CAS
• Le portail renvoie l'utilisateur 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 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 d’attribut type (extrait de supann) pour l'utilisation l’utilisation dans le cadre du portail.

NB Question soulevé soulevée par Raymond: Comment on fait si on utilise un portail avec grouper et du Shibboleth ? en fait comment attaché attacher des personnes qui ne sont pas dans notre ldap dans des groupe 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 d’étudier les possibilités de migrations de données des versions précédentes de portail.
Il est clair qu'il qu’il faut regarder la migration de données des Version Versions 3.x vers 4 par contre les versions 2.x ne seront étudiées qu'en qu’en second temps voir voire pas étudiéeétudiées.
Il faudra s'attarder s’attarder sur la migration des éléments suivants :

• Fragment layout
• Profils utilisateurutilisateurs
• 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 L’occasion va être donné donnée de refondre complétement le packaging esup car celui n'est n’est plus adapté aux technologies actuelles.

...

Le choix de la gestion de versionning s'oriente s’oriente fortement vers GIT (il faut prendre contact avec le support SourceSup support-sourcesup@support.renater.fr car il semble qu'on 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 d’incorporer nos modifications/personnalisation 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 l’exploitant retrouvera ce qu'il 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 d’options (authentification ldap ou pas, utilisation de cas 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 L’idée d’utiliser des variables d’environnement de la JVM a été pressentit pressenti pour faire un partie de la configuration du portail. Cela apporte l'avantage l’avantage de se faire au runtime et de ne pas etre ê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"

Package de DEV et de PROD ?

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 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 rapprocher du JA-SIG pour savoir comment il génère ils génèrent leur package de quickstart (et s'en s’en inspirer fortement). Le quickstart au final ne devrait nécessiter qu'une qu’une JVM préinstallé 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 etre être un prérequis : disponibilité en maven
Peut être ne pas aller trop loin, on ne peut integrer intégrer que si ce qui n'as a pas d'autre lien que le portail, le LDAP et un une base (pas de apogée, moodle, etc...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é S’est posée la question de développé 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éévoluée.
Le portail dispose maintenant d'une d’une vue mobile adaptée (donc avec un simple navigateur web mobile) mais aussi de la possibilité d'utiliser 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é native mobile (compiler compilée selon la plateforme IOS / Android)
• Cette application va disuter avec le native va discuter -entre autre...- avec le portail en JSON (Url/uPortal<Context>/layout.json) et CAS/Shibboleth

L’intérêt de l’application dédiée L'intérêt de l'application dédié par rapport a la vue mobile via un navigateur a été soulevé soulevée sans remporter un franc consensus. (Christian C : ça remonte à Alain Mayeur pour validation.)
On voit sur cette partie, comme cela l'a l’a été évoqué en groupe esup-mobile, qu'un qu’un travail doit être mené sur le serveur CAS afin d'éviter la réauthentification d’éviter la ré-authentification trop fréquente des clients mobiles

Les points a traité traiter dans cette partie :

• Evaluation Évaluation de uMobile
• Possibilité de personnalisation
• Modalité de déploiement des applications dédié 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 ...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 intégrables dans le portail (de manière optionnelles).

Développement

(Non traité dans la journée)

Cette partie a pour but d'essayer d’essayer de faciliter le développement de porlet 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 d’outils pour le développement XSL/java/css

Le portail va inclure, grâce à l'utilisation l’utilisation de portlet V2, un moteur de recherche transversal. Celui-ci sera capable de lancer une recherche dans chaque portlet et se ce sont le porltet elles même 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 a à disposition un mécanisme de notification qu'il qu’il serait intéressant d'étudier d’étudier pour en faire un retour aux développeurdéveloppeurs. Il sera nécessaire dans cette partie d'aborder le

• 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 l’obligation de trouver des prestataires extérieurs capable d'accompagné capables d’accompagner les établissements dans leur installation/déploiement. eSup n'a n’a pas les forces nécessaire nécessaires pour suivre ces demandes.
Il faudra être capable d'identifié d’identifier des prestataire capable capables de répondre dans ce cadre, l'idéal serait d'arriver a l’idéal serait d’arriver à établir des prestation prestations type et peut-être un une négociation de tariftarifs.

Infrastructure

(Non traité dans la journée)

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

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

...

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