Project

General

Profile

Développement #56117

Supprimer la troncature des SMS par défaut ?

Added by Valentin Deniaud over 3 years ago. Updated over 3 years ago.

Status:
Fermé
Priority:
Normal
Target version:
-
Start date:
11 August 2021
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
Planning:
No

Description

Les admins fonctionnels n'en sont pas conscients et ça occasionne des SMS peu intelligibles, cf par exemple #54501.


Files

Associated revisions

Revision 80e84ae6 (diff)
Added by Valentin Deniaud over 3 years ago

sms: increase max_message_length (#56117)

History

#1

Updated by Frédéric Péters over 3 years ago

Et des explications bizarre qui disent qu'à la fois c'est compté pour 3 parce que trop long et à la fois que c'est tronqué. Donc oui, ok. (peut-être quand même tronquer mais à une valeur plus élevée (2000?), pour éviter la bourde d'envoyer un {{form_details}} qui serait super long).

Idéalement aussi à vérifier aussi que c'est ok pour tous les connecteurs.

#2

Updated by Valentin Deniaud over 3 years ago

  • Assignee set to Valentin Deniaud
#3

Updated by Valentin Deniaud over 3 years ago

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

tronquer mais à une valeur plus élevée (2000?), pour éviter la bourde d'envoyer un {{form_details}} qui serait super long).

Ouep, va pour 2000.

Idéalement aussi à vérifier aussi que c'est ok pour tous les connecteurs.

J'ai regardé OVH, twilio, orange j'ai pas trouvé la doc, et découragement là.

#4

Updated by Thomas Noël over 3 years ago

Moi je préférerais un default=2000 bien explicite, donc juste patcher le default=160, pas de "blank=True/null=True" qui va faire disparaître qu'il y a quand même une limite à 2000. Et en plus ça va éviter des migrations, c'est toujours bon à prendre.

#5

Updated by Valentin Deniaud over 3 years ago

Thomas Noël a écrit :

Moi je préférerais un default=2000 bien explicite, donc juste patcher le default=160, pas de "blank=True/null=True" qui va faire disparaître qu'il y a quand même une limite à 2000.

Je vois ça plutôt comme une sécurité catégorie « mécanique interne du connecteur » que comme un truc lié à la fonctionnalité qu'on expose, pouvoir tronquer un message pour éviter tout surcoût.
Concrètement, on a plus de chances que quelqu'un vienne nous dire « il y a un bug, la limite qui était à 160 est passée à 2000, ça n'a pas de sens comme paramétrage ! » que « le SMS de 3000 caractères que j'avais tout à fait l'intention d'envoyer ne passe pas ! » (et dans ce dernier cas on a plutôt envie d'être au courant, histoire de pouvoir répondre « envoie un mail coco »).
Middle ground, l'indiquer dans le help_text qu'il y a une tronquature de sécurité.

Et en plus ça va éviter des migrations, c'est toujours bon à prendre.

Il y a possibilité de plutôt mettre default=0 dans ce cas.

#6

Updated by Thomas Noël over 3 years ago

Valentin Deniaud a écrit :

Thomas Noël a écrit :

Moi je préférerais un default=2000 bien explicite, donc juste patcher le default=160, pas de "blank=True/null=True" qui va faire disparaître qu'il y a quand même une limite à 2000.

Je vois ça plutôt comme une sécurité catégorie « mécanique interne du connecteur » que comme un truc lié à la fonctionnalité qu'on expose, pouvoir tronquer un message pour éviter tout surcoût.
Concrètement, on a plus de chances que quelqu'un vienne nous dire « il y a un bug, la limite qui était à 160 est passée à 2000, ça n'a pas de sens comme paramétrage ! » que « le SMS de 3000 caractères que j'avais tout à fait l'intention d'envoyer ne passe pas ! » (et dans ce dernier cas on a plutôt envie d'être au courant, histoire de pouvoir répondre « envoie un mail coco »).
Middle ground, l'indiquer dans le help_text qu'il y a une tronquature de sécurité.

Je n'ai pas compris. Mettre un default=2000 ne va rien changer aux connecteurs existants qui seront toujours à 160. Pour les futures instances, la limite sera explicitement affichée à 2000, sans besoin de help_text que personne ne lira, et voilà.

Mais peut-être que je rate un truc.

Et en plus ça va éviter des migrations, c'est toujours bon à prendre.

Il y a possibilité de plutôt mettre default=0 dans ce cas.

Roublard :)

#7

Updated by Benjamin Dauvergne over 3 years ago

Valentin Deniaud a écrit :

Et en plus ça va éviter des migrations, c'est toujours bon à prendre.

Il y a possibilité de plutôt mettre default=0 dans ce cas.

