refonte gestion des imports et doublons #184

New Issue

jmtrivial · 2024-11-03T10:09:09+01:00

jmtrivial commented

2024-11-03 10:09:09 +01:00

Problème rencontré

Dès que l'on fait une modification locale d'un événement, au réimport cela créé des détections de doublons. La détection des doublons est d'ailleurs rendue assez compliquée à cause de ça.

Proposition

Les événements issus d'une importation ne sont pas modifiables par les humains
si on veut faire une modification à la main, ça créé un duplicat, et c'est cette version locale qui sera éditée, et notée dupliquée de l'événement initialement importé
dans un groupe d'événements dupliqués, il n'y a que 0 ou 1 version locale
quand une importation récurrente remarque une différence entre l'import et la version initiale, elle remplace la version importée précédemment, et si cet événement a une version locale, le "événements dupliqués" est noté non résolu pour que l'utilisateur puisse prendre connaissance des changements (si on garde aussi la version précédente pour montrer à l'utilisateur ce qui a changé, si la précédente était non publiée, on ne publie pas la nouvelle, et à l'inverse si la précédente était publiée, on dépublie la précédente et on publie la nouvelle)
pour l'utilisateur, résoudre un "événements dupliqués" consiste à :
- dans le cas où il n'y a pas de version locale (cas de deux sources disjointes pour un même événement, comme la coopé et arachnée concert), on peut choisir la version qui sera présentée en priorité à l'utilisateur
- s'il y a une version locale, on permet à l'utilisateur l'édition de cette version, en lui présentant pour chaque champ ce que contiennent les autres versions
quand on a résolu un "événements dupliqués", c'est toujours la version locale qui est mise en avant, sauf s'il n'y en a pas

En conséquence

quand on affiche aux utilisateurs un événement, si c'est une version locale, on lui indique les sources des versions dupliquées issues d'importation
quand on édite un événement, si on est sur un événement source, on tombe sur l'édition de l'événement dans sa version locale, qui est créée par duplication si elle n'existe pas encore
en mode édition, on peut demander à afficher les versions de chaque champ des événements issus de source
quand on affiche un événement issu d'une source externe, la catégorie et les tags affichés sont ceux de la version locale

Améliorations internes

Pour rendre plus rapide la base de données, on pourrait, au lieu d'avoir un booléen "fixed", avoir une clé étrangère qui pointe sur l'événement mis en avant. On pourrait alors enlever le booléen "masked" de chaque événement, et avoir accès directement à la version mise en avant associée à un événement que l'on consulte (avec un prefetch_related à deux niveaux)

Remarques

les outils automatiques de détection de lieu, de catégorie, et peut-être un jour de tags sont appliqués dès l'import sur les versions des événements issus de sources externes, car sauf modification, c'est eux qui sont affichés.

### Problème rencontré Dès que l'on fait une modification locale d'un événement, au réimport cela créé des détections de doublons. La détection des doublons est d'ailleurs rendue assez compliquée à cause de ça. ### Proposition * Les événements issus d'une importation ne sont pas modifiables par les humains * si on veut faire une modification à la main, ça créé un duplicat, et c'est cette version locale qui sera éditée, et notée dupliquée de l'événement initialement importé * dans un groupe d'événements dupliqués, il n'y a que 0 ou 1 version locale * quand une importation récurrente remarque une différence entre l'import et la version initiale, elle remplace la version importée précédemment, et si cet événement a une version locale, le "événements dupliqués" est noté non résolu pour que l'utilisateur puisse prendre connaissance des changements (si on garde aussi la version précédente pour montrer à l'utilisateur ce qui a changé, si la précédente était non publiée, on ne publie pas la nouvelle, et à l'inverse si la précédente était publiée, on dépublie la précédente et on publie la nouvelle) * pour l'utilisateur, résoudre un "événements dupliqués" consiste à : * dans le cas où il n'y a pas de version locale (cas de deux sources disjointes pour un même événement, comme la coopé et arachnée concert), on peut choisir la version qui sera présentée en priorité à l'utilisateur * s'il y a une version locale, on permet à l'utilisateur l'édition de cette version, en lui présentant pour chaque champ ce que contiennent les autres versions * quand on a résolu un "événements dupliqués", c'est toujours la version locale qui est mise en avant, sauf s'il n'y en a pas ### En conséquence * quand on affiche aux utilisateurs un événement, si c'est une version locale, on lui indique les sources des versions dupliquées issues d'importation * quand on édite un événement, si on est sur un événement source, on tombe sur l'édition de l'événement dans sa version locale, qui est créée par duplication si elle n'existe pas encore * en mode édition, on peut demander à afficher les versions de chaque champ des événements issus de source * quand on affiche un événement issu d'une source externe, la catégorie et les tags affichés sont ceux de la version locale ### Améliorations internes * Pour rendre plus rapide la base de données, on pourrait, au lieu d'avoir un booléen "fixed", avoir une clé étrangère qui pointe sur l'événement mis en avant. On pourrait alors enlever le booléen "masked" de chaque événement, et avoir accès directement à la version mise en avant associée à un événement que l'on consulte (avec un prefetch_related à deux niveaux) ### Remarques * les outils automatiques de détection de lieu, de catégorie, et peut-être un jour de tags sont appliqués dès l'import sur les versions des événements issus de sources externes, car sauf modification, c'est eux qui sont affichés.

jmtrivial added the

architecture

importation

modélisation

labels 2024-11-03 10:09:09 +01:00

SebF commented

2024-11-03 18:10:13 +01:00

dans le cas de résolution d’évènement sans version locale mais plusieurs sources (l’exemple coopé/arachnée) déjà publié : présentation des changements ou mise à jour de la version publiée choisie ? Ma préférence va à la maj pour limiter le traitement humain.
ok pour la FK pour lier les différentes versions d’un évènement plutôt que de devoir faire une recherche plus ou moins complexe (lié avec #17 ?)

- dans le cas de résolution d’évènement sans version locale mais plusieurs sources (l’exemple coopé/arachnée) déjà publié : présentation des changements ou mise à jour de la version publiée choisie ? Ma préférence va à la maj pour limiter le traitement humain. - ok pour la FK pour lier les différentes versions d’un évènement plutôt que de devoir faire une recherche plus ou moins complexe (lié avec #17 ?)

jmtrivial commented

2024-11-03 21:43:32 +01:00

sur le premier point, je pensais au scénario suivant:

on importe un événement depuis la source A
on importe un événement depuis la source B
les événements sont détectés comme le même
Dans ce cas, on demande à l'utilisateur lequel il souhaite mettre en avant en priorité.
Puis les mises à jour se font sans changer la version mise en avant.

sur le premier point, je pensais au scénario suivant: - on importe un événement depuis la source A - on importe un événement depuis la source B - les événements sont détectés comme le même Dans ce cas, on demande à l'utilisateur lequel il souhaite mettre en avant en priorité. Puis les mises à jour se font sans changer la version mise en avant.

jmtrivial referenced this issue from a commit

2024-11-09 23:01:51 +01:00

Migration au nouveau paradigme de dupliqués

jmtrivial closed this issue

2024-11-09 23:01:51 +01:00

jmtrivial commented

2024-11-10 23:34:25 +01:00

Avec a3255ff460 on commence à avoir quelque chose de solide

Avec a3255ff460 on commence à avoir quelque chose de solide

jmtrivial reopened this issue

2024-11-10 23:34:25 +01:00

jmtrivial closed this issue