Recherche avancée

Sur d’autres sites (8970)

• Anomalie #3695 (Nouveau) : Édition d’un auteur et autocompletion des login/mot de passe

  13 février 2016, par tcharlss (*´_ゝ｀)

  Reproduire¶

  Voici ce que j’obtiens quand j’édite un auteur sous firefox developer edition 46, que soit un auteur existant ou un nouvel auteur (image également en pj) :
  

  Les champs login et mot de passe sont pré-remplis avec mes informations de connexion quelque soit l’auteur, par contre le mot de passe de confirmation est vide.
  Du coup quand il s’agit de mon profil, je suis obligé soit de vider le mot de passe, soit de le confirmer.
  Et quand il s’agit d’un nouvel auteur, il faut penser à changer les 2 champs.

  Solution ?¶

  Bon il n’agit pas d’un bug de SPIP, mais d’un souci dû l’autocomplétion des champ login/mot de passe des navigateurs. Et je n’ai pas constaté le problème avec les 2 autres navigateurs testés : firefox 44 normal et chromium 48.
  Si j’ai bien compris, certaines fonctionnalités de l’édition développeur arriveront à terme dans la version de base, peut-être que le problème s’y présentera aussi dans les prochaines versions.
  Donc lors de la création de mon profil, j’avais demandé d’enregistrer mes informations de connexion dans le gestionnaire de mot de passe, et maintenant il fait du zèle.
  Je ne sais pas si on peut y faire grand chose, mais au moins le problème est référencé.
  JLuc avait indiqué un rapport de bug / commentaire de commit firefox en rapport sur IRC, mais je ne retrouve pas le lien.

• Anomalie #3686 : formulaire_editer_article_verifier : vérification incomplète

  21 février 2016, par Peet du

  La ligne https://core.spip.net/projects/spip/repository/entry/spip/prive/formulaires/editer_article.php#L157, vient de
  https://core.spip.net/issues/2508.

  L’avantage (?) de https://core.spip.net/projects/spip/repository/revisions/19075, c’est que ça gère aussi bien les cas de création et de modification d’un article dans une rubrique interdite.

  J’ai donc testé mon patch avec le cas d’un admin restreint et il n’y a pas d’effet de bord : ceci grâce à autoriser_article_modifier().

  Il est donc question ici de compléter/corriger cette demande : il doit être possible de voir et de modifier, même si il est interdit de créer.

  Le bug que j’ai trouvé :¶

  C’est le cas qui se présente avec le plugin LIM

  1- un article ou des articles ont été créés dans une rubrique ;
  2- puis le webmestre décide plus tard d’interdire la création de nouveaux articles dans cette même rubrique, ceci grâce à une fonction du plugin LIM ;
  3- Mais si il n’est plus possible de créer un article dans cette rubrique, LIM gère le cas où l’auteur veut les modifier ses articles présents dans cette rubrique.

  Donc le bug soulevé vient du fait que le plugin LIM surcharge l’autorisation autoriser_rubrique_publierdans(). Plus exactement, il ajoute une condition.
  voir http://zone.spip.org/trac/spip-zone/changeset/95014/_plugins_/lim/trunk/lim_autorisations.php.

  Je précise que cette fonctionnalité du plugin LIM pose un problème seulement avec l’objet Article. Pas avec les autres objets éditoriaux.

  Voilà. J’espère n’avoir rien oublié.

• Anomalie #3894 : Jointures (erronées ?) avec les boucles documents et leurs critères

  27 janvier 2017, par marcimat ☺☮☯♫

  Les cas objet / id_objet¶

  En appelant page=test&objet=rubrique&id_objet=1 :

  - (DOCUMENTS){objet?}{id_objet?}
  - (DOCUMENTS){id_objet?}{objet?}
  - (DOCUMENTS){objet?}{id_objet?}{vu=non}
  - (DOCUMENTS){id_objet?}{objet?}{vu=non}
  - (DOCUMENTS){vu=non}{id_objet?}{objet?}
  Jointures correctes : 1 seule jointure L1 sur spip_documents_liens

  - (DOCUMENTS){id_article?}{objet?}{id_objet?}
  Jointure incorrecte : il y a 2 jointures différentes pour objet & id_objet
  

  SELECT documents.fichier
  FROM spip_documents AS `documents`  
  INNER JOIN spip_documents_liens AS L3 ON ( L3.id_document = documents.id_document ) 
  INNER JOIN spip_documents_liens AS L2 ON ( L2.id_document = documents.id_document )
  WHERE (documents.statut = ’publie’)
      AND (documents.mode IN (’image’,’document’))
      AND (documents.taille > 0 OR documents.distant=’oui’)
      AND (L2.objet = ’rubrique’)
      AND (L3.id_objet = 1)
  GROUP BY documents.id_document
  

  - (DOCUMENTS){id_article?}{objet?}{id_objet?}{vu=non}
  Même comportement erroné, avec vu sur L1 et 2 jointures pour objet & id_objet :
  

  SELECT documents.fichier
  FROM spip_documents AS `documents`  
  INNER JOIN spip_documents_liens AS L3 ON ( L3.id_document = documents.id_document ) 
  INNER JOIN spip_documents_liens AS L2 ON ( L2.id_document = documents.id_document ) 
  INNER JOIN spip_documents_liens AS L1 ON ( L1.id_document = documents.id_document )
  WHERE (documents.statut = ’publie’)
      AND (documents.mode IN (’image’,’document’))
      AND (documents.taille > 0 OR documents.distant=’oui’)
      AND (L2.objet = ’rubrique’)
      AND (L3.id_objet = 1)
      AND (L1.vu = ’non’)
  GROUP BY documents.id_document
  

  Il me semble que les jointures objet / id_objet ne fonctionnent que s’ils sont les premiers critères optionnels créant possiblement une jointure de la boucle.
  Cependant (DOCUMENTS){vu?}{objet?}{id_objet?} fonctionne aussi avec vu optionnel (1 seule jointure).