Produits Entr'ouvert » w.c.s.

Pour info je fais le choix de ne supporter que les champs qui ont un identifiant alors que ce n'est pas obligé.

Dans un début d'idée de plan posé nulle part j'étais pour être explicite, avec a priori une nouvelle option "indicateurs statistiques" dans "display_locations" (qui ne serait pas coché par défaut ça me semble très bien).

(ça aiderait aussi bijoe aujourd'hui, #60951).

Je me demande ce qu'il se passe quand plusieurs champs ont le même mais je n'ai pas encore essayé.

Sans doute ça se passe mal.

Dans la suite du plan, j'étais pour ajouter un JSONField "indicateurs statistiques" dans les tables des demandes, en recopiant dedans les infos; c'était pour dans la suite reprendre cette colonne JSONField dans la nouvelle table wcs_all_forms, pour avoir des indicateurs couvrant plusieurs démarches à la fois.

Est-ce qu'il faut garder les is_using_postgresql(), si oui est-ce que c'est juste pour se protéger ou il faut aussi écrire du code pour gérer correctement le cas contraire ?

On peut avoir les fonctionnalités uniquement quand postgresql est là, faut juste lever une erreur propre dans le cas contraire.

Pour le filtre par statut, est-ce qu'on veut exposer tous les statuts ou juste les statuts simplifiés ? (les status simplifiés ça permettrait d'avoir le filtre au niveau global plutôt qu'en sous-filtre)

Oui on peut commencer comme ça. (et plus loin il y aura une notion de "zone" de workflow qui sera utile globalement etc. mais c'est une autre histoire).

Frédéric Péters a écrit :

Je me demande ce qu'il se passe quand plusieurs champs ont le même mais je n'ai pas encore essayé.

Sans doute ça se passe mal.

Mes deux centimes: il y a une tension permanente entre les identifiants choisis par un humain et donc modifiables, victime de duplications, etc.. mais bien pratiques et un identifiant automatique aléatoire style UUID, aucun n'est satisfaisant en permanence. On a pu avoir ce souci avec les rôles ou les usagers lors d'un SSO ou d'un lien avec un annuaire aussi et ce qui marche bien c'est d'avoir les deux et de jongler (pour les utilisateurs on aura l'email/id de fédération/uuid technique d'annuaire qui jouent le même genre de rôle).

Ici si on avait un uuid par champ (un truc caché pas forcément ce qu'on utilise pour générer le nom des colonnes de table, comme pour les données de traitement qui n'a pas forcément était une bonne idée) on pourrait stocker la paire uuid/varname coté combo lors de la configuration, comme référence, et conserver le lien avec les champs du formulaire au gré des renommages, écrasement de formulaire, etc.. ce n'est pas parfait, si on écrase un formulaire avec un formulaire dont le champ a changé à la fois de varname et d'uuid ça ne marchera pas; mais dans la grand majorité des cas ça marche très bien. Il faut prévoir de rafraîrchir les varname en moisonnant w.c.s. régulièrement pour que ça marche bien.

À mon avis chaque fois qu'on a un élément de structure avec une identité, on devrait lui assigner un uuid, qu'on y voit un intérêt ou pas dans l'immédiat, ça finit toujours par servir. Il n'est pas important de s'en servir réellement comme clé primaire dans le code, mais on doit le conserver comme référence supplémentaire chaque qu'on conserve une référence.

Coté bijoe ça aurait bien simplifié des choses aussi.

Ici si on avait un uuid par champ

(ne pas se lancer dans ça dans ce ticket)

OK pour que je modifie le patch pour utiliser les ids ? (c'est pas mal de code à bouger, pour ça que je demande)

Non on a bien plus d'avenir à utiliser les varname. (particulièrement des perspectives de stats aggrégeant plusieurs démarches).

+        options = [
             ('validation', _('Validation Page')),
             ('summary', _('Summary Page')),
             ('listings', _('Management Listings')),
         ]

+        if self.allow_statistics and self.varname:
+            options.append(('statistics', _('Statistics')))

Je serais pour toujours afficher statitics mais pour lever une erreur quand c'est coché et qu'il n'y a pas de varname (l'idée étant qu'ainsi la personne qui sait peut faire les deux en une seule édition).

Automatic expiration