Remarques et Demandes d'évolution du RECIA :
Contexte du RECIA : Principalement accès à des espaces multiples samba avec des résolutions DFS.
- Après la saisie de son identifiant/mot de passe il peut se passer un certain temps avant que les "File" de l'espaces soient affichés, hors aucun indicateur de chargement n'est affiché, faisant que l'utilisateur aura tendance à cliquer à nouveau sur le bouton de connexion. Le seul indicateur de chargement visible est quand on a déjà été connecté sur un drive, que l'on change de drive et que l'on recharge le drive de départ, une icône de chargement s'affiche à gauche du drive à la place de l'icône du drive. il faudrait la même chose à la place de la fenêtre de saisie du login/mot de passe après le clique sur le bouton de connexion, ou le mieux en image transparente sur le premier plan de l'écran avec l'arrière plan de figé, évitant ainsi tout problème de clique.
- L'accès SMB défini avec une authentification n'a pas forcément l'authentification de défini sur le "basePath", cela peut l'être uniquement sur un certain chemin du drive. -> La solution vue est d'ajouter un paramètre dans la définition du drive définissant un chemin complémentaire AuthPath formé de la façon BasePath + AuthPath qui servira a effectuer la connexion.
- La version de jcifs est trop ancienne, il doit en être de même pour slide, faisant qu'il y a des problèmes d'affichage des "children" du drive.
- Le canal cstockage est plus rapide lors du chargement de l'espace (équivalent au drive pour le portlet) après connexion que le portlet, cela vient sans doute du fait que le portlet récupère tous les "Children" avec leurs propriétés alors que le canal lui ne semble pas faire tout cela. Y aurait une façon d'améliorer cela ?
- Commentaire par V.Bonamy: a priori org.apache.commons.vfs.provider.getChildren demande effectivement au AbstractFileSystem fs de récupérer l'ensemble des propriétés des children lors des resolveFiles - aussi avec commons VFS, cela parait difficile d'optimiser la chose.
- Si un chemin d'accès n'est pas joignable le drive n'affichera pas son contenu et finira avec une erreur affichée à l'utilisateur, après avoir changé de drive et en revenant sur le drive à problème une erreur "Internal servlet error" est affichée rendant le fonctionnement du portlet instable. De notre côté nous avons intercepté les erreurs en ne retenant à l'affichage que les espaces sans problème, aucune erreur ne sera affichée à l'utilisateur, mais des messages de log sont générés. Mais la question à se poser est que faire des chemins d'accès posant problème, les lister et les afficher dans une box à l'utilisateur pour qu'il transmette ces problème à un admin ? envoyer un mail d'erreur à l'admin de l'application ? ou juste se contenter des messages de log ?
- il est possible de filtrer les droits d'accès uniquement sur des groupe, mais il est tout à fait possible d'envisager que cela soit effectué via un filtre ou attribut LDAP.
Remarques et Demandes d'évolution de l'Insa de Rennes :
- L'authentification se fait sans domain, cela peut poser problème sur des accès en CIFS par exemple
-> permettre de définir un domain au niveau d'un FsAccess ou d'un UserAuthenticatorService- Commentaire par V.Bonamy: fait dans la branche - ok pour prochaine version
Remarques et Demandes d'évolution de l'Université de Rennes 1 :
- Les remarques concernent l'intégration avec ESUP-ECM (Suite à une discussion entre Vincent et Raymond à Paris le 15/03/2011) :
- Permettre la possibilité, depuis un "répertoire ECM" de la portlet, d'accéder à Nuxeo dans l'espace idoine
- Offrir la possibilité de lancer une recherche depuis un "drive ECM" en utilisant le langage de recherche CMIS