Ajout du bénéficiaire extérieur et du mail des bénéficiares dans les recherches et stats (app.php?p=report)

[Aurely9n]

Bonjour,

Actuellement, la section "recherches et stats" ne permet de rechercher que parmi les bénéficiaires "locaux" (ceux de la db _users) et pas parmi les bénéficiaires extérieurs ce qui me semble être un manque. De plus, le rapport édité ne contient pas l'information de l'email de contact de ce dernier (qu'il soit local ou extérieur), ce qui peut être pratique lorsque on veut les contacter par "batch".
Pour pouvoir rechercher parmi les "benef_ext", j'ai intégré ce bout de code dans "reservation/controller/report.php (l.323)":

if ($champ[$k] == "login"){
  $sql .=  grr_sql_syntax_caseless_contains("e.beneficiaire", $texte[$k], $type_recherche[$k]);  
  $sql .= ' OR ';  
  $sql .=  grr_sql_syntax_caseless_contains("e.beneficiaire_ext", $texte[$k], $type_recherche[$k]);  
} 

Par contre, il faudrait également retourner les mails des bénéficiaires (lorsqu'il existent bien sur) et les ranger dans une colonne à part du tableau (ex: "mail") afin qu'on puisse la manipuler plus facilement.

Cordialement,

[ynaessens]

Bonjour @Aurely9n,
je pense que l'insertion des mails dans les résultats de recherche devrait être soumise à restriction.
Je vois deux issues : le niveau de l'utilisateur qui lance la recherche et la mise en forme sous forme d'un fichier, par ex. csv, pour traitement batch comme vous le suggérez.
Qu'en pensez-vous ?
Cordialement,
YN

[Aurely9n]

Bonjour @ynaessens,

je pense que l'insertion des mails dans les résultats de recherche devrait être soumise à restriction.

Oui je suis d’accord avec votre proposition. Je n'avais pas réfléchi au fait qu'il pouvait y avoir plusieurs type d'utilisateurs sur le système et que tous non pas forcément le droit d'accéder aux mails. Par défaut, les administrateurs devraient avoir accès à cette information. Et le raffinement serait proposer une section dans l'administration qui permet d'autoriser ou non les autres différents rôles à avoir cette information ou non dans la recherche (via un formulaire checkbox peut-être).

... la mise en forme sous forme d'un fichier, par ex. csv, pour traitement batch comme vous le suggérez.

Je ne suis pas sur de comprendre cette remarque.
Moi idée initiale était "simplement" d'ajouter une colonne "mail" aux rapport et tableau déjà existant. Alors ce n'est pas très effectif puisque, si on veut envoyer un mail à toutes les personnes de la liste ainsi générée, il faudra très probablement la nettoyer des nombreux "doublons" mais au moins on aurait l'info.
Effectivement, il serait plus efficace de pouvoir choisir une présentation des résultats qui permettrait de faire un DISTINCT (via requete ou post traitement php) sur le champ mail (ou n'importe quel autre) afin de ne pas avoir ces "doublons" à nettoyer.
Je ne sais pas si je réponds à votre question de mise sous forme de fichier...

Merci pour votre retour en tout cas!

Cordialement,

[Aurely9n]

Bonjour,

Je reviens sur cette discussion pour savoir si ma recommandation pourra être intégrée dans les prochaines futures version de GRR ? Je suis sur la 4.2.0 et pour le moment, la version actuelle de recherche ne permet toujours pas de rechercher parmi les bénéficiaires extérieurs ni d'avoir le mail des bénéficiaires (extérieurs ou pas) dans le rapport produit.

Bien à vous
(Et merci pour le boulot que vous faites hein, j'donne l'impression de râler mais votre outils se bonifie avec le temps et c'est de plus en plus agréable)

[JeromeDevome]

Bonjour,
Non vos remarques sont pertinentes et font évoluer le produit. J'ai intégrer la première partie de votre demande fbd9796 , elle sera dans la version 4.2.2, de ce week-end.

Pour la partie email, cela demande à de la réflexion, pour gérer le mieux la confidentialité. J'image à une table où on enregistre les bénéficiaire ext. avec leurs coordonnées. Elle se remplit via les entrées de réservations, et administrable notamment pour gérer anonymisation des données personnels. Et le champ bénéficiaire pourrais avoir de l'autocomplétion. Il y a un peu de boulot pour faire tout cela :)

[ynaessens]

Bonjour,
pour introduire de l'autocomplétion, il "suffit" d'utiliser un sélecteur de classe select2.
Le point crucial à trancher est qui sera autorisé à accéder aux mails. Restreindre aux administrateurs généraux me semble peu intéressant et autoriser d'autres utilisateurs me pose un problème éthique. Une suppression des adresses dès que la réservation est passée serait-elle RGPD compatible ?

[Aurely9n]

Bonjour,

En ce qui concerne l'ajout d'informations supplémentaires pour les bénéficiaires extérieurs, ma réflexion n'allait pas si loin que ça ^^.
Actuellement, lorsqu'on enregistre un bénéficiaire extérieur, on peut choisir d'ajouter en plus l'information de son mail dans le champs qui va bien. Dans ce cas, GRR enregistre l'info dans le champ "benef_ext" de la table "{prefix}_entry" avec comme motif "patronyme|mail" et en ce qui me concerne, c'est deux infos me suffisent amplement.
Mon avis est que si la le bénéficiaire extérieur doit avoir plus d'infos sur la plateforme alors ce n'est plus un bénéficiaire extérieur à la plateforme et il devrait s'enregistrer comme utilisateur local. Mais ça je pense que c'est mon côté feignant qui s'exprime et ce n'est que mon avis "personnel" par rapport à mon périmètre de travail.

Une suppression des adresses dès que la réservation est passée serait-elle RGPD compatible ?

A mon sens, cela n'a pas d'incidence de supprimer l'adresse une fois que la date est passée. Le principe fondamentale de la RGPD est d'obtenir le consentement éclairé de l'utilisateur dont on souhaite enregistrer les données "personnels" et d'expliquer le cadre et l'utilisation de ces dernières. Du coup, si on lui a posé la question en amont et de dire que son mail sera conservé dans GRR à des fin d'historisation des réservations... Y a aucune raison de supprimer ensuite.

En tout cas, merci encore pour votre travail!