Projet

Général

Profil

Bug #54889

sources de données agendas automatiques, changement de nom et incohérence lors de l'export/import

Ajouté par Thomas Noël il y a presque 3 ans. Mis à jour il y a presque 3 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
15 juin 2021
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

Description

(d'un client perspicace)

Le changement de nom d'un agenda après création des sources de données automatiques associées, ne se répercute pas sur l'identifiant de la source de données (même après actualisation de l'agenda).

Dans le principe ça semble plutôt une bonne chose, puisque l'ancienne source de données est possiblement utilisée dans le formulaire et continue donc de fonctionner...

En revanche, c'est problématique lors de l'export/import : l'import de l'agenda donne lieu à la création d'une source de donnée dont l'identifiant est nouveau (ne se base pas sur celui exporté) : l'import d'un formulaire par la suite est donc naturellement "bloqué" car la source de donnée est inconnue.


Fichiers

Révisions associées

Révision f48199fa (diff)
Ajouté par Lauréline Guérin il y a presque 3 ans

datasource: set slug of chrono datasources (#54889)

Historique

#1

Mis à jour par Thomas Noël il y a presque 3 ans

  • Projet changé de Publik à Chrono
  • Club Non supprimé

Je pose ça dans Chrono car une piste pourrait être que le système d'import d'agendas propose/impose le respect des identifiants exportés.

#3

Mis à jour par Frédéric Péters il y a presque 3 ans

Tu parles d'identifiant ("identifiant est nouveau") les sources de données ne se basent pas sur les slugs ? (je vérifie et elles le font).

Le soucis ici c'est qu'un export/import ne conserverait pas les slugs ?

#4

Mis à jour par Thomas Noël il y a presque 3 ans

Je ne sais pas trop de qul identifiant on parle finalement, car dans l'import_json d'un agenda je vois bien :

        agenda, created = cls.objects.get_or_create(slug=data['slug'], defaults=data)

donc a priori effectivement les slugs ne devraient pas changer.

Je vais demander des détails au client.

#5

Mis à jour par Lauréline Guérin il y a presque 3 ans

dans wcs:

        datasource = existing_datasources.get(url)
        if datasource is None:
            datasource = NamedDataSource()
            datasource.external = 'agenda'
            datasource.data_source = {'type': 'json', 'value': url}
        datasource.external_status = None  # reset
        datasource.name = agenda['text']
        datasource.store()

On ne précise pas le slug de la datasource, il est généré à partir du name.
Si l'agenda change de label, agenda['text'] aussi, on se retrouve avec une nouvelle source de donnée.

=> il faudrait prendre agenda['id'] (== slug de l'agenda côté chrono) pour en faire un slug de datasource ?

note: comment ne pas casser les sources de données agenda existantes lors d'un refresh, si on change ça ?

#6

Mis à jour par Thomas Noël il y a presque 3 ans

  • Projet changé de Chrono à w.c.s.

Lauréline Guerin a écrit :

=> il faudrait prendre agenda['id'] (== slug de l'agenda côté chrono) pour en faire un slug de datasource ?

Ouaip.

note: comment ne pas casser les sources de données agenda existantes lors d'un refresh, si on change ça ?

Je crois qu'on pourrait chercher à avoir un fonctionnement à la "update_or_create" :
  • si une datasource de type external=agenda avec une même id existe déjà, alors on la met à jour
  • sinon on fait comme le code actuelle, juste un store() qui va se débrouiller à créer un nouvel id

(et je passe ce ticket sur w.c.s. parce que c'est bien là qu'est le "bogue", donc)

#7

Mis à jour par Lauréline Guérin il y a presque 3 ans

  • Projet changé de w.c.s. à Chrono
  • Assigné à mis à Lauréline Guérin
#8

Mis à jour par Lauréline Guérin il y a presque 3 ans

  • Projet changé de Chrono à w.c.s.
#9

Mis à jour par Lauréline Guérin il y a presque 3 ans

voila, ça ne touche pas à l'existant; seules les nouvelles datasources prendront ce nouveau slug

#10

Mis à jour par Thomas Noël il y a presque 3 ans

« datasource3.slug == 'chrono-ds-slug-A' » il ne faut pas avoir de "-" sinon on ne peut pas utiliser ces slug dans des expressions du genre data_source.agenda_truc (rarement utilisé, mais.). Ajoute une passe de "misc.simplify(..., space='_')" si tu veux t'assurer le truc.

(Je constate d'ailleurs un bogue dans get_new_slug qui fait des xxx-1 / xxxx-2 quand le slug existe déjà, zou, #54979)

Aussi, quand un slug "chrono_ds_slug_A" est déjà pris on pourrait chercher à avoir "chrono_ds_slug_A_1" et donc faire que get_new_slug puisse partir d'une base « def get_new_slug(self, base=None) » -- tu pourrais alors t'éviter le try/except dans la création d'une nouvelle source et faire juste « datasource.slug = datasource.get_new_slug(base='chrono_ds_%s' % agenda['slug']) »

#12

Mis à jour par Frédéric Péters il y a presque 3 ans

  • Statut changé de Solution proposée à Solution validée
#13

Mis à jour par Lauréline Guérin il y a presque 3 ans

  • Statut changé de Solution validée à Résolu (à déployer)
commit f48199fa92549dddd89cdc9cbcef19aa97370032
Author: Lauréline Guérin <zebuline@entrouvert.com>
Date:   Fri Jun 18 11:38:50 2021 +0200

    datasource: set slug of chrono datasources (#54889)
#14

Mis à jour par Frédéric Péters il y a presque 3 ans

  • Statut changé de Résolu (à déployer) à Solution déployée

Formats disponibles : Atom PDF