Produits Entr'ouvert » Mandaye

Plutôt qu'un SITE_APP_<APP_NAME>_ENABLED = True j'aurait été plus fan d'un SITE_APP = 'mandayejs.applications.Duonext', et quand on en a besoin de faire:

def get_app_settings():
    module = import_module('%s' % settings.SITE_APP.rsplit('.', 1)[0])
    return getattr(module, setttings.SITE_APP.rsplit('.', 1)[1])

Au moins si on se trompe dans le nom de l'app ça se sent et on pourrait se passe complètement d'applications, un simple fichier applications.py avec des classes comme class Duonext(object): ça ferait moins de boulot pour ajouter une application.

Je me demande aussi si tout ça fonctionne bien en mode multitenant parce que les settings sont régulièrement écrasés, il en existe plusieurs versions selon le tenant, donc stocker client_settings et site_settings dans settings ça me semble tendu, le plus simple c'est vraiment de recherche la classe à chaque fois.

Sinon pour la partie client_settings je trouve qu'il y a toujours trop de clés de style et de js, pour moi aucun client ne devrait nécessitait du JS, tout le monde pareil et niveau style on devrait avoir juste une feuille de style CSS, dont dans le futur on devrait pouvoir récupérer l'URL automatiquement, mandayejs ne devrait contenir aucun "asset".

duonext.css et vincennes.associate.css devraient aller dans un mandaye.css global qui est toujours chargé (faire juste attention aux id et class utilisés pour éviter les collisions).

Ceci:

  $('#sso-username').after('<a id="demarches" href="https://demarches.vincennes.fr">Démarches en ligne</a>');
  if ($('#sso-username').length === 0) {
      $('#mandaye-vc-logo').after('<a id="demarches" href="https://demarches.vincennes.fr">Démarches en ligne</a>');
  }

ça devrait être fait dans la génération du panel.html je pense, avec une simple clé CLIENT_PANEL_OTHER_URLS = [('Démarches en ligne', 'https://demarches.vincennes.fr')] sinon ce sera ingérable entre prod/test/dev.

• l'URL de la page de compte (et encore on devrait pouvoir la déduire, mais faisons comme cela pour l'instant)
• l'URL de la feuille de style pour la barre/la page d'association (si celle-ci était un popup on aurait pas besoin de la styler)
• des liens en plus pour la barre (ici "Démarches en lignes") mais dans un premier temps, notre seul déployement étant publik je n'aurai rien conte mettre ça en dur vers {{ portal_citoyen_url }} où je ne sais plus quelle autre variable comme celle-ci qui existe déjà.

Benjamin Dauvergne a écrit :

Plutôt qu'un SITE_APP_<APP_NAME>_ENABLED = True j'aurait été plus fan d'un SITE_APP = 'mandayejs.applications.Duonext', et quand on en a besoin de faire:
[...]

Au moins si on se trompe dans le nom de l'app ça se sent et on pourrait se passe complètement d'applications, un simple fichier applications.py avec des classes comme class Duonext(object): ça ferait moins de boulot pour ajouter une application.

OK

Je me demande aussi si tout ça fonctionne bien en mode multitenant parce que les settings sont régulièrement écrasés, il en existe plusieurs versions selon le tenant, donc stocker client_settings et site_settings dans settings ça me semble tendu, le plus simple c'est vraiment de recherche la classe à chaque fois.

Sinon pour la partie client_settings je trouve qu'il y a toujours trop de clés de style et de js, pour moi aucun client ne devrait nécessitait du JS, tout le monde pareil et niveau style on devrait avoir juste une feuille de style CSS, dont dans le futur on devrait pouvoir récupérer l'URL automatiquement, mandayejs ne devrait contenir aucun "asset".

Le souci c'est que toutes les barres mandayes ne se ressemblent pas, certaines ont des elements que d'autres n'ont pas malheureusement.

duonext.css et vincennes.associate.css devraient aller dans un mandaye.css global qui est toujours chargé (faire juste attention aux id et class utilisés pour éviter les collisions).

