Recherche avancée

Sur d’autres sites (8683)

• Anomalie #3654 (Nouveau) : Régression jointure en 3.1 ?

  15 janvier 2016, par tcharlss (*´_ゝ｀)

  Bonjour,

  La boucle suivante fonctionne en 3.0.21, mais pas en 3.1 :
  #ID_ABONNEMENT #NOM

  requête en SPIP 3 :
  SELECT L1.nom, abonnements.id_abonnement<br />FROM spip_abonnements AS `abonnements`  <br />INNER JOIN spip_auteurs AS L1 ON ( L1.id_auteur = abonnements.id_auteur )<br />WHERE (abonnements.statut = 'actif')

  requête en SPIP 3.1 :
  SELECT L2.nom, abonnements.id_abonnement<br />FROM spip_abonnements AS `abonnements`  <br />INNER JOIN spip_auteurs_liens AS L1 ON ( L1.id_objet = abonnements.id_abonnement AND L1.objet='abonnement') <br />INNER JOIN spip_auteurs AS L2 ON ( L2.id_auteur = L1.id_auteur )<br />WHERE (abonnements.statut = 'actif')<br />GROUP BY abonnements.id_abonnement

  En 3.1, il y a donc une jointure supplémentaire sur la table spip_auteurs_liens qui fait échouer la boucle.

  Anomalie constatée dans le plugin Abonnements : http://zone.spip.org/trac/spip-zone/browser/_plugins_/abonnements/trunk
  Dans la boucle, la jointure sur spip_auteurs est nécessaire afin de pouvoir trier sur la colonne ’nom’ : http://zone.spip.org/trac/spip-zone/browser/_plugins_/abonnements/trunk/prive/objets/liste/abonnements.html#L20
  À toute fin utile, la table spip_abonnement contient une clé id_auteur : http://zone.spip.org/trac/spip-zone/browser/_plugins_/abonnements/trunk/base/abonnements.php#L97

• Revision 84174 : Evolutions du plugin dont certaines peuvent être considérées comme des ...

  12 août 2014, par eric@… — Log

  Evolutions du plugin dont certaines peuvent être considérées comme des corrections :
   la page pages_tous devient pages ce qui est plus cohérent avec les autres objets.
   ajout et utilisation des autorisations classiques pour un obet ’page’ : creer, modifier et voir. Ces autorisations et les suivantes sont par défaut positionnées à admin complet. Une fonction surchargeable permet de toutes les modifier d’un coup.
   ajout de l’autorisation pages_voir pour afficher la liste des pages uniques (exec=pages)
   ajout des autorisations d’affichage des menus pages et pagecreer. Ces autorisations font appel respectivement à pages_voir et page_creer.
   utilisation du pipeline pre_boucle sur la boucle ARTICLES afin de clairement séparer les listes de pages uniques et celles d’articles éditoriaux. Par exemple, les listes d’articles de la page d’acceuil et de la page articles sont exemptes de pages uniques.
  Tout n’est pas parfait en particulier pour les autorisations car il est toujours possible d’accéder à une page unique en saisissant l’url même si on est pas autorisé. C’est en effet l’autorisation de l’article qui se déroule. Pour combler ce manque il faudrait surcharger l’autorisation de l’article en testant l’id de rubrique mais cela produirait des effets de bords avec d’autres plugins comme accès restreint.
  En fait, spécialiser un objet pour en créer un autre n’est pas une opération prévue dans l’api SPIP actuelle.
  Autre remarque : lors de la désinstallation du plugin on supprime la colonne ’page’ de la table spip_articles. On se retrouve avec des articles possédant un id_rubrique à -1. Est-ce bien de laisser cela ainsi ? Ne faudrait-il pas soit les supprimer soit les transférer dans une rubrique existante ?

• Revision 84174 : Evolutions du plugin dont certaines peuvent être considérées comme des ...

  12 août 2014, par eric@… — Log

  Evolutions du plugin dont certaines peuvent être considérées comme des corrections :
   la page pages_tous devient pages ce qui est plus cohérent avec les autres objets.
   ajout et utilisation des autorisations classiques pour un obet ’page’ : creer, modifier et voir. Ces autorisations et les suivantes sont par défaut positionnées à admin complet. Une fonction surchargeable permet de toutes les modifier d’un coup.
   ajout de l’autorisation pages_voir pour afficher la liste des pages uniques (exec=pages)
   ajout des autorisations d’affichage des menus pages et pagecreer. Ces autorisations font appel respectivement à pages_voir et page_creer.
   utilisation du pipeline pre_boucle sur la boucle ARTICLES afin de clairement séparer les listes de pages uniques et celles d’articles éditoriaux. Par exemple, les listes d’articles de la page d’acceuil et de la page articles sont exemptes de pages uniques.
  Tout n’est pas parfait en particulier pour les autorisations car il est toujours possible d’accéder à une page unique en saisissant l’url même si on est pas autorisé. C’est en effet l’autorisation de l’article qui se déroule. Pour combler ce manque il faudrait surcharger l’autorisation de l’article en testant l’id de rubrique mais cela produirait des effets de bords avec d’autres plugins comme accès restreint.
  En fait, spécialiser un objet pour en créer un autre n’est pas une opération prévue dans l’api SPIP actuelle.
  Autre remarque : lors de la désinstallation du plugin on supprime la colonne ’page’ de la table spip_articles. On se retrouve avec des articles possédant un id_rubrique à -1. Est-ce bien de laisser cela ainsi ? Ne faudrait-il pas soit les supprimer soit les transférer dans une rubrique existante ?