sigrennesmetropole / addon_urbanisme

Addon urbanisme pour le visualiseur de l'IDS geOrchestra
http://www.georchestra.org
GNU General Public License v3.0
1 stars 7 forks source link

[NRU] Est-ce que les données qui servent au print sont fournies pas le navigateur de l'utilisateur ? #54

Closed MaelREBOUX closed 7 years ago

MaelREBOUX commented 7 years ago

Je déroule le cas standard

Clic sur parcelle -> fiche d'info web

3 requêtes GET vers cadastrapp https://portail.sig.rennesmetropole.fr/cadastrapp/services/getCommune?_dc=1497969448440&cgocommune=350051 https://portail.sig.rennesmetropole.fr/cadastrapp/services/getParcelle?_dc=1497969448440&parcelle=350051000ZB0034 https://portail.sig.rennesmetropole.fr/cadastrapp/services/getFIC?_dc=1497969448441&parcelle=350051000ZB0034&onglet=1

1 requête GET cadastrapp https://portail.sig.rennesmetropole.fr/urbanisme/renseignUrba?_dc=1497969448441&parcelle=350051000ZB0034

clic pour demander une impression PDF

1 requête POST https://portail.sig.rennesmetropole.fr/urbanisme/print/report.pdf

en réponse une redirection vers une url pour récupérer le PDF https://portail.sig.rennesmetropole.fr/urbanisme/urbanisme/report/834cc460-5f0c-4b4f-8c4a-e59c82addfa0@df04476f-2cf6-40e6-a720-b8d34025075f

La redirection est trop rapide et je n'ai pas le temps dans le deboggeur de consulter ce qui est envoyé en POST. Question @fvanderbiest : est-ce que c'est bien le navigateur de l'utilisateur qui envoie les données à prendre en compte pour l'impression ?

Dit autrement : la partie serveur qui crée le PDF attend des données fournies par le navigateur, elle ne va pas refaire 3 requêtes vers cadastrapp et 1 vers la partie serveur du module Urbanisme ?

fvanderbiest commented 7 years ago

oui

MaelREBOUX commented 7 years ago

Alors on a un souci.

Une utilisatrice nous a remonté que le PDF créé / qu'elle demande ne correspond pas à la parcelle consultée en mode web. Le phénomène est aléatoire mais il s'est produit et se reproduira.

Plus précisément : la partie descriptive de la parcelle est OK mais c'est la partie NRU qui est fausse car c'est en fait celle de la précédente parcelle consultée !

Impossible de savoir si ce qui génère ce problème est un équipement filtrant ou des lenteurs réseau. Peu importe : on pensait que la webapp refaisait une interrogation de la table en se servant de l'identifiant de parcelle passée en paramètre.

le pb c'est que ce document part en annexe à des actes officiels dans les procédure d'urbanisme. C'est très gênant et si l'agent administratif n'est pas attentif ça passe complètement inaperçu !

pcocheril commented 7 years ago

@fvanderbiest Je confirme la priorité haute de ce ticket !

fvanderbiest commented 7 years ago

Je vais regarder ça ASAP, mais je voudrais signaler qu'on est sur un bug tracker public, et que ce n'est pas une bonne pratique d'y exposer des URLs internes à une infrastructure de production.

2 solutions: passer ce depôt en privé ou bien basculer ce genre de tickets sur le depot georchestra-rennes-configuration qui, lui, est privé.

fvanderbiest commented 7 years ago

Je pense comprendre ce qui se passe, il s'agit d'un défaut de conception de l'outil: la vue et le bouton impression ne devraient pas être activés lorsque les différentes XHR sont en cours. Sinon il y a effectivement le risque d'un mélange d'informations, que ce soit en visuel ou en impression.

fvanderbiest commented 7 years ago

A priori corrigé avec 7bc3b33, à redéployer. J'ai ajouté un masque qui indique que la vue est en cours de rafrachissement pendant les XHRs et qui par ailleurs empêche l'utilisateur d'imprimer pendant ce temps (car alors le résultat serait incorrect).

pcocheril commented 7 years ago

OK, Merci François. Catherine redéploiera l'add-on à son retour de congés (mardi).

MaelREBOUX commented 7 years ago

Je rouvre tant qu'on n'a pas testé.

alebras commented 7 years ago

Ça ne concerne que l'addon ou est-ce qu'il faut aussi redéployer la webapp ?

alebras commented 7 years ago

Nous venons de redéployer l'addon sur notre plateforme de test. Puis nous l'avons testé avec génération d'une note de RU puis impression de ce document. Le fonctionnement de l'addon nous semble OK sur mozilla Firefox , l'impression correspond bien au document. Par contre, l'impression ne se fait pas sur chrome. Message: main.js:824 Resource interpreted as Document but transferred with MIME type application/pdf: "https://URL/urbanisme/urbanisme/report/01e2954a-d586-44ed-9aca-8c64b120d858@692b6217-72f5-4905-b3f0-e04baa33b440" Amandine et Catherine

MaelREBOUX commented 7 years ago

Alors sur mon poste en Chrome 60.0.3112 c'est passé du premier coup. Ci-dessous les requêtes réseaux.

screenshot836

Le nb de requêtes vers l'url de téléchargement du PDF varie : /urbanisme/report/011c140b-ccf3-4ea7-9a9d-98754e2e8091@692b6217-72f5-4905-b3f0-e04baa33b440

MaelREBOUX commented 7 years ago

Maj Chrome 61.0.3163 et ça passe aussi.

catmorales commented 7 years ago

OK ça devait être un problème sur le navigateur d'Amandine. Je propose de redéployer cet addon demain en production sur la PF extranet pour débloquer les personnes en commune et on le fera en production intranet avec Amandine quand elle reviendra (pour qu'elle continue la procédure).

catmorales commented 7 years ago

Déploiement en prod prévu mardi midi.

alebras commented 7 years ago

Déploiement fait ce jour sur les 2 PF. A tester par les utilisateurs

MaelREBOUX commented 7 years ago

Je ferme car on peut pas vraiment aller plus loin à ce jour.