Project

General

Profile

Anomalie #3566

Roadmap #3936: Refonte des révisions

Restaurer une révision ne restaure pas toujours tous les champs modifiés

Added by marcimat 🌈 almost 4 years ago. Updated 10 months ago.

Status:
Fermé
Priority:
Haut
Assignee:
-
Target version:
Start date:
10/12/2015
Due date:
% Done:

0%

Resolution:
fixed
Navigateur:

Description

Deux cas de figure remarqués :

Cas A
- Créer une version avec un champ révisable vide, par exemple un article avec un texte vide.
- Modifier cet article en ajoutant un texte
- Si l'on fait afficher l'historique des modifications, et qu'on demande à Restaurer la version précédente, le texte est rempli avec le contenu actuel, alors qu'il était vide à la version précédente.

Cas B
- Créer plusieurs révisions sur des champs différents (pour aller vite, alterner des modifications entre 2 auteurs, sinon il faut attendre un certain temps si on utilise le même auteur pour que les modifications fassent des révisions différentes)
- Imaginons qu'on a effectué 7 révisions, et qu'on affiche dans l'historique des modifications la différence entre la version 7 et la version 2
- On voit l'ensemble des champs modifiés
- En cliquant alors le lien «Restaurer la version n°2», seuls les champs modifiés par la version n°2 apparaissent changés dans le formulaire. Les champs modifiés ENTRE la version courante et la version 2 ne reviennent pas au contenu qu'ils avaient en version 2. Du coup, tout ne revient pas dans l'état de modification de la version 2

Ce me semble 2 bugs assez ennuyant.


Related issues

Related to SPIP - Anomalie #2238: Révision (Version initiale) : IP au lieu d'id_auteur Fermé 08/21/2011
Related to SPIP - Evolution #3238: API éditer objet / fonction objet_inserer : associer l'auteur *avant* l'appel du pipeline post_insertion Fermé 06/28/2014
Related to Révisions - Anomalie #4127: Bug de version initiale ? Fermé 04/09/2018

History

#1 Updated by marcimat 🌈 almost 4 years ago

Valable en 3.0 et 3.1

#2 Updated by marcimat 🌈 almost 4 years ago

Précisions :
- La version 1 semble souvent correctement rétablie (il semble qu'elle contienne l'ensemble des champs dans spip_versions pour cette version). Ce n'est pas le cas des versions >= 2.
- Problèmes identiques en 2.1 ; ce ne sont donc pas je crois des problèmes survenus suite au passage à tous objets éditoriaux.

#3 Updated by xdjuj - over 3 years ago

C'est réparé sur SPIP ?

#4 Updated by marcimat 🌈 almost 3 years ago

  • Priority changed from Normal to Haut
  • Target version changed from 3.0 to 3.1

J'ai encore un autre cas … C'est tout de même très gênant.

Prenons un article avec 2 champs : texte et ps.
Mettons dedans ces textes (en alternant l'auteur pour créer une révision systématiquement)
Révision 1 : texte = A, ps = A
Révision 2 : texte = B,
Révision 3 : ps = C
Révision 4 : texte = D

On a donc là en révision 4 : texte = D, ps = C.
Si on restaure la révsion 3, on devrait avoir : texte = B, ps = C
Hors, comme le champ 'texte' n'a pas été modifié en révision 3, le champ texte ne se restaure pas.

Si on restaure la révision 2, on a bien le champ texte (il est modifié par la révision 2), mais cette fois le PS ne change pas (même principe).

#5 Updated by marcimat 🌈 almost 3 years ago

On avance… le commit http://zone.spip.org/trac/spip-zone/changeset/99883 améliorera une fois la fonction utilisée.

Cependant la première révision actuellement n'enregistre que la liaison auteur/article, et non l'ensemble des champs saisies.
J'ai fini par comprendre que révisions se base sur 'post_insertion' (qui a donc l'id_article créé) pour lever un flag permettant d'éviter de créer la première révision avant d'arriver dans post_edition.
Bien. Sauf que… avant 'post_insertion', l'appel de auteur_associer($id_auteur, array('article' => $id_article)); dans auteur_inserer() crée la première révision (le flag n'étant pas encore levé). Cette fonction appelant à un moment 'pre_edition_liens', que le plugin Révisions écoute.

#6 Updated by marcimat 🌈 almost 3 years ago

Ce flag avait été introduit par http://zone.spip.org/trac/spip-zone/changeset/50708 au fait. Donc pour corriger https://core.spip.net/issues/2238

#7 Updated by marcimat 🌈 almost 3 years ago

  • Related to Anomalie #2238: Révision (Version initiale) : IP au lieu d'id_auteur added

#9 Updated by marcimat 🌈 almost 3 years ago

  • Related to Evolution #3238: API éditer objet / fonction objet_inserer : associer l'auteur *avant* l'appel du pipeline post_insertion added

#10 Updated by marcimat 🌈 almost 3 years ago

Je confirme que ça remarche (et parfaitement avec la nouvelle fonction) en remettant l'appel à auteur_associer() après le pipeline post_edition.
Le problème se situe donc bien à ce niveau. Il va falloir trouver comment permettre de dire à Révisions de lever le flag plus tôt que post_insertion… avant donc le passage à pre_insertion_liens ;

ou réussir à lui faire lever ce flag dans pre_insertion_liens en transmettant un paramètre indiquant que c'est le premier lien ici (mais ça ferait passer ce paramètre de auteur_associer() jusqu'au pipeline dans un grand nombre de fonction. Pas idéal non plus.

Un pipeline trig_insertion() juste après l'obtention de l'identifiant ? …

#11 Updated by cedric - about 2 years ago

  • Parent task set to #3936

#12 Updated by cedric - about 2 years ago

  • Target version changed from 3.1 to 3.3

#13 Updated by marcimat 🌈 10 months ago

#14 Updated by cedric - 10 months ago

  • Status changed from Nouveau to Fermé
  • Target version changed from 3.3 to 3.2
  • Resolution set to fixed

Also available in: Atom PDF