[OCCTAX] Problème de chargement de liste de JDD lors de la création d'un relevé #2815

andriacap · 2023-12-01T16:55:49Z

Version
Version de GeoNature affectée par le bug : 2.13.3 (pas testés les autres versions)

Description du bug

Dans le cadre d'une prestation avec l'ARB IDF , il a été remonté une erreur concernant la liste des jdd affichés dans le formulaire du relevé occtax. La liste des jdd affichés concerne l'ensemble des JDD (soit basé sur les permissions associés au Module METADATA ALL Lecture --> tous les JDD) alors que les permissions censés être affichés sont ceux liés aux permission OCCTAX ALL Création --> les données de mon organismes.

Comportement attendu
Le comportement attendu serait dans le cas de figure présenté ci dessus de n'afficher les JDD n'appartenant qu'à ceux de l'organisme de l'utilisateur connecté et non l'ensemble des JDD.

Comment reproduire
Au niveau du module des permissions dans Admin --> Il est possible d'observer le problème en appliquant les permissions suivantes à un utilisateur :

Module (METADA) , Objet (ALL), Action (R), Label ( lire les métdonnées) , portée (tout)
Module (OCCTAX), Objet (ALL), Action (C), Label (Créer des relevés), portée (de mon organisme)

Au niveau du module OCCTAX --> se rendre sur le module et cliquer sur "Ajouter un relevé" . Voir la liste des JDD (tous les jdd affichés)

Résolution de l'erreur

Dans le fichier ici :

GeoNature/frontend/src/app/GN2CommonModule/form/datasets/datasets.component.ts

Lines 88 to 104 in 22b577a

    
             this._dfs.getDatasets((params = filter_param)).subscribe((res) => { 
        
               this.datasetStore.filteredDataSets = res; 
        
               this.datasetStore.datasets = res; 
        
               this.valueLoaded.emit({ value: this.datasetStore.datasets }); 
        
               if ( 
        
                 res.length == 1 && 
        
                 this.parentFormControl.hasValidator(Validators.required) && 
        
                 [null, []].includes(this.parentFormControl.value) 
        
               ) { 
        
                 let value: number[] | number = res[0].id_dataset; 
        
                 if (this.multiSelect) { 
        
                   value = [res[0].id_dataset]; 
        
                 } 
        
                 this.parentFormControl.patchValue(value); 
        
               } 
        
             }); 
        
           }

L'observable n'est pas associée à une Subscription et du coup n'est pas unsubscribe lorsque le composant est "détruit" . Du coup ce qui se passe c'est que la requête qui appel la liste des JDD (POST /meta/datasets?orderby=dataset_name) sur la base des permissions OCCTAX / ALL / C / données de mon organisme est surcouché par la requête qui est passée sur les permissions de METADATA/ALL/R/ Tout.

Pour palier à ce problème on ajoute ngOnDestroy dans lequel on unsubscribe la "Subscription" à l'Observable .

Je vais créer une PR pour résoudre ce bug.

The text was updated successfully, but these errors were encountered:

[Refs_ticket]: PnX-SI#2815 Reviewed-by: andriacap

TheoLechemia · 2023-12-04T10:09:09Z

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)

andriacap · 2023-12-04T11:50:01Z

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 :

GeoNature/frontend/src/app/GN2CommonModule/form/datasets/datasets.component.ts

Lines 88 to 104 in 22b577a

    
             this._dfs.getDatasets((params = filter_param)).subscribe((res) => { 
        
               this.datasetStore.filteredDataSets = res; 
        
               this.datasetStore.datasets = res; 
        
               this.valueLoaded.emit({ value: this.datasetStore.datasets }); 
        
               if ( 
        
                 res.length == 1 && 
        
                 this.parentFormControl.hasValidator(Validators.required) && 
        
                 [null, []].includes(this.parentFormControl.value) 
        
               ) { 
        
                 let value: number[] | number = res[0].id_dataset; 
        
                 if (this.multiSelect) { 
        
                   value = [res[0].id_dataset]; 
        
                 } 
        
                 this.parentFormControl.patchValue(value); 
        
               } 
        
             }); 
        
           }

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

TheoLechemia · 2023-12-04T14:14:44Z

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)

andriacap · 2023-12-05T09:07:57Z

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

corps de la 1ère requête lancée :
- {"module_code":"OCCTAX"}
- Durée : 7 sec
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

