Project

General

Profile

Development #4507

backoffice : mémorisation de listing

Added by Frédéric Péters over 6 years ago. Updated 4 months ago.

Status:
Solution déployée
Priority:
Normal
Target version:
-
Start date:
19 Mar 2014
Due date:
30 Apr 2020
% Done:

0%

Patch proposed:
Yes
Planning:
No

Description

Avec #4505, et déjà avec la sélection de colonnes, il devient intéressant de permettre à un agent d'enregistrer son paramétrage de listing.

0001-backoffice-add-support-for-custom-views-4507.patch View (75.7 KB) Frédéric Péters, 31 Mar 2020 09:43 AM


Related issues

Related to w.c.s. - Development #1782: listing du backoffice: chaque utilisateur doit pouvoir définir sa vue préférée Nouveau 15 Oct 2012
Related to w.c.s. - Development #15165: Sauvegarde des filtres sur vues globale et par formulaires Rejeté 27 Feb 2017
Related to w.c.s. - Development #15003: Elargir possibilités du filtres statuts dans la vue globale Fermé 15 Feb 2017 17 Mar 2017
Related to Publik - Development #19754: Possibilité pour les agents de sauvegarder des vues personnalisées Solution déployée 29 Oct 2017
Related to Publik - Development #37532: Vues personnalisées sur les demandes et sur les fiches Fermé 07 Nov 2019
Related to w.c.s. - Bug #41768: Enregistrement d'une vue listing : le bouton "supprimer la vue" est coupé Solution déployée

Associated revisions

Revision 5c04a440 (diff)
Added by Frédéric Péters 4 months ago

