Produits Entr'ouvert » Intégrations graphiques Publik

Je vous sollicite pour ne pas partir en travers dès le début.

Vu la cellule ./publik-base-theme/templates/portal-agent/combo/json/phone-calls.html (https://dev.entrouvert.org/issues/30827)
que je colle dans mon /var/lib/combo/tenants/agent-combo.dev.publik.love/
que je configure pour pointer sur le connecteur phonecalls (https://dev.entrouvert.org/issues/29829)

Si sur la page du portail agent si j'ajoute un champ recherche,
et si via le connecteur je signale un appel en cours :

$ curl 'https://passerelle.dev.publik.love/phonecalls/allo/call-start?callee=123&caller=456'

Ici, j'ai l'impression que les numéros de téléphone des usagers ne sont pas pris en compte dans la recherche. Il me manque un paramétrage ?

• en JS pré-remplir le champ recherche avec ce numéro et lancer la recherche

Comme l'indique Fred, le pré-remplissage est déjà fait, mais par contre j'ai l'impression qu'il reste à déclencher automatiquement la recherche ?

• compléter tous les liens fiches utilisateurs affichées par la recherche avec ?phone=xxx

Donc en JS aller compléter le lien de la fiche utilisateur, un peu comme c'est fait pour pré-remplir le champ recherche avec le numéro de l'appelant.
Cela pourrait être codé également dans phone-calls.html, lors du déclenchement de la recherche ?
Ou parce que les cellules sont asynchrone, faudrait-il ajouter ce code dans combo/apps/search/templates/combo/search-cell-results.html qui irait scruter une hypothétique cellule phone-calls sur la page ?

• puis coté fiche usager
  • récupérer phone=xxxx dans la query-string
  • compléter tous les liens .../backoffice/... avec ?channel=phone&phone=xxx

Donc idem, ajouter du JS pour compléter les liens dans combo/apps/wcs/templates/combo/wcs/backoffice_submission.html ?

Vu la cellule ./publik-base-theme/templates/portal-agent/combo/json/phone-calls.html (https://dev.entrouvert.org/issues/30827)
que je colle dans mon /var/lib/combo/tenants/agent-combo.dev.publik.love/

Non, le gabarit devrait être trouvé tout seul.

Ici, j'ai l'impression que les numéros de téléphone des usagers ne sont pas pris en compte dans la recherche. Il me manque un paramétrage ?

Il faut que le champ soit configuré pour être pris en compte dans les recherches. (case à cocher dispo via la modification du profil dans hobo). Il faut aussi que le champ recherche soit configuré pour chercher dans les usagers.

Comme l'indique Fred, le pré-remplissage est déjà fait, mais par contre j'ai l'impression qu'il reste à déclencher automatiquement la recherche ?

Non ça doit se faire tout seul, via ce code dans phone-calls.html :

                if (new_caller) {
                  $('.combo-search-input').val(new_caller).trigger('change');
                }

puis coté fiche usager

Il manque d'abord le moment où sur la page avec le champ recherche les liens appropriés sont modifiés pour avoir phonecall=<...> ajouté à leur querystring. (liens appropriés : ceux de la cellule "nouvelle demande" + ceux vers les utilisateurs, dans les résultats de la recherche).

Nicolas Roche a écrit :

• en JS pré-remplir le champ recherche avec ce numéro et lancer la recherche

Comme l'indique Fred, le pré-remplissage est déjà fait, mais par contre j'ai l'impression qu'il reste à déclencher automatiquement la recherche ?

Si tu ne vois rien dans le code JS de phonecalls.html c'est que ce n'est pas fait et oui ce ticket demande d'ajouter ça.

• compléter tous les liens fiches utilisateurs affichées par la recherche avec ?phone=xxx

Donc en JS aller compléter le lien de la fiche utilisateur, un peu comme c'est fait pour pré-remplir le champ recherche avec le numéro de l'appelant.

Oui mais ça va peut-être demander de te hooker dans la partie recherche une fois déclenchée, parce que je suppose que c'est asynchrone, i.e. tu reçois le numéro, ça pré-remplit le champ recherche, tu déclenches la recherche, là tu dois attendre un évènement qui te dise que la recherche est terminée et les résultats affichés pour maintenant chercher les liens vers les fiches usagers qui sont affichées et venir les compléter avec ?phone=456.

Cela pourrait être codé également dans phone-calls.html, lors du déclenchement de la recherche ?

Je ne connais pas le code JS de la recherche, peut-être émet-t-il déjà le bon évènement pour pouvoir agir quand les résultats sont affichés sinon il faudrait l'ajouter (un truc genre document.trigger('publik:search-finished'), il faut lire le code de cette partie pour voir si un signal quelconque n'est pas déjà produit.

Ou parce que les cellules sont asynchrone, faudrait-il ajouter ce code dans combo/apps/search/templates/combo/search-cell-results.html qui irait scruter une hypothétique cellule phone-calls sur la page ?

Oui voilà comme je dis plus haut, mais dans l'autre sens, search-cell-results doit reste agnostique et juste émettre un event "j'ai terminé" c'est phone-calls qui réagira.

• puis coté fiche usager
  • récupérer phone=xxxx dans la query-string
  • compléter tous les liens .../backoffice/... avec ?channel=phone&phone=xxx

Donc idem, ajouter du JS pour compléter les liens dans combo/apps/wcs/templates/combo/wcs/backoffice_submission.html ?

Oui, à moins que ce soit possible en python dans les cellules soumission backoffice et que ça ait la préférence de quelqu'un, de mon coté j'ai compris que le JS ne posait pas de problème ici (je reste prudent).

PS: mais dans ce cas ça demandera un ticket sur combo en plus de celui-ci.

J'ajoute une chose, dans le cas Toulouse (et peut-être dans le cas général en fait), il faudrait aussi compléter tous les liens sur la page de recherche avec une &?phone(call)=456&. Si on prend le cas de Toulouse sur https://agents-moncompte.cutm-ea-dev-publik.nfrance.com/, si la recherche ne donne rien, l'agent va cliquer sur le lien "Saisie backoffice" pour aller choisir un formulaire à remplir, il faudra dans ce cas, même sans fiche usager, passer le numéro à la soumission backoffice (donc ici avoir un lien https://agents-moncompte.cutm-ea-dev-publik.nfrance.com/saisie-backoffice/?phone=456), à la fois pour garder le numéro dans le contexte de soumission mais aussi certainement pour remplir un champ téléphone de contact du formulaire.

Pour ne pas se prendre la tête je me dis qu'on peut ajouter ?phone=456 à toutes les URLs de la page ou est intégré phonecalls.html et qui pointent vers le même portail (pas de netloc ou alors netloc == window.location.hostname).

Pour la cellule backoffice submission après avoir vu comme ça fonctionne, j'ai l'impression qu'il sera plus rapide de directement patcher son template comme cela :

diff --git a/combo/apps/wcs/templates/combo/wcs/backoffice_submission.html b/combo/apps/wcs/templates/combo/wcs/backoffice_submission.html
index f126db45..f35955fe 100644
--- a/combo/apps/wcs/templates/combo/wcs/backoffice_submission.html
+++ b/combo/apps/wcs/templates/combo/wcs/backoffice_submission.html
@@ -10,7 +10,7 @@
   {% for category_formdefs in categories_formdefs %}
     <li><h4>{{ category_formdefs.grouper }}</h4></li>
     {% for formdef in category_formdefs.list|dictsort:"title" %}
-      <li><a href="{{formdef.backoffice_submission_url}}?NameID={{name_id}}&ReturnURL={{ absolute_uri|iriencode }}">{{formdef.title}}</a></li>
+       <li><a href="{{formdef.backoffice_submission_url}}?NameID={{name_id}}&ReturnURL={{ absolute_uri|iriencode }}{% if request.GET.phone %}&channel=phone&phone={{ request.GET.phone|urlencode }}{% endif %}">{{formdef.title}}</a></li>
     {% endfor %}
   {% endfor %}
   </ul>

ou alors d'introduire un point d'extension avec un {% block formdef-url-extra-query-string %}{% endblock %} à surcharger dans le thème.

J'ajoute une chose (...)

Oui, j'écrivais ça plus haut :

Il manque d'abord le moment où sur la page avec le champ recherche les liens appropriés sont modifiés pour avoir phonecall=<...> ajouté à leur querystring. (liens appropriés : ceux de la cellule "nouvelle demande" + ceux vers les utilisateurs, dans les résultats de la recherche).

      // head insert caller into querystring (do not append to ReturnURL parameter)

J'ai l'impression que tu te compliques la vie pour rien tu peux juste faire + ('?' in url ? '&' : '?') + 'channel=phone&phone=' + encodeURIComponent(phone) ça n'est pas possible que tu étendes la valeur de ReturnURL.

Ça explique aussi pourquoi dans l'autre ticket tu as mis le block au milieu de l'URL.

j'ai utilisé l'objet URL pour parser l'URL, qui n'est pas bien supporté par Safari sur iOS : https://developer.mozilla.org/fr/docs/Web/API/URL/URL

L'incompatilité Safari c'est juste un bug (si url est undefined, new URL lancer une exception TypeError, je pense qu'on s'en fout), je suis plus gêné par l'incompatibilité totale avec IE, il me semble que IE 11 fait toujours partie de la cible. Donc je dirai qu'il ne faut pas utiliser cette API qui n'apporte pas grand chose. Les cellules et le moteur de recherche ne produisant que des URLs relatives, je pense que tu peux te contenter de ne compléter que celles-ci.

Que se passera-t-il s'il n'y a plus d'appel en cours et qu'on revient sur la page et qu'on a pas cliqué sur release line ? J'ai l'impression que le dernier caller enregistré dans le localstorage sera ajouté aux URLs (et idem si on reste sur la page et qu'on fait une recherche quelconque alors qu'un appel est en cours ou l'a été). Les gens ne feront vraisemblablement jamais de clic sur release lines (et autant que faire se peut il faudrait qu'ils n'aient pas à s'en servir, je pense que c'est ce qu'on va me demander demain).

Je dirai que tout changement manuel au champ de recherche devrait virer le caller sauvegardé, idem quand on arrive sur la page "from scratch", idéalement on ne devrait pas conserver d'état entre deux recherches, donc dans search-finished il faudrait remettre window.localStorage.caller à zéro. On est même pas certain que search-finished sera bien toujours appelé.

En y réfléchissant autrement, modifier href est peut-être un peu casse gueule, on pourrait à la place intercepter les clicks sur les liens,

function complete_url_with_phone(url) {
   if (window.localStorage.caller) {
      url = ....;
   }
   return url;
}

function is_relative_url(url) {
  return ! ('//' in url);
}

$(window).on('a', 'click[href=*]', function (event) {
  var a = event.target;
  if (! a.href || ! is_relative_url(a.href)) {
      return true;
  }
  var url = complete_url_with_phone(a.href);
  if (a.target) {
    window.open(url, a.target);
  } else {
    window.location = url;
  }
  event.preventDefault();
  return false;
}}

ensuite on pose le caller sur un nouvel appel qui apparaît ou click sur un appel (c'est déjà le cas dans ton patch) et on retire le caller si on a un évènement onchange natif (tu peux passer un argument supplémentaire à trigger pour faire la différence :

$(search_input).trigger('change', ['caller'])

$(search_input).on('change', function (event, origin) { 
  if (origin != 'caller') (
    set_caller(undefined);
  }
})

à ton avis ?

J'en rajoute une couche.

On est clairement dans une interaction modale, et cela sur au moins deux pages, la page d'accueil du portail agent et les fiches usagers. Soit un appel est en cours ou sélectionné, alors une référence à celui-ci doit être ajoutée aux URLs de soumission backoffice. localStorage est un bon moyen de stocker ça, il n'y a pas de doute.

Mais il faudrait afficher à l'utilisateur qu'on est dans cette situation, genre avec un bandeau en haut de page "Appel en cours du xx.xx.xx.xx.xx, les demandes seront liées à cette appel [ X ]", un click sur le X supprimerait ce mode (bandeau à afficher aussi en fiche utilisateur je suppose).

Aussi si l'information est dans localStorage on a pas besoin de la passer dans les URLs vers la fiche usager, uniquement dans les URLs vers w.c.s.

Il manque un trigger dans set_caller() pour prendre en compte le changement sur la page en cours :

$(document).trigger('combo:submission-context-update');

J'ai testé avec cette modif et tout marche bien.

Nicolas Roche a écrit :

Aussi si l'information est dans localStorage on a pas besoin de la passer dans les URLs vers la fiche usager, uniquement dans les URLs vers w.c.s.

Vu que la passe à WCS est faite par #48503 en fait il n'y a plus aucun de lien à surcharger/modifier à la volée ici.

Oui.

à ton avis ?

Je n'avait pas compris ces histoires de portée avec localStorage/sessionStorage, c'est drôlement casse gueule du coup tout ça, mais bon c'était déjà comme ça avec callee.

Je pense que passer par un storage rend les raisonnement plus simple soit on est dans un contexte.

Mais il faudrait afficher à l'utilisateur qu'on est dans cette situation, genre avec un bandeau en haut de page "Appel en cours du xx.xx.xx.xx.xx, les demandes seront liées à cette appel [ X ]", un click sur le X supprimerait ce mode (bandeau à afficher aussi en fiche utilisateur je suppose).

Puisque ça n'affecte que la saisie backoffice autant le faire uniquement dessus non ?

Fred pense que ce serait mieux d'avoir l'affichage de ce contexte dans une sidebar, on verra comment faire ça sur https://agents-moncompte.cutm-ea-dev-publik.nfrance.com/allo-toulouse/ quand le design de la l'accueil des agents sera défini; dans un premier temps ça pourra se simuler très facilement avec un script dans une cellule texte donc pas besoin de statuer là dessus maintenant.

Mais peut-être aussi qu'on remettra la cellule appel téléphonique sur la fiche usager en barre de droite.