Pouvoir avoir plusieurs jeux de données destinataires dans un import

[joelclems]

• Dans les données : pouvoir ajouter une colonne renseignant l'uuid de jeux de données
• Pouvoir associer ces uuid à des jeux de données présents en base

[lpojgc]

Cet ajout serait effectivement un très gros plus et pourrait faire gagner beaucoup de temps ! Actuellement on importe en lot et on met ensuite à jour en bdd pour rattacher aux bons jdd

[DonovanMaillard]

C'est aussi un très gros sujet :)

Ca implique de ne plus sélectionner de JDD en début de saisie, de trouver comment on controle qui a les droits d'écrire dans tel ou tel jdd, d'importer des données dans un JDD dont l'uuid n'est pas connu dans le module métadonnées, de gérer les jeux inactifs ou non rattachés au module d'import... ça fait pas mal de choses :)

[bouttier]

Il est prévu de faire évoluer le module d’import pour alimenter d’autres destinations. À ce titre, ce besoin est également présent pour d’autres destination telle que Occhab, destination pour laquelle le standard d’échange prévoit la spécification du JDD dans une colonne metadonneeId ou jddMetaId. Par ailleurs, lorsque l’on importe des Habitats, on souhaite pouvoir préciser la station par une colonne du fichier source, ou alors, dans le cas où le fichier contient des habitats d’une seule station, on souhaite pouvoir spécifier la station en paramètre de l’import.

Ainsi, deux fonctionnalités sont attendues :

• Pouvoir rajouter une colonne virtuelle avec une valeur constante (cas du JDD actuellement, mais pourrait être un numéro de station)
• Dans le cas d’une colonne de JDD, être capable de contrôler les permissions sur ces derniers ligne par ligne (et non pas globalement comme actuellement)

[joelclems]

il faudrait renseigner l'id du jdd ou l'uuid ?

[camillemonchicourt]

On prévoit plutôt de ne jamais utiliser les ID internes de la BDD pour les imports. Mais plutôt les UUID (pour les données) ou des codes (pour les référentiels).