[OCCTAX] Problème de chargement de liste de JDD lors de la création d'un relevé about geonature HOT 8 CLOSED

Salut @TheoLechemia ,

Merci pour ton retour . J'ai bien vérifié les droits (voir image ci dessous)

J'avais du mal a reproduire le problème de l'ARB égalemernt mais en réalité le problème survient si la requête sur les droits liés à la première requête (POST /meta/datasets?orderby=dataset_name se fini après celle lancée pour lire les droits de création dans occtax.)

En mode debug , si tu tentes à différentes reprise tu auras un moment où la liste des jdd sera l'ensemble des jdd (et tu verras que la requête POST /meta/datasets?orderby=dataset_name s'est éxécuté deux fois avec celle qui appelle l'ensemble des jdd qui surcouche l'autre requête qui renvoie normalement les jdd que de son organisme ). Tu peux mettre un breakpoint dans le code ici et te rendre coté front sur la page de formulaire de relevé Occtax :

Tente aussi en changeant les droits et en remettant les droits qui génère le bug.

Ci dessous les images avec la liste des jdd renvoyées (dans le premier cas avec seulement les jdd de l'organisme, et dans l'autre cas l'ensemble des jdd). Et pourtant les permissions sont les mêmes

Merci à toi pour ton retour

from geonature.

Ok je viens de comprendre.
Le problème vient de ce store : https://github.com/PnX-SI/GeoNature/blob/master/frontend/src/app/GN2CommonModule/form/datasets/dataset.service.ts qui est utilisé dans le composant ici : https://github.com/PnX-SI/GeoNature/blob/master/frontend/src/app/GN2CommonModule/form/datasets/datasets.component.html#L4

Le premier appel à /meta/datasets?orderby=dataset_name vient de la page carte/liste d'occtax qui charge pour les filtres la liste des JDD accessible en lecture à l'utilisateur.
Ensuite tu va sur la page du formulaire, le second appel est fait, et il finit avant le second. Donc le store contient les données du premier..
On avait dû faire ce store pour cacher des données, mais il est inopérant car on veut des listes différentes suivant les cas donc il faut le virer.
Le ngDestroy fonctionne car quand tu quitte la page carte liste, il annule ce qu'il y a après le subscribe donc il ne remplit pas le store. En virant le store on aura plus besoin du ngDestroy (car de toute façon ça ne soulagerait pas le serveur car la requête est déjà lancée)
Il faudrait aussi voir pourquoi la route met 12sec à répondre, il y a des truc à améliorer de ce côté là

from geonature.

Salut,

Je ne pense pas que le problème viennent de là car les subscription venant de httpClient sont automatiquement unsubscribe à la reception des données ou lors du timeout :
https://angular.io/guide/http-request-data-from-server#starting-the-request
ça peut venir de :

• ton utilisateur a des droits sur ces JDD via les acteurs mis sur le cadre d'acquisition
• ton utilisateurs a des droits supérieurs via son groupe
  Dans mon cas j'ai mis des droit "1" en création à mon utilisateurs et aux groupes auxquels il appartient et on a le comportement attendu. Tu dois avoir un truc comme ça dans l'admin des permissions :
  
  -> c'est bien la dernière colonne (permissions effective qui fait foi)

from geonature.

j'arrive pas à reproduire, même en mettant un time.sleep sur la route des JDD dans le cas ou elle est appelé par le module métadonnée.
A mon avis ça vient de l'input creatableInModule du composant datasets qui ne doit pas être mis au moment l'appel.
Est ce que tu arriverais à voir le contenut du POST (payload) pour les deux requêtes qui tu vois passer (et dans le cas ou tu as le bug)

from geonature.

Le corps des requêtes POST /meta/datasets?orderby=dataset_name qui se lancent (avec leur temp d'éxécution) :

1. corps de la 1ère requête lancée :
   • {"module_code":"OCCTAX"}
   • Durée : 7 sec
2. corps et temps de la 2nde requête lancée une fois sur le tab "Releve" :
   • {"active":true,"module_code":"OCCTAX","create":"OCCTAX"}
   • Durée : 611ms

Et d'ailleurs je remarque que systématiquement le bug survient lorsque la première requête est beaucoup trop longue par rapport à la deuxième requête. La première requête peut aller jusqu'à 12sec de chargement (l'autre est plus rapide, de l'ordre de 500ms à 2sec) .
Mais c'est vrai que ton time sleep devrait permettre de reproduire le bug , j'avais zappé ça dans ton message

from geonature.

Pour revenir sur le ngOnDestroy , lorsqu'il est mis en place il est permet bien de stoper la première requête POST /meta/datasets?orderby=dataset_name dès lors qu'on va sur le tab Releve qui lance la deuxième requête POST /meta/datasets?orderby=dataset_name avec le corps requête :
{"active":true,"module_code":"OCCTAX","create":"OCCTAX"}

D'où le fait que le bug n'apparait plus lorsque je met en place la subscription avec le unsubscribe dans le ngOnDestroy .

from geonature.

Super merci pour ta réponse. J'ai mis à jour la PR liée ( #2816 )

Pour le temps de requête ça fait effectivement partie des requêtes à améliorer en terme de performance .. On en a listé d'autre notamment dans la synthese .

from geonature.

Corrigé dans la 2.13.4.

from geonature.