Ceci:

[...]

ça devrait être fait dans la génération du panel.html je pense, avec une simple clé CLIENT_PANEL_OTHER_URLS = [('Démarches en ligne', 'https://demarches.vincennes.fr')] sinon ce sera ingérable entre prod/test/dev.

Vincennes ne devrait avoir que 3 customizations:

• l'URL de la page de compte (et encore on devrait pouvoir la déduire, mais faisons comme cela pour l'instant)
• l'URL de la feuille de style pour la barre/la page d'association (si celle-ci était un popup on aurait pas besoin de la styler)
• des liens en plus pour la barre (ici "Démarches en lignes") mais dans un premier temps, notre seul déployement étant publik je n'aurai rien conte mettre ça en dur vers {{ portal_citoyen_url }} où je ne sais plus quelle autre variable comme celle-ci qui existe déjà.

+1

Josué Kouka a écrit :

Je me demande aussi si tout ça fonctionne bien en mode multitenant parce que les settings sont régulièrement écrasés, il en existe plusieurs versions selon le tenant, donc stocker client_settings et site_settings dans settings ça me semble tendu, le plus simple c'est vraiment de recherche la classe à chaque fois.

Sinon pour la partie client_settings je trouve qu'il y a toujours trop de clés de style et de js, pour moi aucun client ne devrait nécessitait du JS, tout le monde pareil et niveau style on devrait avoir juste une feuille de style CSS, dont dans le futur on devrait pouvoir récupérer l'URL automatiquement, mandayejs ne devrait contenir aucun "asset".

Le souci c'est que toutes les barres mandayes ne se ressemblent pas, certaines ont des elements que d'autres n'ont pas malheureusement.

Et bien c'est désormais interdit, toutes les barres mandaye seront pareils. Je ne connais que deux déploiements montpellier et vincennes, peux-tu lister les différences ?

ok, de toute façon c'est mieux qu'elles soient toutes identiques.

Bon ben je dirai que si y a le temps on aille jusqu'au popup tout de suite, un div overlay blanc à 90% de transparence avec une iframe au milieu de 300x300, faut pas oublier le target="_top" sur le formulaire pour recharger toute la page.

Il faut sans doute passer sur un autre ticket pour la popup d'association de compte, qui doit en partie être une cellule d'appairage côté combo.

• combo → mandaye : est-ce qu'on est appairé ?
• si oui, ok
• si non,
  • combo → mandaye : quel champs pour l'appairage ?
  • ← identifiant chose, date de naissance, code secret
  • combo affiche la boite de dialogue
  • l'usager valide,
  • combo → mandage : voilà des infos, dis-moi si c'est ok.
  • si ok, bien, on ferme la popup
  • si pas ok, on affiche un message d'erreur dans la popup

On peut voir ce déroulé à partir de https://dev.entrouvert.org/projects/combo/wiki/Mockup_page_de_bienvenue#Saisie-des-infos-de-lusager

• il faudrait normaliser les classes et id sur un préfixe mandaye- plutôt que mandaye- de temps en temps et sso- ailleurs
• pour moi il ne devrait y avoir qu'un seul fichier CSS (là je vois un ajout de fontawesome css à la volée) nommé vincennes-conservatoire.css qui éventuellement peut inclure d'autres fichiers CSS avec la directive @import "other.css" par exemple le fontawesome.css

• $('#sso-url').after($('#sso-mandaye-link'));

  si sso-url doit être après mandaye-link alors que ce soit tout le temps comme ça et fait dans le template
• trop de fichier js séparé il faut tout mettre dans mandaye.js, le force-redirect.js doit être rendu générique, il faut qu'il trouve l'URL /Connect.aspx via un champ sur le template du panel ou autre, ou alors un fichier JS dynamique sur une URL /_mandaye/redirect.js qui renverrait:
  

  var mandaye_js_redirects = ['/Connect.aspx'];
  

  
  les valeurs doivent venir de app_settings; l'idée générale c'est qu'il ne faut pas qu'on ait à écrire un autre force.redirect.js ailleurs pour la même fonctionnalité, il faut simplement créér un AppSetting.
