Ticket #1365 (closed defect: fixed)
L'utilisation de behaviors liés aux catégories provoque des problèmes d'ordre
Reported by: | zeiram | Owned by: | sogox |
---|---|---|---|
Priority: | normal | Milestone: | 2.5.2 |
Component: | module:core | Version: | 2.4 |
Severity: | normal | Keywords: | catégorie, behavior |
Cc: |
Description
L'utilisation des behaviors adminAfterCategoryCreate et adminAfterCategoryUpdate perturbe l'ordonnancement des catégories.
Cas test :
- soit un plugin qui utilise le behavior adminAfterCategoryCreate et qui ne fait que resauvegarder la catégorie :
$core->addBehavior('adminAfterCategoryCreate',array('testBugCatOrderAdminBehaviours','coreAfterCategorySave')); class testBugCatOrderAdminBehaviours { public static function coreAfterCategorySave ($cur,$id=null) { global $core; $core->blog->updCategory($id, $cur); } }
- soit un blog ayant deux catégories "imbriquées" : "b" est l'enfant de "a" (a / b).
- l'utilisateur veut ajouter une nouvelle catégorie "c" comme enfant de "a".
Résultat attendu : les catégories "b" et "c" sont sœurs : a / b et a / c. (Note : et c'est bien ce qui se produit sans l'existence du plugin décrit ci-dessus. Le bug n'apparaît que lorsqu'on essaie d'utiliser ces behaviors pour modifier la catégorie qui vient d'être créée.)
Résultat obtenu : "c" devient enfant de "b" : a / b / c.
Le souci est également présent à l'appel du behavior adminAfterCategoryUpdate et si on essaie de réordonner les catégories depuis leur écran propre. Il n'y a plus que deux solution pour réparer la situation : désactiver le plugin et refaire tout l'ordonnancement des catégories ou intervenir directement en base de données.
(Évidemment, le plugin qui m'a fait découvrir ce problème a un but plus intéressant que simplement resauvegarder la catégorie. ;-) )
Change History
comment:2 Changed 11 years ago by franck
Par contre j'ai du mal à voir où mettre en place un correctif qui permettrait de se passer du contournement.
Si quelqu'un veut regarder…
comment:4 Changed 11 years ago by sogox
Fixé avec le commit https://bitbucket.org/sogos/dotclear/commits/fce53a81a4d8d068a852ded6971a2a284ec2d360 en attente de validation par FrankPaul?
comment:7 Changed 11 years ago by franck <carnet.franck.paul@…>
- Status changed from new to closed
- Resolution set to fixed
(In [797b03c6a9ef]) Fix category cursor before corresponding behaviour, fixes #1365, thanks sogos/sogox for patch and tests
J'ai du mal à comprendre pourquoi le bug persiste dans le cas de la modification, par contre pour la création, je pense que ça vient du fait que les champs cat_lft et cat_rgt ne sont pas mis à jour dans le curseur, une fois le nœud créé.
Un contournement possible :
Où j'applique la mise à jour des champs idoines après lecture dans la base.