Produits Entr'ouvert » Passerelle

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.

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.

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.

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 :)

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.

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.

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.

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à.

"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)

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™.

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.