Fonctionnalités attendues dans WUI v2

Gestion des mots de passe

L'utilisateur doit pouvoir modifier son mot de passe, en respectant la politique des mots de passe paramétrée au niveau de l'annuaire LDAP. Par exemple :

  • taille minimale
  • temps de validité restant
  • historique
  • etc.
Voir http://tools.ietf.org/html/draft-behera-ldap-password-policy-09

Peut-être à implémenter dans LDAP core ?

Priorité : basse.

Gestion des photos / trombinoscope

D'habitude les photos des personnes ne sont pas stockées dans l'annuaire. Il faut donc prévoir un espace web où les fichiers seront stockés, et liés à la fiche de la personne de l'annuaire.

  • La photo doit être modifiable par l'administrateur et/ou l'utilisateur
  • On doit avoir une page "trombinoscope"
  • Les photos doivent pouvoir apparaître dans les résultats d'une recherche
  • Si les photos sont stockées dans l'annuaire, on doit également pouvoir les voir
Priorité : moyenne.

Organigramme

Lorsque l'on clique sur une strucuture, on doit pouvoir obtenir son organigramme, avec si possible les photos des personnes responsables de chaque service.

Priorité : basse.

Recherche rapide

Un champ de recherche rapide doit être accessible partout dans l'application. Il permet la recherche sur les noms et prénoms.

Priorité : moyenne.

Recherche avancée / multi-critères

Un formulaire de recherche avancée :

  • choix des critères
  • et / ou
  • mémorisation des dernières recherches effectuées
Question : prévoit-on un cache des recherches ?

Priorité : haute.

Export des résultats

Suite à une recherche ou au clic sur une structure, un organigramme, etc., il doit être possible de sauvegarder les données au format :

  • PDF (mise en page liée au thème chois)
  • CSV
  • LDIF
  • DSML
Priorité : moyenne.

Modification d'entrée

Priorité : haute.

Création d'entrée

Priorité : haute.

Préférences de l'utilisateur

Les utilisateurs doivent pouvoir stocker certaines préférences :

  • langue de l'interface
  • thème (skin)
  • ...
-> Schéma enrichi ?

Priorité : haute.

Modification "en masse"

Suite à une sélection d'entrées effectuées à partir du formulaire de recherche, il doit être possible de modifier l'ensemble de ses fiches. Par exemple changement une adresse pour un ensemble de personne, ou réinitialiser leur mot de passe. Cela doit être possible sur toutes les entrées autorisées, avec un message indiquant si l'accès en écriture aux attributs de certaines entrées est refusé.

Exemple de workflow associé :

  • l'utilisateur vient d'effectuer une recherche, il dispose d'un ensemble d'entrées "EE" ;
  • il choisit "modification" en masse ;
  • on lui demande de choisir un objectClass parmi l'union des des objectClass disponibles dans l'ensemble ;
  • l'ensemble "EE" est filtré pour ne garder que les entrées qui contiennent l'objectClass selectionnée ;
  • les attributs correspondant à l'objectClass sont présentés afin que l'utilisateur en sélectionne un ;
  • l'utilisateur édite l'attribut, peux choisir entre "mettre à jour" (i.e ne traiter que les entrées ayant déjà l'attribut) ou "créer si besoin" et valide ;
  • la modification est faite sur toutes les entrées correspondant aux choix de l'utilisateur.
Priorité : moyenne.

Interception (trigger) sur les actions LDAP

Donner la possibilité d'intercepter des actions LDAP (par exemple : mot de passe modifié) et de déclencher un action en conséquence, de maniètre immédiate, ou de stocker cette action pour un traitement ultérieur.

Priorité : moyenne.