Bon déjà en vrai la limite max pour 1 SMS c'est 70 caractères avec de l'unicode (en gros dès qu'on met un accent on passe à 70 si je comprends bien). Je mettrais plutôt par défaut 2000 si c'est ça notre limite, avec un intervalle de valiation entre 70 et 2000 (interdit de mettre plus et voilà). Au lieu de tronquer je refuserai l'appel avec une erreur ça me parait plus normal de faire comme ça, il vaut mieux péter 2/3 notifications lors des tests que d'en tronquer 10000 avant de s'en rendre compte. Et un texte d'explication sur tout ça dans l'interface.

#8

Updated by Valentin Deniaud over 3 years ago

Thomas Noël a écrit :

Je n'ai pas compris

Je disais que c'est un paramétrage par défaut qui provoque un haussement de sourcil (et une fois les sourcils retombé, soit « ah oui ils ont mis 2000 pour limiter la casse » ou « le paramétrage par défaut est nul ça devrait être genre 160 je vais faire un ticket »).

Benjamin Dauvergne a écrit :

Bon déjà en vrai la limite max pour 1 SMS c'est 70 caractères avec de l'unicode (en gros dès qu'on met un accent on passe à 70 si je comprends bien)

Eh non les accents passent en encodage 7-bit, cf https://docs.ovh.com/gb/en/sms/send_sms_messages_via_url_-_http2sms/#appendix_2.

au lieu de tronquer je refuserai l'appel avec une erreur ça me parait plus normal de faire comme ça

Je suis d'accord mais on ne peut pas faire péter tous les connecteurs en changeant ça...

Ou alors idée de plan alternatif, on oublie ce paramétrage, il est déprécié, ça n'intéresse personne de pouvoir dire précisément que la limite c'est 1312 caractères, et le 160 n'a pas de sens parce que la limite c'est peut-être 70, et le 70 n'a pas de sens parce que la limite c'est peut-être 160. Ce qui est intéressant et voulu c'est « je ne veux pas de surcoût » : on peut donc imaginer cette case explicite, décochée par défaut pour les connecteurs existants, et que la cocher refuse avec erreur les SMS qui surcoûtent. Et on intègre l'alphabet du tableau ci-dessous pour savoir prédire si un SMS coûte cher ou pas.

#9

Updated by Frédéric Péters over 3 years ago

Eh non les accents passent en encodage 7-bit (...)

(je n'avais pas vu ce commentaire, j'ai noté la même chose dans #56127#note-2).

on peut donc imaginer cette case explicite, décochée par défaut pour les connecteurs existants, et que la cocher refuse avec erreur les SMS qui surcoûtent

Ou avoir trois valeurs, laisser passer / refuser mais également "faire au mieux la translitération des caractères qui feraient coûter davantage"; i.e. vraiment désolé Émile mais dans le SMS tu es converti en Emile.

#10

Updated by Thomas Noël over 3 years ago

Valentin Deniaud a écrit :

Thomas Noël a écrit :

Je n'ai pas compris

Je disais que c'est un paramétrage par défaut qui provoque un haussement de sourcil (et une fois les sourcils retombé, soit « ah oui ils ont mis 2000 pour limiter la casse » ou « le paramétrage par défaut est nul ça devrait être genre 160 je vais faire un ticket »).

Très clairement : jamais aucun client n'a configuré un connecteur SMS. C'est toujours nous qui le faisons pour eux. Et jamais personne n'a pris conscience des SMS tronqués et des coups des sous-messages (j'en avais parlé, mais pissage dans un violon).

Donc vraiment personne ne va se plaindre de rien, on passe à 2000 par défaut et basta. Et on ne change pas l'existant à 160, parce qu'on ne change pas de système de facturation en cours de projet. Que des SMS tronqués soient émis c'est un problème génant, mais existant ; mais que la facture des SMS double parce qu'on passe tout le monde à 2000, c'est une cata.

Benjamin Dauvergne a écrit :

au lieu de tronquer je refuserai l'appel avec une erreur ça me parait plus normal de faire comme ça

Je suis d'accord mais on ne peut pas faire péter tous les connecteurs en changeant ça...

Oui, on peut pas.

Ou alors idée de plan alternatif, on oublie ce paramétrage, il est déprécié, ça n'intéresse personne de pouvoir dire précisément que la limite c'est 1312 caractères, et le 160 n'a pas de sens parce que la limite c'est peut-être 70, et le 70 n'a pas de sens parce que la limite c'est peut-être 160. Ce qui est intéressant et voulu c'est « je ne veux pas de surcoût » : on peut donc imaginer cette case explicite, décochée par défaut pour les connecteurs existants, et que la cocher refuse avec erreur les SMS qui surcoûtent. Et on intègre l'alphabet du tableau ci-dessous pour savoir prédire si un SMS coûte cher ou pas.

Je pense qu'on se prend la tête pour peanuts alors j'arrête ici, pour moi un patch s/160/2000/ suffit... En parallèle on fait un mail à nos CPF avec la liste des connecteurs SMS instanciés sur le SaaS, pour qu'ils fassent un tour dessus, discutent éventuellement l'affaire avec les clients concernés (spoiler: aucun), et voilà.

#12

Updated by Frédéric Péters over 3 years ago

"faire au mieux la translitération des caractères qui feraient coûter davantage"

(je ne demande absolument pas que ça soit fait ici, et je n'interviendrai pas davantage c'était déjà trop)

#13

Updated by Valentin Deniaud over 3 years ago

  • Status changed from Solution proposée to En cours

Thomas Noël a écrit :

que la facture des SMS double parce qu'on passe tout le monde à 2000, c'est une cata.

Mais le patch ne fait pas du tout ça ?

Je pense qu'on se prend la tête pour peanuts alors j'arrête ici, pour moi un patch s/160/2000/ suffit...

OK je vais faire ce patch et ça fermera le ticket, mais l'aventure continuera dans un autre pour avoir une option pour interdire les surcoûts parce que je pense que c'est ça qui est utile au fond.

#14

Updated by Thomas Noël over 3 years ago

Valentin Deniaud a écrit :

Thomas Noël a écrit :

que la facture des SMS double parce qu'on passe tout le monde à 2000, c'est une cata.

Mais le patch ne fait pas du tout ça ?

Oui, je réagissais à une éventuelle idée de "changer l'existant" (idée qui était sous-entendue parfois, mais peut-être seulement dans ma tête).

Je pense qu'on se prend la tête pour peanuts alors j'arrête ici, pour moi un patch s/160/2000/ suffit...

OK je vais faire ce patch et ça fermera le ticket, mais l'aventure continuera dans un autre pour avoir une option pour interdire les surcoûts parce que je pense que c'est ça qui est utile au fond.

Non, faut rien interdire. Il faut obéir au workflow et envoyer des SMS correctement (non tronqués). Les SMS sont là parce que les mails ça ne marche plus en 2021. Souvent les SMS contiennent des informations vraiment importantes.

Le coût, c'est à nous d'informer les clients que ça peut aller jusqu'à 3 ou 4 unités, et voilà, "ne faites pas des SMS trop longs", et c'est tout. Et si les SMS sont jugés trop chers, alors faut pas les utiliser du tout.

En tout cas c'est mon Humble Avis™.

#15

Updated by Valentin Deniaud over 3 years ago

Valentin Deniaud a écrit :

OK je vais faire ce patch et ça fermera le ticket, mais l'aventure continuera dans un autre pour avoir une option pour interdire les surcoûts parce que je pense que c'est ça qui est utile au fond.

En fait j'imaginais qu'il était coutume de tester son wf avant de le mettre en prod, y compris l'envoi de SMS, et qu'une erreur finale de la part du connecteur permettrait d'alerter en amont sur la nécessité de reformuler le texte du message. Mais en fait comme les SMS vont contenir des variables comme le nom de l'usager, on va vite se retrouver dans le cas où les SMS partent pendant les tests mais pas en vrai. C'était donc une mauvaise idée.

Thomas Noël a écrit :

un patch s/160/2000/ suffit

Voilà ce patch

#16

Updated by Benjamin Dauvergne over 3 years ago

  • Status changed from Solution proposée to Solution validée

Ok.


De mon coté mon sous-entendu depuis le début c'est que les fonctionnels ne savent pas combien coûte vraiment chaque envoi parce qu'on ne l'affiche nulle part, je ne sais pas si c'est vraiment le cas. Il me semble qu'on remonte la consommation globale désormais mais pas pour chaque envoi.

#17

Updated by Valentin Deniaud over 3 years ago

Benjamin Dauvergne a écrit :

De mon coté mon sous-entendu depuis le début c'est que les fonctionnels ne savent pas combien coûte vraiment chaque envoi parce qu'on ne l'affiche nulle part

Oui c'est #56116.

#18

Updated by Valentin Deniaud over 3 years ago

  • Status changed from Solution validée to Résolu (à déployer)
commit adc0cc0648158e5c8431eba6271bafc70a3cb561
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date:   Mon Aug 23 14:25:12 2021 +0200

    sms: increase max_message_length (#56117)
#19

Updated by Frédéric Péters over 3 years ago

  • Status changed from Résolu (à déployer) to Solution déployée
#20

Updated by Pierre Cros over 3 years ago

  • Subject changed from Supprimer la tronquature des SMS par défaut ? to Supprimer la troncature des SMS par défaut ?

Also available in: Atom PDF