backoffice: add support for custom views (#4507)

History

#1 Updated by Pierre Cros over 6 years ago

Et même d'en sauvegarder plusieurs, façon Redmine (enfin si ça rajoute pas trop en coûts de dev)

#2 Updated by Frédéric Péters over 6 years ago

Lien posé vers #1782, qui reprend aussi quelques idées.

#3 Updated by Victor Claudet almost 6 years ago

  • Patch proposed set to No

Meyzieu me relance sur cette fonctionnalité, alors je le dis ici.

#4 Updated by Frédéric Péters almost 6 years ago

On leur a vendu ?

#5 Updated by Victor Claudet almost 5 years ago

On l'a vendu a personne et tout le monde la demande (Vincennes aussi par exemple depuis longtemps), Alfortville maintenant.

#6 Updated by Pierre Cros over 3 years ago

Important pour afficher des cartes des demandes dans Combo #8454

#7 Updated by Frédéric Péters over 3 years ago

On limite ce ticket à la possibilité pour l'admin (de la fabrique de formulaire) d'enregistrer formdef par formdef sa sélection de filtre/colonnes.

#8 Updated by Frédéric Péters over 3 years ago

  • Priority changed from Normal to Haut

#9 Updated by Brice Mallet over 3 years ago

  • Related to Development #15165: Sauvegarde des filtres sur vues globale et par formulaires added

#10 Updated by Frédéric Péters over 3 years ago

À côté du bouton "Valider" / "Rafraîchir" (besoin d'uniformiser entre vue globale et vue d'un formdef, #15347), quand il y a eu un filtre appliqué (techniquement, quand la query string n'est pas vide), avoir un bouton "Enregistrer". Popup alors pour entrer un nom et si l'agent est admin (de la fabrique de formulaires), case à cocher "visible par tout le monde", case à cocher "par défaut". On enregistre la query string + formdef.id (et None si c'est une requête "globale").

Sous les boutons "Valider" (et maintenant "Enregistrer"), la liste des requêtes enregistrées, sous un titre "Requêtes personnalisées" (?). Ou au-dessus des critères plutôt ? (dans la vue "statistiques globales", on a "Raccourcis", sous les critères). Quand on est sur le listing d'un formulaire précis, afficher à la fois les requêtes "globales" et les requêtes attachées au formulaire en question.

Quand on clique sur un des liens "requête", poser la query string associée + un paramètre identifiant la requête (query_id). En présence de cet identifiant de requête dans l'URL, la popup "enregistrer" propose alors d'écraser ou de créer une nouvelle. Aussi, un bouton "Supprimer la requête".

#11 Updated by Pierre Cros over 3 years ago

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

Sous les boutons "Valider" (et maintenant "Enregistrer"), la liste des requêtes enregistrées, sous un titre "Requêtes personnalisées" (?). Ou au-dessus des critères plutôt ?

Sous les critères, mais plutôt "Vues personnalisées".

Pour le reste, tout semble avoir été prévu, top.

#12 Updated by Brice Mallet over 3 years ago

  • Related to Development #15003: Elargir possibilités du filtres statuts dans la vue globale added

#13 Updated by Brice Mallet over 3 years ago

"Ou au-dessus des critères plutôt ? (dans la vue "statistiques globales", on a "Raccourcis", sous les critères)"

Mais dans les stats BiJoe, les visualisations - construites - se placent en premier. Je serais pour présenter les requêtes enregistrées en premier (si les qq indicateurs / listes sont pertinents, plus besoin d'utiliser de nouveaux filtres) et avec affichage graphique plus fort que la construction de nouveaux filtres

#14 Updated by Brice Mallet over 3 years ago

Quand on est sur le listing d'un formulaire précis, afficher à la fois les requêtes "globales" et les requêtes attachées au formulaire en question.

Les requêtes "globales" : cela signifie t'il les requêtes construites sur la base de la vue globale ? ou plutôt les requêtes sauvegardées par l'administrateur de la fabrique de formulaires qui viennent alors en plus des requêtes propres à l'agent ?

#15 Updated by Frédéric Péters over 3 years ago

cela signifie t'il les requêtes construites sur la base de la vue globale ?

Oui, celles-là.

On a quatre situations :

  • requête créée par un agent, sur un formulaire précis : visible uniquement sur celui-ci, pour cet agent
  • requête créée par un agent, sur la vue globale : visible de la vue globale et sur tous les formulaires, pour cet agent
  • requête créée et partagée par un admin, sur un formulaire précis : visible uniquement sur le formulaire, par tous les agents
  • requête créée et partagée par un admin, sur la vue globale : visible de la vue globale et sur tous les formulaires, par tous les agents.

#17 Updated by Pierre Cros almost 3 years ago

  • Related to Development #19754: Possibilité pour les agents de sauvegarder des vues personnalisées added

#18 Updated by Frédéric Péters 9 months ago

  • Related to Development #37532: Vues personnalisées sur les demandes et sur les fiches added

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

  • Due date set to 30 Apr 2020
  • Priority changed from Haut to Normal
  • Assignee set to Frédéric Péters

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

Patch pour les fonctionnalités essentielles, et un peu au-delà,

  • possibilité pour l'agent d'enregistrer des vues personnalisées sur les formulaires et les fiches,
  • possibilité pour l'admin d'enregistrer et d'exposer ses vues à tous les agents,
  • possibilité de réordonner les colonnes,
  • visibilité dans l'API (/api/forms/<slug>/list/<custom>/) du résultat.

Une fois cette base en place il y a quantité d'évolutions possibles (permettre d'exploiter ces vues dans les sources de données, pour par exemple avoir une source "postes à pourvoir (ouverts)", questions que ça pose sur l'export/import, questions sur la possibilité de vues partagées par différents formulaires, filtres supplémentaires...).

Le patch en lui-même est je pense assez clair, sur la page de tableau de traitement (FormPage) un attribut supplémentaire (view) et celui-ci est consulté, avant la query string, pour connaitre le paramétrage à appliquer.

À part ça, dans l'objet CustomView, le truc à noter peut-être c'est l'attribut columns, qui n'est pas une liste des identifiants mais une liste de dictionnaires {'id': ...}, c'est dans l'idée de pouvoir faire évoluer ça pour contenir davantages d'informations (et peut-être avoir des colonnes personnalisées, qui seraient définies à partir d'un gabarit django, pour faire comme les "projections" dans le connecteur CSV).

#21 Updated by Thomas Noël 4 months ago

Il y a un bogue ici :

+        existing_slugs = {
+            x.slug: True
+            for x in self.select(ignore_errors=True)
+            if (x.user_id == self.user_id and x.visibility == 'owner' and self.visibility == 'owner')
+            and x.formdef_type == self.formdef_type
+            and x.formdef_id == self.formdef_id
+        }

qui permet la création de vues "any" avec le même slug, voire mix any/owner. En fait pour éviter tout conflit je pense qu'il faut prendre tous les slugs du même formdef_type/formdef_id, sans autre critère.


Lorsque l'usager n'est pas admin, voir comment préfixer le slug avec "user-", pour éviter qu'un usager pollue le travail de l'admin (typiquement, admin qui doit créer un slug spécifique utilisé par un consommateur d'api).


Typo sur self.admin_permisison qui se répète heureusement partout, mais bon, à corriger (partout donc).

Dans get_custom_view_form il y a d'ailleurs un is_accessible('forms') à remplacer alors par is_accessible(self.admin_permission) (au niveau de la vérification de la permission de mise à jour de la vue)


J'ai eu un doute sur "Vues personnalisées" qui va s'afficher quand il n'y aura que des vues partagées (créées par un admin). Mais je n'ai pas d'autre proposition alors gardons cela ainsi, c'est simple et très bien. Et après tout, ce sont des vues personnalisées, par une autre personne, mais personnalisées quand même.

J'ai rien vu d'autre ce soir. Ca marche plutôt bien comme tout.


Dans les évolutions il faudra sans doute prévoir (et je pense que le code ici présent le permettra) :
  • d'exporter/importer toutes les vues "any" liées à un formdef/carddef lors de l'export/import de celui-ci
  • de permettre qu'une vue any soit la vue par défaut au niveau de l'UI (mais pas de l'API), juste par un redirect quand on arrive sur backoffice/management/formslug/

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

qui permet la création de vues "any" avec le même slug, voire mix any/owner. En fait pour éviter tout conflit je pense qu'il faut prendre tous les slugs du même formdef_type/formdef_id, sans autre critère.

+

Lorsque l'usager n'est pas admin, voir comment préfixer le slug avec "user-", pour éviter qu'un usager pollue le travail de l'admin (typiquement, admin qui doit créer un slug spécifique utilisé par un consommateur d'api).

Je préfère du coup garder l'unicité par utilisateur (+ correction pour avoir une unicité aussi pour les vues "any"), certes si un usager crée une vue avec un nom utilisé par l'admin celle-ci prendra le dessus mais je trouve limite ça bien. (par contre il faut être sûr que ça soit toujours le cas, branche modifiée pour que ça soit le cas).

~~

Dans les évolutions (...)

Oui ça fait partie de bouts envisagés, pas compliqués une fois la base en place.

#23 Updated by Thomas Noël 4 months ago

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

certes si un usager crée une vue avec un nom utilisé par l'admin celle-ci prendra le dessus

Y'a encore du conflit : je suis admin, je créé une vue perso nommée test, slug test. Je créé une autre vue nommée test, cette fois partagée, elle prend également le slug test... oups (de plus je n'y ai pas accès, c'est la vue perso test qui prend le dessus).

C'est une situation qui va arriver et qui sera difficile à déboguer.

si un usager crée une vue avec un nom utilisé par l'admin celle-ci prendra le dessus mais je trouve limite ça bien.

Pas moi : si l'usager avait déjà créé sa vue, il ne comprendra pas pourquoi il n'a jamais accès à la nouvelle vue proposée par un admin. (et personne ne comprendra, impossible de le voir sans se connecter à la place de l'utilisateur en panne)

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

J'ai besoin d'un récap de ce qui est proposé, je partais de :

  • une vue partagée peut avoir n'importe quel slug (pas déjà utilisé, ce qui manquait dans mon patch initial),
  • une vue privée peut avoir n'importe quel slug (pas déjà utilisé, et le patch initial acceptait un slug doublon d'une vue partagée sans définir de comportement, et le nouveau patch accepte aussi mais définit le comportement).

S'ajouterait "pour éviter tout conflit je pense qu'il faut prendre tous les slugs du même formdef_type/formdef_id, sans autre critère" :

  • une vue privée peut avoir n'importe quel slug sauf un slug déjà utilisé (peu importe partagée ou pas et l'utilisateur concerné),

+ "voir comment préfixer le slug avec "user-", pour éviter qu'un usager pollue le travail de l'admin"

  • une vue privée doit commencer par "user-",
  • une vue partagée ne peut pas commencer par "user-".

(pas de patch, besoin de clarifier tout ça d'abord)

#25 Updated by Thomas Noël 4 months ago

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

J'ai besoin d'un récap de ce qui est proposé, je partais de :

  • une vue partagée peut avoir n'importe quel slug (pas déjà utilisé, ce qui manquait dans mon patch initial),
  • une vue privée peut avoir n'importe quel slug (pas déjà utilisé, et le patch initial acceptait un slug doublon d'une vue partagée sans définir de comportement, et le nouveau patch accepte aussi mais définit le comportement).

S'ajouterait "pour éviter tout conflit je pense qu'il faut prendre tous les slugs du même formdef_type/formdef_id, sans autre critère" :

  • une vue privée peut avoir n'importe quel slug sauf un slug déjà utilisé (peu importe partagée ou pas et l'utilisateur concerné),

+ "voir comment préfixer le slug avec "user-", pour éviter qu'un usager pollue le travail de l'admin"

  • une vue privée doit commencer par "user-",
  • une vue partagée ne peut pas commencer par "user-".

(pas de patch, besoin de clarifier tout ça d'abord)

Je suis perdu aussi, je pense qu'on cherche à être intelligent et c'est jamais bon signe :) Ce que je vois c'est que les slugs ne peuvent pas changer alors que la visibilité (perso/partagée) peut, ça complexifie l'algo.

À partir de là, ma proposition est bête-et-méchante :
  • ne jamais permettre de doublon de slug, dans aucun cas, quelque soit la visibilité ou le créateur. Pas d'intelligence, garantie zéro conflit.
  • quand le créateur n'est pas admin, les slug sont préfixés avec « user-<id>-- » ou juste « user-- » ou «u--». L'admin en revanche n'est pas soumis à cette contrainte, même pour ses vues perso.

La raison de cette dernière règle : ne pas polluer les admin. Ils pourront toujours créer des slugs comme il veut (principalement dans le but de créer des slugs «parlants» et «fixés» pour les API/sources-de-données/etc). Et pour toutes ses vues, quelle que soit la visibilité, afin qu'il puisse les créer/tester d'abord en vue perso avant de les partager.

Effectivement ainsi on ne permet pas à un agent d'écraser une vue partagée par une vue perso, parce que c'est source d'incompréhension.

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

Je continue à trouver pas terrible de "polluer" les URL avec des suffixes tiret-numéro.

J'en viens à ma proposition initiale (slugs unique par utilisateur / globalement quand c'est "any") mais modifier le lookup pour que .../<slug> cherche uniquement les vues "any" et que .../user-<slug> cherche uniquement les vues "owner"; ça me semble éviter tous les problèmes :

  • les vues privées et publiques ont toujours des adresses différentes
  • les vues publiques ont des slugs uniques
  • les vues privées, par utilisateur, ont des slugs uniques, et c'est les seuls qui sont vues

#27 Updated by Thomas Noël 4 months ago

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

Je continue à trouver pas terrible de "polluer" les URL avec des suffixes tiret-numéro.

J'en viens à ma proposition initiale (slugs unique par utilisateur / globalement quand c'est "any") mais modifier le lookup pour que .../<slug> cherche uniquement les vues "any" et que .../user-<slug> cherche uniquement les vues "owner"; ça me semble éviter tous les problèmes :

  • les vues privées et publiques ont toujours des adresses différentes
  • les vues publiques ont des slugs uniques
  • les vues privées, par utilisateur, ont des slugs uniques, et c'est les seuls qui sont vues

Yep ça roule pas mal comme ça. (Note : cas certainement rare mais il faudra interdire qu'un slug commence par "user-" pour ne pas qu'il recouvre une vue "owner" si un jour il est slug d'une vue "any")

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

(branche modifiée/poussée)

Yep ça roule pas mal comme ça. (Note : cas certainement rare mais il faudra interdire qu'un slug commence par "user-" pour ne pas qu'il recouvre une vue "owner" si un jour il est slug d'une vue "any")

Sur ce cas si jamais ça arrive le slug sera créé comme étant "userx-..." plutôt que "user-...", totalement arbitrairement.

#29 Updated by Thomas Noël 4 months ago

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

Ça me va comme ça, allons-y !

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

  • Status changed from Solution validée to Résolu (à déployer)
commit 5c04a4402a8c65b16ef5d1f604ddc283d2a710be
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Mon Mar 9 09:35:09 2020 +0100

    backoffice: add support for custom views (#4507)

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

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

#32 Updated by Marie Kuntz 4 months ago

<3

#33 Updated by Marie Kuntz 4 months ago

  • Related to Bug #41768: Enregistrement d'une vue listing : le bouton "supprimer la vue" est coupé added

Also available in: Atom PDF