Recherche avancée

Sur d’autres sites (6622)

• Anomalie #3408 : Ergo : incoherence entre l’accès au formulaire instituer et si on a vraiment le d...

  9 février 2021, par Maïeul Rouquette

  Pour reproduire le bug.

  Ajouter dans mes_options.php les lignes suivantes

  $GLOBALS[’spip_pipeline’][’autoriser’] .= "|mes_autorisations" ;
  function mes_autorisations()
      function autoriser_article_instituer($faire, $type, $id, $qui, $opt) 
          return true ;
      
  
  

  Se connecter en tant que simple auteur/autrice

  On voit qu’on peut publier un article dans le formulaire de changement de statut. Mais lorsqu’on choisit de le faire, le statut n’est pas modifié !

  A noter que par rapport au code de b_b, mais aussi à mon analyse initiale, $v[’id_rubrique’] est systématiquement null.
  Voici mes pistes :
  - `formulaire_editer_objet_charger` devrait renvoyer un id_rubrique (+ corriger le id_parent qui est null dans mon cas !) https://git.spip.net/SPIP/spip/src/branch/master/ecrire/inc/editer.php#L200
  - il y a 2 fois le test de si on a le droit de publier : dans objet_instituer https://git.spip.net/SPIP/spip/src/branch/master/ecrire/action/editer_objet.php#L332 + dans la fonction verifier du formulaire https://git.spip.net/spip/spip/src/branch/master/prive/formulaires/instituer_objet.php#L146 > c’est ceinture et bretelle. je sais pas si c’est pertinent de garder les deux, a priori dans objet_instituer cela suffit non ?

• Anomalie #3408 : Ergo : incoherence entre l’accès au formulaire instituer et si on a vraiment le d...

  5 février 2021, par RastaPopoulos ♥

  Si j’ai bien compris, il n’est pas dit que c’est avoir les deux autorisations qui est incohérent, ça à la limite pourquoi pas… (même s’il me semble qu’il ne devrait y avoir qu’une seule autorisation dédiée appelée, donc "instituer" et DANS celle-ci ça devrait tester "publierdans" du parent non ?)
  C’est que si on autoriser "instituer" pour un objet et bien ça affiche le choix possible de le faire dans l’interface, alors qu’en fait la personne n’a pas le droit si pas aussi "publierdans".

  Et donc la résolution ça serait plutôt que pour l’affichage aussi (pour charger) il faut tester les deux, s’il faut les deux pour verifier, non ?

  Ce n’est pas logique, et donc bien un bug ergo, si on laisse à la personne la possibilité d’utiliser le formulaire alors qu’elle n’en a pas le droit en vrai.

  Donc je vois pas trop pourquoi on fermerait, même si on corrige pas tout de suite…

• Anomalie #4537 (Nouveau) : {tri} oubli d’implémenter "sinum" qui existe pour {par}

  10 août 2020, par RastaPopoulos ♥

  Normalement, on doit pouvoir trier pareil, à part que tri est mieux car dynamique. Mais tri sinum XXX plante avec Unknown column ’sinumXXX’ in ’order clause’

  Car la fonction tri_champ_order() implémente "multi", "num", mais pas "sinum". Vu qu’on s’attend logiquement à pouvoir utiliser pile la même chose dans les deux critères, d’après moi c’est bien un bug que ça ne marche pas comme attendu (et pas un truc manquant à faire évoluer).
  https://git.spip.net/SPIP/spip/src/branch/master/ecrire/public/fonctions.php#L262

  C’est d’ailleurs un peu dommage de pas pouvoir mutualiser du code et de devoir implémenter à chaque fois deux fois les différents cas, une fois pour par puis une fois pour tri. :(
  Mais bon comme c’est vraiment pas fait pareil apparemment…