Project

General

Profile

Development #67710

Permettre le déplacement d'une page par l'import

Added by Valentin Deniaud 6 months ago. Updated 22 days ago.

Status:
Solution proposée
Priority:
Normal
Target version:
-
Start date:
26 July 2022
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

Description

Dans l'import/export, on identifiait une page par son slug.

Mais à différents endroits de la hiérarchie il peut y avoir les pages avec le même slug. Donc on a fait #59509 : désormais une page est identifiée par sa position dans la hiérarchie des pages.

Comme explicité dans #59509#note-8, cela change le comportement qui permettait de déplacer une page lors de l'import, à la place on en crée toujours une nouvelle.

Est-ce qu'on n'ajouterait pas un champ UUID au modèle Page, ainsi toute page est facilement identifiée de manière unique, éliminant le besoin de se baser sur un critère changeant de position dans la hiérarchie ?

Le principal inconvénient ça me paraît être une page qui aurait été recyclée pour en faire tout autre chose, alors l'import de la page initiale dont personne ne se rappelle qu'elle l'est déclenchera une mise à jour inattendue, mais c'est sûrement marginal.


Related issues

Related to Publik - Bug #72733: Documentation : server error 500 sur certains snapshotFermé22 December 2022

Actions

History

#1

Updated by Pierre Cros 3 months ago

Comme il me semble que c'est nécessaire pour inclure combo dans l'applification, ce serait bien d'avoir ça.

Je viens de faire mon premier déploiement en prod en créant / exportant / important une appli depuis la plate-forme de test et c'est super mais les 2 combos manquent.

#2

Updated by Lauréline Guérin about 2 months ago

Si on ajoute un uuid, avec une migration pour renseigner le legacy, et qu'on se base sur cet uuid pour l'import, alors pour le legacy, on ne pourra plus faire d'import de recette vers prod, car les pages existeront déjà en prod avec un uuid généré par la migration (et pas le même que dans le fichier d'import).

Si on ajoute un uuid, nullable, sans migration pour le legacy, en ne renseignant l'uuid que pour les nouvelles pages, alors il faut lors de l'import gérer les cas avec uuid/sans uuid (pas forcément évident), et le legacy continuera à marcher moyen sur l'export/import.

Des avis ?

#3

Updated by Valentin Deniaud about 2 months ago

Lauréline Guérin a écrit :

Si on ajoute un uuid, avec une migration pour renseigner le legacy, et qu'on se base sur cet uuid pour l'import, alors pour le legacy, on ne pourra plus faire d'import de recette vers prod, car les pages existeront déjà en prod avec un uuid généré par la migration (et pas le même que dans le fichier d'import).

Et si dans la migration au lieu d'avoir un uuid random on fais un hash des slugs qui servent actuellement à identifier une page ? On devrait bien retomber sur même uuid en recette et en prod, avec pas de legacy à traîner.

#4

Updated by Frédéric Péters about 1 month ago

  • Related to Bug #72733: Documentation : server error 500 sur certains snapshot added
#5

Updated by Lauréline Guérin 25 days ago

  • Assignee set to Lauréline Guérin
#6

Updated by Gitea (Bot) Gitea 25 days ago

  • Status changed from Nouveau to En cours

Lauréline Guérin (lguerin) a ouvert une pull request sur Gitea concernant cette demande :

#7

Updated by Lauréline Guérin 22 days ago

  • Status changed from En cours to Solution proposée

Also available in: Atom PDF