Closed MaelREBOUX closed 7 years ago
oui
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 !
@fvanderbiest Je confirme la priorité haute de ce ticket !
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é.
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.
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).
OK, Merci François. Catherine redéploiera l'add-on à son retour de congés (mardi).
Je rouvre tant qu'on n'a pas testé.
Ça ne concerne que l'addon ou est-ce qu'il faut aussi redéployer la webapp ?
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
Alors sur mon poste en Chrome 60.0.3112 c'est passé du premier coup. Ci-dessous les requêtes réseaux.
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
Maj Chrome 61.0.3163 et ça passe aussi.
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).
Déploiement en prod prévu mardi midi.
Déploiement fait ce jour sur les 2 PF. A tester par les utilisateurs
Je ferme car on peut pas vraiment aller plus loin à ce jour.
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 ?