• le fichier mandayejs/sites/duonet/static/vincennes/conservatoire/js/vincennes_associate.js je ne sais pas à quoi il sert je ne le vois inclus nul part, je dirais que si c'est une modification à la page "associate" il faudrait que ce soit dans le template, ou alors que ça ne serve à rien par utilisation d'une popup.

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

Il faut sans doute passer sur un autre ticket pour la popup d'association de compte, qui doit en partie être une cellule d'appairage côté combo.

• combo → mandaye : est-ce qu'on est appairé ?
• si oui, ok
• si non,
  • combo → mandaye : quel champs pour l'appairage ?
  • ← identifiant chose, date de naissance, code secret
  • combo affiche la boite de dialogue
  • l'usager valide,
  • combo → mandage : voilà des infos, dis-moi si c'est ok.
  • si ok, bien, on ferme la popup
  • si pas ok, on affiche un message d'erreur dans la popup

On peut voir ce déroulé à partir de https://dev.entrouvert.org/projects/combo/wiki/Mockup_page_de_bienvenue#Saisie-des-infos-de-lusager

Ça ne me semble pas bien compliqué d'ouvrir une iframe sur une page vide à part un formulaire alors je préférerai avoir cet état la fini, on pourra ensuite changer l'URL du bouton associer pour pointer vers cette page combo avec une cellule d'appairage, de plus il faut penser au cas d'un mandaye sans combo. On y est presque.

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

Il faut sans doute passer sur un autre ticket pour la popup d'association de compte, qui doit en partie être une cellule d'appairage côté combo.

• combo → mandaye : est-ce qu'on est appairé ?
• si oui, ok
• si non,
  • combo → mandaye : quel champs pour l'appairage ?
  • ← identifiant chose, date de naissance, code secret
  • combo affiche la boite de dialogue
  • l'usager valide,
  • combo → mandage : voilà des infos, dis-moi si c'est ok.
  • si ok, bien, on ferme la popup
  • si pas ok, on affiche un message d'erreur dans la popup

On peut voir ce déroulé à partir de https://dev.entrouvert.org/projects/combo/wiki/Mockup_page_de_bienvenue#Saisie-des-infos-de-lusager

Ok. Je ferai un ticket pour l'écriture d'un webservice (_mandaye/api/)

Benjamin Dauvergne a écrit :

• il faudrait normaliser les classes et id sur un préfixe mandaye- plutôt que mandaye- de temps en temps et sso- ailleurs
• pour moi il ne devrait y avoir qu'un seul fichier CSS (là je vois un ajout de fontawesome css à la volée) nommé vincennes-conservatoire.css qui éventuellement peut inclure d'autres fichiers CSS avec la directive @import "other.css" par exemple le fontawesome.css
• [...] si sso-url doit être après mandaye-link alors que ce soit tout le temps comme ça et fait dans le template
• trop de fichier js séparé il faut tout mettre dans mandaye.js, le force-redirect.js doit être rendu générique, il faut qu'il trouve l'URL /Connect.aspx via un champ sur le template du panel ou autre, ou alors un fichier JS dynamique sur une URL /_mandaye/redirect.js qui renverrait:
  [...]
  les valeurs doivent venir de app_settings; l'idée générale c'est qu'il ne faut pas qu'on ait à écrire un autre force.redirect.js ailleurs pour la même fonctionnalité, il faut simplement créér un AppSetting.

Ok je vois; je vais faire un ticket

• le fichier mandayejs/sites/duonet/static/vincennes/conservatoire/js/vincennes_associate.js je ne sais pas à quoi il sert je ne le vois inclus nul part, je dirais que si c'est une modification à la page "associate" il faudrait que ce soit dans le template, ou alors que ça ne serve à rien par utilisation d'une popup.

Le fichiers est utilisé dans mandaye/template/mandaye/associate.html. On ne devrait plus en avoir besoin dès que la page d'association passe en popup.