...
A noter : J'ai dû rentrer dans le code de LiteUI fin août car je n'obtenais pas correctement les accents ce qui était bloquant pour la mise en production (normalement, résolu depuis : https://spaces.internet2.edu/display/Grouper/Grouper+UI+internationalization). Du coup, j'ai utilisé les connaissances acquises sur le fonctionnement du code LiteUI pour apporter les modifications rapides que je souhaitais. Je vous les livre, elles ne suivent pas forcément ce qui est écrit sur le wiki ici : https://spaces.internet2.edu/display/Grouper/Customising+the+Grouper+UI - Si un autre établissement peut apporter des rectifications/conseils/éclairages, ils sont les bienvenus !
Attention, problème avec IE9 pour le paging : je vais donner l'astuce de cliquer sur le bouton "affichage de compatibilité" juste après la saisie de l'url, à côté de la loupe.
1. Franciser l'interface
...
J'ai francisé l'interface en modifiant le fichier \ [chemin d'installation de Grouper-UI\]/conf/resources/grouper/nav.properties : toutes les clés simpleMembershipUpdate (je n'ai francisé que LiteUI car AdminUI est vraiment orienté administrateur Grouper donc par des informaticiens). Voir le fichier joint : listesModificationsFrancaises.txt Il faut intégrer ces clés dans votre fichier nav.properties et commenter celles correspondantes en anglais. \---\- Ou mieux : créer un fichier nav.properties français avec déjà ces clés, voir comment il peut surcharger celui en anglais (où le mettre pour qu'il soit pris en compte ?) \-\---
Attention au tri avec les accents, j'ai également modifié un source pour faire le tri correctement, voir sur la liste grouper-users nov 2011 (modif du SubjectSortWrapper.java)
2. Ne pas afficher le lien vers AdminUI + réduire les détails sur le groupe et les membres
...
| Bloc de code |
|---|
#simpleMembershipUpdate.exportAllSubjectFields=sourceId, screenLabel, entityId, name, description simpleMembershipUpdate.exportAllSubjectFields=name, mail |
Paramétrage de ldappcng
Voir sur la liste grouper-users nov 2011 comment exporter un attribut ldap multivalué (modif de SimpleMembershipUpdateImportExport.java mais sera mis dans les prochaines versions).
Paramétrage de ldappcng
Un peu compliqué le paramétrage Un peu compliqué le paramétrage de cette publication. Les 4 fichiers essentiels sont ceux ci-dessous précisés.
...
Ici, la valeur à mettre dans l'attribut ldap est celle qui se trouve dans l'attribut "ustlRole" du groupe Grouper.
Quelques scripts
Pour vous aider dans vos scripts, je vous ai joint plusieurs scripts et vous explicite ci-dessous leur fonction.
1. Publier dans la branche ou=people du ldap et garder une copie de ce qui se fait
2. Mettre tous les membres des groupes (publiant dans la branche ou=people du ldap) dans un groupe témoin
Il y a actuellement un problème avec le couple Grouper/ldappcng (sera corrigé avec l'arrivée du "real-time and incremental provisioning" prévu à la roadmap). Le problème est qu'il ne publie les modifications dans le ldap QUE pour les membres des groupes. Cela fait que si la personne n'est plus membre d'aucun groupe, il ne sera pas publié et l'on pourrait donc avoir un décalage entre ce qui est dans le ldap et ce qui est dans Grouper. Par exemple, user1 est membre de mongroupe1 et mongroupe2. Il est publié dans le ldap avec l'attribut ustlRole (pour Lille1) égal à 2 valeurs : mongroupe1-users et mongroupe2-users. Après sa publication dans le ldap, il est retiré de ces 2 groupes et ne figure plus dans aucun autre groupe : à ce moment-là, il n'est pas republié dans le ldap car le module ldappcng n'interroge et met à jour ldap que pour ceux qui sont dans des groupes Grouper...
Cela est dû au fonctionnement actuel : le module ldappcng interroge ldap, uid par uid présent dans un groupe, pour savoir si ce qu'il a côté grouper pour cet uid est conforme à ce qu'a ldap pour cet uid. Mais comme il n'interroge que les uid présents dans un groupe, il n'interroge plus ceux qui ne sont plus dans aucun groupe... il vaudrait mieux que ldappcng interroge Grouper des modifications qui ont eu lieues depuis la dernière publication ldap, je pense que c'est ce qui sera fait dans la nouvelle version de ce module ldappcng.
En attendant, j'ai prévu une "rustine" pour éviter que cela se produise. Je mets systématiquement tout membre d'un groupe publiable dans le ldap (mes fameux groupes de type ustlRole) dans un groupe qui sert de témoin de présence : groupe témoinustlRole.
...
pourPublierViaLdappcng.sh et wakscriptSync
Ce script permet d'interroger le ldap pour connaître les personnes qui sont à resynchroniser par rapport à ce qui existe dans Grouper. Ceux qui sont à modifier sont enregistrer dans le fichier uidATraiter et sont synchronisés l'un après l'autre par un sync. S'il y a eu des personnes synchronisées, le fichier uidATraiter est mémorisé dans un répertoire à part avec la date de publication. Cela permet de suivre ce qu'il se fait, c'est rassurant au début !
Il faut savoir que la synchronisation Grouper-Ldap version 1.6.3 n'est pas optimum car elle interroge systématiquement ldap pour chaque personne présente dans un groupe Grouper, ce qui est consommateur côté ldap. L'administrateur ldap ayant des craintes, il n'a pas souhaité que j'utilise un bulkSync mais un sync sur ceux à modifier. Finalement, en connaissant mieux cette synchronisation, je me rends compte que cela revient au même mais au moins, cela l'a rassuré et m'a permis de continuer Grouper. Il faut attendre les futures versions de ce connecteur pour avoir une version incrémentale : plutôt que d'interroger ldap, le connecteur interrogera Grouper pour savoir ce qui a été modifié depuis la dernière synchronisation (voir la version 2.1 de Grouper qui devrait sortir fin 2011).
2. Mettre tous les membres des groupes (publiant dans la branche ou=people du ldap) dans un groupe témoin
NettoyerPuisDonnerLeRoleTemoin.sh - pourNettoyerRoleTemoin.sh - nettoyerLeRoletemoin.gsh - pourDonnerLeRoleTemoin.sh - donnerLeRoleTemoin.gsh -
Il y a actuellement un problème avec le couple Grouper/ldappcng (sera corrigé avec l'arrivée du "real-time and incremental provisioning" prévu à la roadmap). Le problème est qu'il ne publie les modifications dans le ldap QUE pour les membres des groupes. Cela fait que si la personne n'est plus membre d'aucun groupe, il ne sera pas publié et l'on pourrait donc avoir un décalage entre ce qui est dans le ldap et ce qui est dans Grouper. Par exemple, user1 est membre de mongroupe1 et mongroupe2. Il est publié dans le ldap avec l'attribut ustlRole (pour Lille1) égal à 2 valeurs : mongroupe1-users et mongroupe2-users. Après sa publication dans le ldap, il est retiré de ces 2 groupes et ne figure plus dans aucun autre groupe : à ce moment-là, il n'est pas republié dans le ldap car le module ldappcng n'interroge et met à jour ldap que pour ceux qui sont dans des groupes Grouper...
Cela est dû au fonctionnement actuel : le module ldappcng interroge ldap, uid par uid présent dans un groupe, pour savoir si ce qu'il a côté grouper pour cet uid est conforme à ce qu'a ldap pour cet uid. Mais comme il n'interroge que les uid présents dans un groupe, il n'interroge plus ceux qui ne sont plus dans aucun groupe... il vaudrait mieux que ldappcng interroge Grouper des modifications qui ont eu lieues depuis la dernière publication ldap, je pense que c'est ce qui sera fait dans la nouvelle version de ce module ldappcng.
En attendant, j'ai prévu une "rustine" pour éviter que cela se produise. Je mets systématiquement tout membre d'un groupe publiable dans le ldap (mes fameux groupes de type ustlRole) dans un groupe qui sert de témoin de présence : groupe témoinustlRole.
Attention, j'ai dû créer 2 sources.xml différents : l'un pour ce groupershell et l'un pour LiteUI car mon administrateur ldap souhaitait que j'optimise mes requêtes ldap pour ces scripts. Donc, dans le script pourDonnerLeRoleTemoin.sh, j'utilise la fonction SubjectFinder.findAll("*") qui utilise la recherche sur l'attribut "ustlRole" paramétrée dans sources.xml(.gsh) :
| Bloc de code |
|---|
<search>
<searchType>search</searchType>
<param>
<param-name>filter</param-name>
<param-value>(ustlRole=%TERM%)</param-value>
etc
</search>
|
Si je laissais le sources.xml comme cela, LiteUI ne fonctionnerait pas car il rechercherait sur l'attribut ustlRole plutôt que sur l'uid et le displayName comme paramétré dans sources.xml(.liteui) :
| Bloc de code |
|---|
<search>
<searchType>search</searchType>
<param>
<param-name>filter</param-name>
<param-value>(& (|(uid=%TERM%)(displayName=*%TERM%*)))</param-value>
</param>
etc
</search>
|
3. Initialisation des données : peupler les groupes depuis le ldap
chargerustlRoles.gsh - chargerAdmin.gsh
Ceux-ci permettent de peupler les groupes Grouper à partir des valeurs déjà présentes dans l'annuaire (reprise de l'existant dans ldap dans Grouper).
Le premier permet de mettre comme membres du groupe Grouper de type "PAGSRole" toutes les personnes du ldap dont l'attribut ustlRole a la même valeur que l'attribut "ustlRole" du groupe Grouper.
Le second permet de mettre le droit Grouper "UPDATE" à toutes les personnes du ldap dont l'attribut ustlRole est égal à admin-+"valeur de l'attribut "ustlRole" du groupe Grouper. Par exemple, ceux qui ont ustlRole=admin-IntranetEquipeDirection auront le droit UPDATE sur le groupe Grouper dont l'attribut "ustlRole=IntranetEquipeDirection-users". Ils rejoindront aussi le seul groupe d'administration d'application que nous avons créé dans Grouper : le groupe des administrateurs d'application dont l'attribut "ustlRole=admin-appli".
Brigitte WALLAERT-TAQUET