Saisie simultanée dans la ligne vide du bas d'une table : la ligne d'une personne est remplacée par celle d'une autre

Hello tout le monde,

Nous utilisons Grist sur LaSuite (grist.numerique.gouv.fr). Nous rencontrons un problème quand deux personnes ajoutent une ligne en même temps dans la même table.

Contexte

  1. La personne A commence à saisir une nouvelle ligne dans la ligne vide du bas.

  2. Pendant ce temps, la personne B crée aussi une ligne.

  3. Résultat : la ligne commencée par A est remplacée par celle créée par B, et la saisie de A n’apparaît plus comme une ligne distincte.

Nous avons rencontré ce cas plusieurs fois avec 2 personnes en simultané.

Mon hypothèse :
La ligne vide en bas d’une table Grist est une ligne « virtuelle » : l’enregistrement n’existe pas encore quand la personne A commence à taper. Il n’est créé qu’au moment où elle valide sa première cellule. Si la personne B crée une vraie ligne pendant ce temps, la table de A se met à jour, la ligne vide est repoussée d’un cran, et le curseur ou l’éditeur de A se retrouve sur la ligne de B. Sa saisie est alors perdue ou écrase une cellule de B. Les deux lignes ont des identifiants distincts côté serveur, donc le problème vient de l’interface et non d’un conflit de données.

Ma question :

Est-ce que vous avez déjà rencontré ce problème ?
Est-ce que vous réussissez à reproduire ?
Comment résoudre ce problème ?

Contraintes :

  • Utiliser un formulaire interne, ce ne serait pas pratique pour nous car les utilisateurs ont besoin de faire des copier/coller des lignes (car les lignes se ressemblent)
1 « J'aime »

Bonjour,

Ça ressemble au problème qu’on peut rencontrer avec le formulaire public, mais ramassé dans un laps de temps plus court.

Comme vous l’avez suggéré, la ligne vide n’est que la matérialisation d’un nouvel enregistrement qui ne préempte le prochain ID disponible dans la table qu’à validation de sa 1ère saisie l’une des cellule de cette ligne virtuelle.

Il n’y a sans doute pas vraiment moyen de l’empêcher, mais voici 3 pistes à explorer pour limiter les occurrences :

  1. Raccourcir le temps passé en mode édition de la 1ère case
    Par exemple en saisissant une valeur “facile” (comme un booléen) en 1er, avant les opérations plus longues.
  2. Utiliser un bouton d’action pour copier la ligne
    La copie classique via l’interface met généralement un certain temps à s’appliquer, Grist faisant probablement un certain nombre d’opérations en arrière-plan. Un bouton d’action prépare les données en amont et déclenche une copie généralement plus rapide.
  3. Modifier la structure pour rendre moins nécessaire le copier-coller de lignes entières
    Copier une/des lignes pour de nouveaux enregistrements peut être vu comme appliquer/lier ces lignes à un modèle, ou répéter plusieurs fois la même information avant de la modifier.
    Vous pouvez par exemple copier uniquement l’ID de la ligne d’origine et gérer la recopie des données via les formules d’initialisation, etc.
1 « J'aime »

@clemencefrz je pense qu’il faut ouvrir un bug report Grist car pour un outil collaboratif, ce n’est absolument pas normal.

Des nouvelles sur ce possible bug ?

Bonjour !
merci d’avoir pris le temps de lire.

Le problème était apparu entre deux agents.
Mais, personnellement, je n’ai pas réussi à reproduire le problème avec un agent.

En y réfléchissant, je pense que le problème était que deux agents travaillaient en même temps sur un même tableau en faisant des copier/coller de lignes, et que l’un et l’autre ne se rendaient pas compte qu’il/elle effectuait l’action de « coller » sur la ligne de son collègue.

Donc le problème est plutôt un problème d’agencement de page, donc de notre côté.