Lors de l'envoi d'une information par email par exemple, le From
du mail ne contient que l'adresse mail du contact. Voir à le rendre plus sexy en rajoutant par exemple une concaténation du nom et du prénom de contact concerné, ou la dénomination du membre associé.
Par exemple, soit un membre *Secrétariat de MonAsso avec un contact d'adresse email secretariat@domain.tld
. Actuellement le mail envoyé contient l'en-tête From: secretariat@domain.tld
et dans les outils de lecture de mails seul l'adresse email s'affiche. Avec cette modification, on aurait l'en-tête From: Secrétariat de MonAsso <secretariat@domain.tld>
et dans les outils de lecture de mails apparaîtrait Secrétariat de MonAsso, pour les outils qui gèrent cela correctemnt
OLIGAA est toujours opérationnelle, mais avec des versions de ruby
, rails
, et autres multiples gems qui sont obsolètes voire plus maintenues : et ce n'est pas acceptable
Dans le détail :
ruby
: 2.3.6
, plus maintenue depuis le 31/03/2019
rails
: 5.1.7
, plus maintenue depuis le 25/08/2019
mariadb
: 10.1.48
, plus maintenue depuis le 17/10/2020
Il serait donc de bon ton, a minima, de faire des montées de version pour atteindre :
ruby
3.0
rails
6.1
Beaucoup de travail en perspective, dont une partie a déjà été débroussaillée dans #113 mais pas intégré
@trasibulle nous a contacté pour nous informer d'un problème de synchronisation des événements du site vers Google Agenda.
Les événements créés sur le site avec un type d'événement synchronisé sur GA doivent apparaître dans le calendrier GA.
Cf. #102
Lorsqu'on réinitialise le mot de passe d'un utilisateur, il est indiqué qu'un mail a été envoyé mais le mail ne part jamais si l'adresse email de contact n'est pas fournie dans les paramètres : FROM
absent...
Pour cette branche issue de la MR !110, l'idée est donc de supprimer les cassettes VCR enregistrées avec l'ancienne version de la gem Google API pour enregistrer les requêtes de la nouvelle version.
Pour l'instant, je suis bloqué à l'authentification, Google m'informant que l'utilisateur n'a pas les droits nécessaires pour accéder à ces ressources, alors que semble bien configuré dans l'IAM chez Google
Considérant la chronophagie du sujet et nos autres priorités, m'est avis que tu ne devrais t'y atteler avant mon retour que si cette énigme t'empêche de dormir…
David F. (0385c756) at 20 Aug 14:46
Working on Google API update with VCR re-recording. #113
... and 19 more commits
Vu avec @trasibulle par téléphone ce jour :
A priori oui. Pour moi la première fonctionnalité à mettre derrière un flag est la plateforme, très spécifique au CDSA33.
Les modules qui sont identifiés ici sont toujours d'actualités ?
Non pas du tout. Je l'avais enlevé à la base, ça ne changeait rien. Je l'ai remis temporairement, parce qu'ils y étaient avant que je retouche le code. Cela me semblait bizarre aussi, mon avis aurait été de l'enlever.
Tous ces to_json
m'étonnent, vu que le code et la doc indiquent tous les deux qu'il faut lui passer un objet, et pas une chaîne de caractère JSON… Ça fonctionne mieux comme ça en pratique ?
Alexandre Friquet (03c29dac) at 22 Jul 13:25
Il me semble ici avoir trouvé la bonne syntaxe, ça me parait plus que plausible. Cela dit headers: {'Content-Type' => 'application/json'})
disparait. Comme pour les attributs de signet, j'ai l'impression que le Content-Type est soit plus nécéssaire soit plus utilisable. J'ai tenté de placer un event.to_json
en me référent à cette méthode (def to_json) rien. De là survient surement ce problème MultiJson::ParseError:765: unexpected token at ''
. J'ai du mal gérer l'histoire du JSON et cela me donne l'impression d'avoir fourni un champs vide. En même temps cela me semble être en rapport avec l'auth.
J'ai un peu l'impression que Google monte les versions et lâchent des petits trucs ici et là sans nécéssairement pensé un remplacement. Signet n'à pas l'air d'avoir changé mais j'eut l'impression que certains attributs avaient sauté.
Considérant les passages de la doc de migration que je mets en gras :
In the 0.9 version of this library, the authentication and authorization code was moved to the new googleauth library. While the new library provides significantly simpler APIs for some use cases, not all features have been migrated. Missing features are expected to be added by end of Q2 2015.
The underlying Signet is still used for authorization. OAuth 2 credentials obtained previously will continue to work with the 0.9 version. OAuth 1 is no longer supported.
J'ai l'impression que :
person
) fait partie de ces fonctionnalités qui n'ont pas été migrée ;Signet
brut comme on le fait là sans changer grand chose…Je continue de parcourir le code de google-api-ruby-client
pour transformer ces impressions en certitudes, pendant que @Cefin s'occupe du travail de fond…
P.S.: ce message n'est pas parti hier… Toujours à peu près d'actualité, dans les grandes lignes en tout cas.
Juste pour lancer le débat
Je me demande s'il ne serait pas mieux d'utiliser le fichier json
comme ici.
L'avantage principal c'est que toutes les infos sont directement dans le fichier et donc pas besoin d'utiliser des variables d'environnement mais surtout on utiliserait l'API publique de google-auth
sans aller voir comment c'est implémenté à l'intérieur.
Les inconvénients majeurs sont qu'il va falloir