Ignore:
Timestamp:
Nov 15, 2017, 12:46:06 AM (3 years ago)
Author:
rastapopoulos@…
Message:

Revert d'une partie de [96182] : 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/trunk/polyhier_fonctions.php

    r100659 r107571  
    218218                        }
    219219                }
    220                 // si le champ id_rubrique est recuperer par jointure, c'est le type et la primary de la table jointe
    221                 // qu'il faut chercher dans la table spip_rubriques_liens (ie cas des evenements)
    222                 if ($cle AND $desc) {
    223                         $type = objet_type($boucle->from[$cle]);
    224                         $primary = $cle . "." . id_table_objet($boucle->from[$cle]);
    225                 }
    226220        }
    227221        else {
Note: See TracChangeset for help on using the changeset viewer.