Icône parfois inappropriée ou inexistante (non reconnaissance du type du document ?)

[vieville]

dans le test que nous venons d'effectuer nous rencontrons 1 cas où l'icône est du type text (feuille de papier avec crayon) alors que le fichier principal est du type text/html (mais saisi comme une note dans nuxeo)

Dans un deuxième cas il n'y a pas d'icône attaché alors que le document est un folder (quand on clique dessus dans la portlet son contenu est bien attaché) mais qui sa description est vide.

Dans un troisième cas il n'y a pas d'icône pour un document dont le type a été défini "localement" (support de formation)

Tout ça c'est sans doute des cas extrêmes... et donc rares...

[raymondBourges]

Cas 1 : normal ? Si non, que faudrait-il comme icône ? Cas 2 : Il me semblait qu'un folder avait bien une icône de type folder. Est-ce spécifique au fait que la description est vide (ou une autre particularité) ou as-tu le cas sur tous les folders ? Cas 3 : Il me semble qu'il faudrait avoir une icône par défaut pour tout ce que l'on ne sait pas traiter. On va regarder çà.

PS : N'hésite pas à mettre des images dans les issues pour que ce soit plus "parlant".

[vieville]

Cas 1 : pas certain. En fait ce que je souhaite c'est que l'icône (peu importe ce qu'elle représente à ce moment) soit associée avec le document principal du document et non au type de document - ce qui réglerait alors le cas n°3 en même temps Cas 2 : C'est vraiment spécifique au fait que le champ description soit vide. Si je le remplis l'erreur disparait Cas 3 : voir cas 1- actuellement si un type de document n'est pas connu il semble qu'on puisse le lister. On ne devrait lister que les documents du type foldershable...

Est-ce que je suis compréhensible ?

[raymondBourges]

Suite appel : Cas 1 : La portlet utilise l'info remontée par Nuxeo pour déterminer l'icône à utiliser. L'idée de Claude était de prendre le type Mime du document principal pour déterminer l'icône à utiliser. C'est une évolution non négligeable. Je propose de la reporter. Cas 2 : Un répertoire avec une description vide n'a pas d'icône d'affichée ! --> Vérifier si on a le même comportement ici. Cas 3 : --> Vérifier dans le code si on se base sur la facette folderish du document (et pas "simplement" le type folder) pour déterminer si c'est un élément navigable ou pas

[raymondBourges]

Cas 2 : non reproductible ! On laisse de côté pour le moment. Cas 3 : On a regardé le code et on utilise pas la facette folderish. C'est pourtant une très bonne idée --> On fait.

[vieville]

cas 2 : ne se reproduit plus à lille suite à un changement de version pour tester le download des documents multi fichiers [il n'y avait pas eu de changement côté nuxéo entretemps]

On peut vraiment laissé tomber ce cas

[myrenai]

Cas 3 -> réalisée en tag 1.0.8 et https://mvn.esup-portail.org/content/repositories/releases/org/esupportail/esup-portlet-intranet-web-springmvc-portlet/1.0.8/

[vieville]

Cas 3, je constate que ça fonctionne correctement de mon côté : bravo!

Cas 1 : il reste quelques documents sans icône vue intranet:

vue nuxéo :

[raymondBourges]

Je ne sais pas si tu connais la blague de Coluche à propos du tiercé qui dit : "Si vous avez joué le 8, le 12 et le 8, vous vous êtes trompé, vous avez joué deux fois le 8..." Mais tu nous as mis 2 fois la même image ;-)

[vieville]

ouais pas trop réveillé.... voilà la copie du côté portlet

[vieville]

J'ai inspecté les logs en mode debug et pour les documents dont l'icône ne s'affiche pas sur la portlet le flux du document la propriété common:icon est à null !

C'est pas trop compréhensible car l'affichage est correct dans les interfaces de nuxéo.

Nuxéo utilise sans doute une autre donnée pour afficher l'icône.

[vieville]

J'ai envoyé une question à ce sujet (common:icon à null alors que l'affichage dans nuxéo est correct) sur nuxeo car je pense que nous avons certainement oublié de faire quelque chose lors de la déclaration de nos nouveaux types. En effet un nouveau type qui réutilise une icône définie au préalable dans nuxéo (/icons/contextuallink.png pour le doctype docWEBENT) fonctionne correctement. Je vous propose d'attendre un retour éventuel à cette question...