Ignore:
Timestamp:
Nov 15, 2017, 12:47:31 AM (18 months ago)
Author:
rastapopoulos@…
Message:

Backport de [107571] : Revert d'une partie de [96181] : non on ne doit pas aller chercher les liens indirects sur une autre table que celle demandé. Cette modif casse complètement de nombreux squelettes qui marchaient bien avant (on vient seulement de le voir et comprendre pourquoi).

Le principe des tables de liens avec objet/id_objet c'est de pouvoir les utiliser sur les objets que l'on veut. Donc ensuite quand on demande les liens de rubrique pour les objets "patates", on VEUT les liens avec "patates", pas avec un autre objet calculé et remplacé en cachette comme ça. Quand on demande "les événements liés en polyhier aux rubriques de la branche 30" on veut bien les événements qui y sont liés, pas les événements des articles de cette branche ce qui n'a rien à voir.

Si des gens ont besoin d'une fonctionnalité différente en cherchant les articles parents liés, c'est autre chose, et il faudrait un autre critère ou bien un paramètre explicite supplémentaire à ce critère. Mais le fonctionnement normal, cohérent, toujours sur l'objet demandé, doit rester le même.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • _plugins_/polyhierarchie/branches/v2.0/polyhier_fonctions.php

    r100658 r107572  
    206206                        }
    207207                }
    208                 // si le champ id_rubrique est recuperer par jointure, c'est le type et la primary de la table jointe
    209                 // qu'il faut chercher dans la table spip_rubriques_liens (ie cas des evenements)
    210                 if ($cle AND $desc) {
    211                         $type = objet_type($boucle->from[$cle]);
    212                         $primary = $cle . "." . id_table_objet($boucle->from[$cle]);
    213                 }
    214208        }
    215209        else $cle = $boucle->id_table;
Note: See TracChangeset for help on using the changeset viewer.