Anomalie #682
ferméProblèmes avec le JSON envoyé au script d'enregistrement des contributions
100%
Description
Il y a plusieurs champs qui sont relativement inutilisables en raison de leur valeur changeant selon la traduction employée...
"type" fait partie de ceux là (on peut avoir "Membership"/"Cotisations", "Don"/"Donation"), il faudrait mettre une valeur symbolique non traduite (comme c'est déjà le cas pour "payment/type").
"member/status" a également ce problème. Je suggère de mettre member/status_id avec l'identifiant du statut et member/status_label avec la description textuelle.
"member/organization" lorsqu'il est présent est une chaîne ("1"), ca serait plus logique que cela soit un entier
Et par souci d'homogénéisation, il serait bien que tous les libellés soient systématiquement dans la langue par défaut du galette installé... même si l'utilisateur qui saisit la contribution utilise une autre langue.
Mis à jour par Raphaël Hertzog il y a plus de 11 ans
Il manque également un champ indiquant la date de la contribution.
Mis à jour par Johan Cwiklinski il y a plus de 11 ans
"type" fait partie de ceux là (on peut avoir "Membership"/"Cotisations", "Don"/"Donation"), il faudrait mettre une valeur symbolique non traduite (comme c'est déjà le cas pour "payment/type").
Sauf que les types de paiements, c'est une liste finie, que l'utilisateur ne peut pas configurer ; alors que les contributions et dons sont configurables. Pour le type de paiement, c'est codé en dur...
"member/status" a également ce problème. Je suggère de mettre member/status_id avec l'identifiant du statut et member/status_label avec la description textuelle.
OK. Idem pour type
du coup ?
"member/organization" lorsqu'il est présent est une chaîne ("1"), ca serait plus logique que cela soit un entier
Hum... C'est un booléen à la base, il semble que ce soit l'encodage JSON qui en fasse un chaîne. J'y regarderai. Tu dis "lorsqu'il est présent", ce n'est pas toujours le cas ? Seule la raison sociale est censée ne pas être présente lorsque le membre n'est pas une personne morale..
Et par souci d'homogénéisation, il serait bien que tous les libellés soient systématiquement dans la langue par défaut du galette installé... même si l'utilisateur qui saisit la contribution utilise une autre langue.
Ça, c'est un problème par contre. Il n'est pas prévu dans Galette de modifier la langue à la volée, hormis pour les textes, qui sont récupérés depuis la base. La contribution utilisée pour le script est celle qui est enregistrée, donc fatalement, dans la langue de l'utilisateur.
Il devrait être possible de modifier la langue, puis de la remettre, mais je crains des effets de bord... Ce ne sera pas dans le hotfix qui est en cours.
Mis à jour par Johan Cwiklinski il y a plus de 11 ans
Johan Cwiklinski a écrit :
"type" fait partie de ceux là (on peut avoir "Membership"/"Cotisations", "Don"/"Donation"), il faudrait mettre une valeur symbolique non traduite (comme c'est déjà le cas pour "payment/type").
Sauf que les types de paiements, c'est une liste finie, que l'utilisateur ne peut pas configurer ; alors que les contributions et dons sont configurables. Pour le type de paiement, c'est codé en dur...
Je suis fatigué, je raconte n'importe quoi... Ça ne pose pas de soucis (j'étais parti sur le contribution elle même et non son type, je ne sais pourquoi).
Mis à jour par Raphaël Hertzog il y a plus de 11 ans
Johan Cwiklinski a écrit :
"member/status" a également ce problème. Je suggère de mettre member/status_id avec l'identifiant du statut et member/status_label avec la description textuelle.
OK. Idem pour
type
du coup ?
Ca me va.
Hum... C'est un booléen à la base, il semble que ce soit l'encodage JSON qui en fasse un chaîne. J'y regarderai. Tu dis "lorsqu'il est présent", ce n'est pas toujours le cas ? Seule la raison sociale est censée ne pas être présente lorsque le membre n'est pas une personne morale..
Je me suis vautré, il est bien toujours présent, soit "" soit "1". Ca me va ainsi. "0" aurait été embêtant car c'est une chaine non-vide qui est évaluée à vrai en contexte booléen.
Ça, c'est un problème par contre. Il n'est pas prévu dans Galette de modifier la langue à la volée, hormis pour les textes, qui sont récupérés depuis la base. La contribution utilisée pour le script est celle qui est enregistrée, donc fatalement, dans la langue de l'utilisateur.
Il devrait être possible de modifier la langue, puis de la remettre, mais je crains des effets de bord... Ce ne sera pas dans le hotfix qui est en cours.
Je l'ai signalé comme "nice to have" mais ce n'est pas très grave...
Mis à jour par Johan Cwiklinski il y a plus de 11 ans
- Statut changé de Nouveau à Résolu
- % réalisé changé de 0 à 100
Appliqué par commit 1b5b665ac7a2aec69133418f36a18e7479b7b17b.