Project

General

Profile

Development #60061

inclure des limites sur le nombre de "champs" à divers endroits

Added by Frédéric Péters 5 months ago. Updated 26 days ago.

Status:
Solution déployée
Priority:
Normal
Target version:
-
Start date:
23 Dec 2021
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
Planning:
No

Description

Pas nécessairement des limites techniquement absolues mais des valeurs élevées qui peuvent amener des problèmes type performance (genre un formulaire de workflow avec 100 champs conditionnels).

Éventuellement inclure un premier niveau de valeurs, moins élevées, mais correspondant à des limites "métier" sur lesquelles on voudrait avertir.

Concernés : nombre de champs dans un formulaire/modèle de fiche, nombre de champs pour une page d'un formulaire/modèle de fiche, nombre de données de traitement, nombre de champs dans un formulaire de workflow, nombre de champs dans un bloc de champs.


Files

Associated revisions

Revision 52eaf1ea (diff)
Added by Frédéric Péters 29 days ago

general: add soft/hard limits to number of field (#60061)

History

#1

Updated by Anaïs Ecuvillon 5 months ago

Tu imagines ça comment ? Genre dans un premier temps : un message d'alerte dans le BO qui indique : le nombre de champs dans cette page atteint la limite recommandé blablabla, en terme de performance, d'expériences utilisateurs, etc.

Mais pas encore de blocage ? Quel est le nombre de champs qui d'un point de vue technique commence à vraiment faire perdre des performances ?

#2

Updated by Frédéric Péters 5 months ago

Aujour'hui on a une vraie limite technique sur la base de données sur les champs/données de traitement et à partir de 500 champs on affiche un message « Ce formulaire contient plus de 500 champs. Il approche des limites de la base de données et de nouveaux champs ne devraient pas être ajoutés », sans rien bloquer.

Même sur cette vraie limite on n'a pas de compte précis (le fait d'avoir ajouter/supprimer à répétition influe, certains types de champs comptent pour deux ou trois, c'est en fait un pool partagé entre champs et données de traitement, etc.). Sur des limites de type "performance" ce sera encore plus flou.

Mais de toute façon je dirais qu'on resterait sur un message sans blocage.

#4

Updated by Frédéric Péters 4 months ago

  • Assignee set to Frédéric Péters
#5

Updated by Frédéric Péters 4 months ago

Pour info ce qui actuellement existe sur le SaaS de prod: (nombre de champs max, nombre de champs moyen, et dernier décile)

  • formulaires, max max : 887, moyenne max : 95, 90p max : 289
  • modèles de fiche, max max : 272, moyenne max : 47, 90p max : 272
  • blocs de champs, max max : 39, moyenne max 15: , 90p max : 22
  • données de traitement, max max : 89, moyenne max : 38 , 90p max : 88
  • variables de workflow, max max : 30, moyenne max : 18, 90p max : 29
  • formulaires de workflow, max max : 244, moyenne max : 15, 90 max : 63
#6

Updated by Olivier Renard 4 months ago

Bonjour,

Est il possible d'avoir la liste de ces chiffres par instances (me dire si je dois faire un autre ticket et où) ?

Bien sincèrement

#8

Updated by Pierre Cros 4 months ago

Et donc ma proposition de chiffres arbitraires à partir de ceux de Fred (soft/hard) :

Champs de formulaires : 200 / 300
modèles de fiche, max max : 200 / 300 (parce que c'est bien que ce soit raccord avec les forms)
blocs de champs : 20 / 30
données de traitement : 20 / 30
variables de workflow : 10 / 15
formulaires de workflow, max max : 20 / 30
Nombre maximum de champs dans une page : 40 / 60
Nombre maximum de conditions dans une page : 10 / 15
Nombre maximum d'appels WS dans une page : 5 / 7

Je suis resté trop tolérant sans doute sur le nombre de champs max par page, on pourrait diviser par deux.

Pour rappel, la limite soft ça génère uniquement un avertissement "Simplifie bourrique !", la limite hard est indépassable.

#9

Updated by Olivier Renard 4 months ago

Par rapport aux cas discutés ce matin(Orleans...), faut-il (devons nous) mettre une limite sur le nombre de statuts (je ne vois pas cette notion dans notre proposition)?

#10

Updated by Frédéric Péters 4 months ago

Ce ticket est vraiment sur le nombre de champs mais la même approche (limite soft puis hard) pourra tout à fait être employée à d'autres endroits comme le nombre de statuts. Il n'y a pas de limite système dure sur les statuts, au contraire des champs sur un formulaire, mais les raisons fonctionnelles (complexité, maintenance) s'y appliquent de manière proche.

#11

Updated by Stéphane Laget 4 months ago

J'ai du mal avec la limite des champs de formulaires (limite hard) : Champs de formulaires : 200 / 300
Il y a des formulaires où tu vas de fait devoir dépasser cette limite, malgré toute la bonne volonté du client, je pense notamment aux formulaires de subventions.
Ce sont des champs basiques souvent, qui s'affichent sur plusieurs pages et sans conditions particulières.
Il y aurait peut-être à nuancer ici.

Idem pour les données de traitement ou les variables de wf, la limite hard posée me semble intenable.

#12

Updated by Pierre Cros 4 months ago

Les limites ça fait toujours des gens qui sont pas contents.

Franchement si tu dépasses 300 champs dans un formulaire, ta démarche est pourrie, simplifie là, fais plusieurs formulaires, peu importe.

Pareil pour le reste, je suis pas surpris que ça te semble peu pour qui veut faire un WF à tout faire, il faut limiter ce type de pratique au profit de WF plus unitaires.

#13

Updated by Pierre Cros 4 months ago

Pour le nombre d'étapes de WF je ferai volontiers 20 / 30, mais pour éviter la révolte chez une certaine catégorie de personnel, disons 40 / 60.

#14

Updated by Frédéric Péters 4 months ago

(ce ticket n'implémentera de toute façon que les limites sur les nombres de champs.)

#15

Updated by Frédéric Péters 4 months ago

Pour clarifier parce que j'ai introduit les notions de limites soft et hard après une réponse à Anaïs où je disais "on resterait sur un message sans blocage".

Le message sans blocage, c'est la limite soft.

Ce que j'introduit plus loin, limite hard, c'est une vraie limite indépassable, une fois atteinte (ou dépassée, dans le cas d'un existant), l'écran ne propose plus de bouton pour ajouter un champ.

#16

Updated by Pierre Cros 4 months ago

Et autre précision encore plus importante, la limite hard ne s'applique pas seulement aux nouveaux items :
Le formulaire existant qui dépasse 300 champs, il devient impossible de lui ajouter un champ, il va falloir prévenir assez en amont.

#26

Updated by Frédéric Péters 3 months ago

C'est pour la prochaine, patch actualisé avec les dernières limites décidées.

#28

Updated by Lauréline Guerin about 2 months ago

  • Status changed from Solution proposée to Solution validée
#29

Updated by Frédéric Péters 29 days ago

  • Status changed from Solution validée to Résolu (à déployer)

Fatigue des rebase, il y avait déjà pas mal à faire ici, j'ai mis le feature flag (ignore-hard-limits) par défaut et j'ai poussé; ça affiche donc les messages concernant les limites posées mais ça ne bloque pas le dépassement.

commit 52eaf1ea62163a8158e61cb3251bfd3d0c209cd0
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Sun Jan 23 20:07:42 2022 +0100

    general: add soft/hard limits to number of field (#60061)
#30

Updated by Transition automatique 26 days ago

  • Status changed from Résolu (à déployer) to Solution déployée

Also available in: Atom PDF