Recherche avancée

Sur d’autres sites (6578)

• Anomalie #3035 (Nouveau) : Association de mots-clés et autorisation

  6 août 2013, par Joseph Larmarange

  Création d’un ticket suite à http://permalink.gmane.org/gmane.comp.web.spip.devel/64550

  Cas de figure :
  - des groupes de mots-clés pour lesquels les rédacteurs ont les droits pour ajouter un mot clé de ces groupes.
  - un rédacteur qui visualise un article dont il n’est pas l’auteur et par conséquent pour lequel il n’a pas les droits d’ajouter ou de supprimer un mot-clé.

  Néanmoins, ce rédacteur va voir la liste des mots-clés associés à cet article, avec un lien pour supprimer les mots-clés en question, un lien ’Ajouter des mots-clés’ lui permettant de charger le formulaire d’ajout de mot-clé.

  Si ce rédacteur décide de faire l’une de ces actions (ajout ou suppression), le bloc va se recharger, l’action ne sera pas exécutée et il n’y aura aucun message d’erreur, par exemple pour avertir que l’on n’a pas les droits nécessaires. On a donc une incohérence de l’interface.

  En investigant, j’aperçois plusieurs points qui font défaut.

  En premier lieu, la fonction autoriser_associermots_dist() regarde simplement si un auteur à le droit en général d’associer des mots-clés d’un groupe en fonction de son statut (admin ou rédacteur) mais ne prends pas en compte si l’individu a le droit de modifier l’objet en question.

  Le formulaire EDITER_LIENS du core regarde dans sa fonction charger l’autorisation associerobjets (donc associermots dans notre cas de figure) pour savoir si le formulaire est editable ou non. Dans sa fonction traiter, le formulaire regarde simplement si l’individu a le droit de modifier l’objet en question ou non (mais ne revérifie pas qu’il a les droits d’associer l’objet en question). Par ailleurs, si on n’a pas les droits requis, la fonction traiter ne renvoie pas de message d’erreur.

  Le squelette prive/objets/liste/mots_lies.html ne tient compte ni de #ENVeditable ni d’une quelconque autorisation pour afficher ou non un lien de suppression d’un mot-clé.

  La fonction autoriser_groupemots_afficherselecteurmots_dist renvoie toujours true.

  Propositions d’évolution

  • Faire évoluer l’autorisation associermots pour qu’elle vérifie également, si un $id_objet est passé, que l’invidu a les droits de modifier l’objet en question. Cela permettra que la propriété editable soit correctement renseignée dans le formulaire d’ajout de mot-clé. Par ailleurs, pour les plugins ayant besoin de savoir si quelqu’un a le droit d’associer un mot-clé, cela fera une seule auorisation à vérifier (le problème s’est posé avec coche_mots).
  • La fonction traiter de éditer_liens devrait dépendre de associermot (il faut vérifier que cela n’a pas d’incidence pour les autres tables de liens) et non des droits de modification d’un objet. Ces droits peuvent être différents dans un contexte d’autorisations personnalisées.
  • Cette même fonction traiter doit renvoyer un message d’erreur si on n’a pas les droits suffisants.
  • Le squelette prive/objets/liste/mots_lies.html doit vérifier l’autorisation associermots pour afficher un lien de suppression d’un mot-clé.
  • Par cohérence, la fonction autoriser_groupemots_afficherselecteurmots_dist est modifiée pour renvoyer, par défaut, le résultat de l’autorisation associermots.

• Anomalie #4543 (Nouveau) : Accessibilité des chargements ajax (live regions)

  2 septembre 2020, par nicod _

  Suite à un audit de site par Temesis, il remonte que les attributs aria qu’on utilise sont mal placés.

  Je cite :

  Il semble qu’il y a un problème plus global avec l’utilisation des live region :
  Je rencontre à nouveau le div englobant div.ariaformprop qui possèdent les attributs

  aria-live
  aria-atomic
  aria-relevant

  Cette utilisation de ces attributs est erronée :

  elle ne donne pas le résultat probablement attendu
  le support d’aria-relevant dans les assistances technologiques n’est pas assuré

  Il est donc nécessaire de ne pas utiliser de live region sur une div englobante comme là.
  Il faut supprimer ces attributs et utiliser aria-live et aria-atomic avec parcimonie.

  J’ai regardé l’exemple que tu donnes sur spip.net également.

  L’exemple était : https://www.spip.net/spip.php?page=recherche&recherche=plugin&debut_articles=0#pagination_articles

  Cette prolifération d’aria-live + aria-atomic part probablement d’un bon sentiment, mais comme parfois avec l’accessibilité, le mieux est l’ennemi du bien.

  En positionnant ces attributs, avec ces valeurs, sur des div englobantes, cela génère dans les lecteurs d’écran la lecture automatique des contenus qui ont été mis à jour.

  Certes la lecture peut être interrompue par l’utilisateur, mais cela revient, à mon avis à imposer quelque chose qui n’a pas été forcément souhaité. De cette manière le propriétaire du site impose une expérience différente aux utilisateurs de lecteur d’écran.
  Ensuite, il faut bien entendu prendre en compte le contexte. Il pourrait arriver que ce comportement soit pertinent. Ce n’est pas le cas ici.

  Dans le cas de rechargement ajax, il faut étudier chaque cas et son contexte, mais le plus souvent le principe est :

  Ne pas utiliser ces attributs lorsqu’il n’y a pas d’interactions / rechargement ajax . Exemple sur un formulaire, cela n’a pas de sens : on rempli un form et puis on valide le form. A priori (si j’ai bien compris le fonctionnement) il n ’y a aucune raison d’utiliser de live region. En théorie, la présence de ces attributs s’il n’y a pas de rechargement ne devrait pas gêner. Mais certains lecteurs d’écran peuvent prendre des libertés par rapport aux spécifications et vocaliser des contenus tout de même. C’est pourquoi il faut être parcimonieux.

  Lorsqu’ils sont utiles et nécessaires, utiliser ces attributs pour informer d’un changement. Exemple : donner le nouveau nombre de résultats après utilisation de filtre. Mais il faut bien penser que dans plusieurs cas ils ne sont pas nécessaires, en effet, un bouton d’action doit être explicite avant qu’on appuie dessus. Donc par exemple : lorsque je demande à afficher la page 2 dans une pagination de résultat, il n’y a pas d’info à vocaliser automatiquement, le fait que le bouton dise "afficher la page 2" est suffisant, il serait superflu, voire gênant d’aller plus loin dans ce qui est vocalisé.

  Enfin, il faut gérer le focus clavier. Cet aspect est essentiel dès qu’il y a des interactions ajax, mais il dépend totalement du contexte. Et cet aspect est indépendant de la nécessité d’utiliser les live regions. Exemple : dans une série de filtre on va laisser le focus sur le filtre pour que l’utilisateur puisse parcourir la série de filtre. A contrario, dans une pagination (ou quand on a un bouton de type "afficher plus d’articles", dans des news ou dans une page de produits pour un site de e-commerce) on va déplacer le focus sur le 1er nouveau élément qui vient de s’afficher (la zone qui a été mise à jour).