andriacap · 2023-12-05T09:20:42Z

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 .

TheoLechemia · 2023-12-05T10:10:37Z

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à

Remove unused datasetStore Remove ngOndestroy and subscription (first dev suggestion) [Refs_ticket]: PnX-SI#2815 Reviewed-by: andriacap

andriacap · 2023-12-05T12:08:40Z

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 .

…rmissions [Refs_ticket]: PnX-SI#2815

…rmissions [Refs_ticket]: #2815

camillemonchicourt · 2023-12-15T09:16:18Z

Corrigé dans la 2.13.4.

…rmissions [Refs_ticket]: #2815

…rmissions [Refs_ticket]: PnX-SI#2815

andriacap added the bug label Dec 1, 2023

andriacap added a commit to andriacap/GeoNature that referenced this issue Dec 1, 2023

fix: observable getDataset not unsubscribe

34ae565

[Refs_ticket]: PnX-SI#2815 Reviewed-by: andriacap

andriacap mentioned this issue Dec 1, 2023

fix: observable getDataset problem with datasetStore #2816

Closed

andriacap added a commit to andriacap/GeoNature that referenced this issue Dec 5, 2023

refactor: remove datasetStore and ngOnDestroy

36751e9

Remove unused datasetStore Remove ngOndestroy and subscription (first dev suggestion) [Refs_ticket]: PnX-SI#2815 Reviewed-by: andriacap

TheoLechemia pushed a commit to andriacap/GeoNature that referenced this issue Dec 6, 2023

Remove innapropriate datasetStore which cause datasets no fit with pe…

e3d25b4

…rmissions [Refs_ticket]: PnX-SI#2815

TheoLechemia pushed a commit that referenced this issue Dec 6, 2023

Remove innapropriate datasetStore which cause datasets no fit with pe…

bec1272

…rmissions [Refs_ticket]: #2815

camillemonchicourt closed this as completed Dec 15, 2023

andriacap mentioned this issue Dec 19, 2023

[OCCTAX] Requête sur les jdd PnX-SI/gn_mobile_occtax#239

Closed

jacquesfize pushed a commit that referenced this issue Jan 8, 2024

Remove innapropriate datasetStore which cause datasets no fit with pe…

76f168b

…rmissions [Refs_ticket]: #2815

jacquesfize pushed a commit that referenced this issue Jan 9, 2024

Remove innapropriate datasetStore which cause datasets no fit with pe…

ddef2f8

…rmissions [Refs_ticket]: #2815

jacquesfize pushed a commit to jbrieuclp/GeoNature that referenced this issue Jan 9, 2024

Remove innapropriate datasetStore which cause datasets no fit with pe…

08e2762

…rmissions [Refs_ticket]: PnX-SI#2815

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[OCCTAX] Problème de chargement de liste de JDD lors de la création d'un relevé #2815

[OCCTAX] Problème de chargement de liste de JDD lors de la création d'un relevé #2815

andriacap commented Dec 1, 2023 •

edited

Loading

TheoLechemia commented Dec 4, 2023 •

edited

Loading

andriacap commented Dec 4, 2023

TheoLechemia commented Dec 4, 2023

andriacap commented Dec 5, 2023 •

edited

Loading

andriacap commented Dec 5, 2023 •

edited

Loading

TheoLechemia commented Dec 5, 2023 •

edited

Loading

andriacap commented Dec 5, 2023

camillemonchicourt commented Dec 15, 2023

[OCCTAX] Problème de chargement de liste de JDD lors de la création d'un relevé #2815

[OCCTAX] Problème de chargement de liste de JDD lors de la création d'un relevé #2815

Comments

andriacap commented Dec 1, 2023 • edited Loading

TheoLechemia commented Dec 4, 2023 • edited Loading

andriacap commented Dec 4, 2023

TheoLechemia commented Dec 4, 2023

andriacap commented Dec 5, 2023 • edited Loading

andriacap commented Dec 5, 2023 • edited Loading

TheoLechemia commented Dec 5, 2023 • edited Loading

andriacap commented Dec 5, 2023

camillemonchicourt commented Dec 15, 2023

andriacap commented Dec 1, 2023 •

edited

Loading

TheoLechemia commented Dec 4, 2023 •

edited

Loading

andriacap commented Dec 5, 2023 •

edited

Loading

andriacap commented Dec 5, 2023 •

edited

Loading

TheoLechemia commented Dec 5, 2023 •

edited

Loading