Projet

Général

Profil

Development #52416

savoir rapprocher les champs selon leur identifiant lors de l'écrasement d'un formulaire avec un nouvel import

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

Statut:
Nouveau
Priorité:
Normal
Assigné à:
-
Version cible:
-
Début:
27 mars 2021
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:
Non

Description

Actuellement quand on écrase un formulaire par un nouvel import, on a une page qui présente les champs qui vont être modifiés/supprimés/ajoutés. Cette page se construit en regardant les "id" et les "type" de chaque champ.

Ce n'est pas souple, si on veut écraser avec un formulaire qui contient un champ avec l'identifiant "foo", il faut que l'existant ait le même id. Sinon, l'existant est supprimé et un nouveau champ est créé, vide.

Il faudrait prendre en compte que même si l'id est différent, la volonté est certainement que le nouveau champ "foo" est là pour remplacer l'existant.

Ce ticket pour définir :
  • quel serait l'algo à mettre en place pour savoir quel champ remplace quel autre : quelle priorité entre l'identifiant choisi par l'usager et l'id des champs, etc.
  • quelle UI présenter, est-ce qu'on y autoriserait des adaptations/validation (case à cocher) pour choisir si un écrasement doit avoir lieu ou pas, etc.

(le cas d'usage n'est pas si fréquent aujourd'hui, mais dans la perspective de Publik Studio et de la construction d'applis, ça va devenir indispensable d'avoir cette souplesse de remplacement des formulaires)

Historique

#1

Mis à jour par Stéphane Laget il y a environ 3 ans

En fait il est déjà fréquent aujourd'hui

#2

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

Je ne vois pas comment la situation est fréquente ou deviendrait plus fréquente, quelle procédure de développement amène à devoir rapprocher les champs selon l'identifiant (optionnel) des champs ?

(j'ai peur de quelque chose très casse gueule ici).

#3

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

Cas classique : on a un formulaire avec une date "form_var_date", sur le champ 32.

Sur le nouveau formulaire, le "form_var_date" a été tripoté (supprimé, recréé) et est maintenant sur le champ 76.

En écrasant le formulaire actuel avec le nouveau, on a une indication comme quoi le champ "date" va être supprimé. Et impossible de rétablir la situation sur le nouveau formulaire (impossible de redonner l'id 32 au champ date).

Formats disponibles : Atom PDF