• Anomalie #4128 (En cours) : Bug de génération de boucle avec les modèles Spip

  11 avril 2018, par Julien PORIAU

  Dans les modèles personnalisés Spip, les images (boucle documents ou logos) sont mal générées et provoque un bug d’encodage visible dans le front-end lors du passage dans une autre langue (balises multi).
  Nous n’avons pas trouvé où était le souci dans Spip, mais les caractères qui remontent dans le code source, ressemblent aux octets qui composent le fichier binaire d’une image.
  Voir en live ici : http://spip-dev.nidecker.com/probleme-de-langue.html?lang=ca.

  

  Pour essayer d’isoler cette anomalie, nous avons procédé de la sorte avec l’aide de mon développeur :

  1. Nous sommes reparti d’un SPIP 3.1.7 entièrement neuf (minimal), avec deux modèles Spip, rien d’autre.
  Le bug se reproduit, ce qui exclus un problème lié aux squelettes ou autres plugins.

  Nous n’avons pas réussi a déterminer précisément ce qui génère ce bug, à part que c’est dans un contexte où on appelle une langue pas définie dans le multi.
  En fonction du contenu de l’article, du nombre de modèles dans l’article, en fonction des boucles dans les inclure, le bug n’arrive pas au même endroit...

  Le problème vient de la génération des logos ou documents : si on supprime les balises #LOGO_* ou si on renomme IMG en IMG_, plus d’erreur.
  Même sans traitements, avec juste [(#LOGO_*)], rien à faire.

  2. Nous avons pensé que c’était peut être une image au mauvais format : On a alors tenté de passer ImageOptim sur tout le répertoire /IMG, redimensionné tous les logos en vignettes png de 320x240, rien à faire...

  3. On a fini par passer ce site de test en 3.2, pas mieux.

  4. Nous avons épluché les caches générés dans /tmp/cache et /tmp/cache/skel, tout paraît normal de ce côté là..

  5. On a ensuite un peu avancé en enlevant dans mes_options.php la variable $GLOBALS['forcer_lang'] = true".
  Sur la version minimal, plus de bug. Mais sur le site de production, le problème réside toujours.
  Mais en faisant des tests avec et sans (et en supprimant bien /tmp/cache/ à chaque fois), ça se confirme pour la version minimal.

  6. A partir d’une copie de la version production, nous avons désactivé tout les plugins, passer ImageOptim sur /IMG et rien a faire.. Impossible de déterminé d’où vient le problème :(

  7. Nous avons essayé d’écrire comme ceci : [<img src="http://core.spip.org/projects/spip/(#LOGO_MOT|image_reduire{50,*}|extraire_attribut{src})" alt="" style='max-width: 300px; max-height: 300px' />]
  Cela fonctionne sur la version minimal mais pas sur la version production.

  8. Dans la version minimal, j’ai encore récemment testé une dernière chose. J’ai supprimé les documents non sollicités sur ma page de teste (spip.php ?article1441&lang=ca).
  Avec la requête SQL suivante : DELETE FROM jones_documents WHERE id_document NOT IN (1948,1949,2534,2535,630,631,1783,1784,1785,1786,1787,1788,1781,1782)
  Le bug n’apparait plus..

  Je sèche..

  Vous trouverez ici en téléchargement une archive de la version minimal (Spip 3.1.7) : https://www.dropbox.com/s/dek0zg7jafl8uxe/jones.zip?dl=0] ( 20mo)
  Pour reproduire le bug, il suffit de passer la variable "&lang=ca" dans l’article 1441 (localhost/spip.php ?article1441&lang=ca).

  Je donne volontiers un accès à la version production si besoin.