Closed memento closed 9 years ago
RaspbianFrance
commented
9 years ago Salut, je pense qu'il faut effectivement privilégier les numéros internationaux, mais il me semblerait dommage d'imposer ce choix aux utilisateurs. D'autant que c'est une notation qui n'est vraiment pas naturelle.
Nous pourrions peut-être ajouter une petite ligne d'avertissement dans les formulaires contenant des numéros.
RaspbianFrance
commented
9 years ago Nous venons d'ajouter le message précédemment évoqué sur l'envoi de SMS et la création de contacts !
memento
commented
9 years ago En fait, c'est aussi gênant pour la gestion des accusées de réception car quand un accusé arrive, il est signé par un numéro au format international alors que le contact peut être enregistré avec un numéro au format local. Du coup, pas de correspondance possible entre le message précédemment envoyé et l'accusé de réception.
Je propose de couper la poire en deux. Plutôt que d'imposer à l'utilisateur d'écrire un numéro en +336..., je propose le traitement suivant à l'ajout du contact :
Si le numéro est à 10 chiffre (pour être sûr) et qu'il commence par un "0", alors on transforme le numéro de la forme 0123456789 vers la forme +33123456789 juste avant l'ajout dans la base de données. ça peut être rajouté comme fonction dans la classes des utilitaires.
Remarque : C'est vrai que quand je suis dans la rue ( :) ) et que j'entre un nouveau contact dans mon répertoire, ça peut m'arranger de n'entrer que la forme locale par contre ça ne me dérange pas si le numéro est converti sans effort de ma part.
Qu'en pensez-vous ?
Bien à vous.
memento
commented
9 years ago Remarque 2 : En plus, quand on entre des contacts, parfois on a le courage de taper le +336... et parfois non. Du coup, le répertoire n'est pas "beau" car la liste des numéros n'est pas régulière (oui, je suis un _geek maniac_).
Ok, c'est un argument qui pèse pour la moitié d'un mais pour les maniaques du contrôle comme moi, ça compte et force est de constater que chez les utilisateurs de Raspberry Pi, il doit y en avoir beaucoup.
Bon allez, je n'insiste plus, j'attends votre réponse.
RaspbianFrance
commented
9 years ago Nous avions déjà pensé à cette solution, mais elle n'est pas viable en pratique. Le 0 correspond à +33 pour la France, mais il correspondra à une valeur complètement différente pour la Belgique par exemple.
À la limite, il serait envisageable d'ajouter une configuration supplémentaire qui permette d'activer l'auto-transformation des numéros, et une autre qui permette de définir la chaîne de remplacement.
RaspbianFrance
commented
9 years ago Nous sommes entrain de finir le code des accusés de réception. Au passage, nous mettons à jour la version de Descartes utilisée par RaspiSMS (nous en aurons besoin pour pouvoir gérer plus en détails les requêtes SQL, ce qui sera nécessaire pour gérer les accusés de réception de façon élégante).
Nous réglerons le problème des numéros internationaux juste après.
memento
commented
9 years ago Oui, effectivement, bien vu ! Le traitement devrait changer selon la nationalité et il n'y a pas que le nombre de chiffres composants le numéro égal à 10 qui rentre en jeu.
Pour les accusés, j'espère que mes indications dans les issues vous ont servis. Vous pensez avoir terminé quand ? Je continue tout de même de mon côté (pour le sport) ;)
Pour les accusés, je prends une logique de pile (first in, first out) et je ne peux pas être plus précis que ça étant donné que les accusés n'arrivent pas avec un timestamp ou un id du message précédemment envoyé. A moins que vous ayez trouvé un contournement ?
Vous servez-vous d'une fonctionnalité de Gammu, ou bien une pile (comme moi) ?
RaspbianFrance
commented
9 years ago Nous utilisons également une pile (il ne semble hélas pas exister de méthode plus précise). Nous aurons probablement fini d'ici une ou deux heures ;)
RaspbianFrance
commented
9 years ago Les accusés de réception sont en place. Le système de pile n'est pas parfait mais nous avons essayé d'améliorer le tout en ne prenant en compte que les SMS en attente de réception depuis moins de 24h !
memento
commented
9 years ago Une ou deux heures ? Génial !
Pour la précision, il faut passer Gammu en mode base de données (par exemple MySQL). Là, nous sommes en mode fichier. Il faut savoir qu'en mode base de données, lorsqu'un accusé arrive, la ligne de la table des SMS envoyés dans la base de données est automatiquement mise à jour avec le statut.
Ainsi, une simple requête vers la base de données de Gammu peut nous renseigner. On pourrait ainsi implémenté le tout comme une tâche périodique visant à synchroniser les informations contenues dans les deux tables des bases de données.
Au passage, si on avait pris Gammu en mode base de données, il y aurait eu moins de boulot pour RaspiSMS en général car on n'aurait eu qu'à attaquer la base de données (pour tout un tas d'actions, comme envoyer un sms sans avoir à attendre la minute suivante pour l'envoi). Cependant, c'est le lot de tout projet mené avec engouement et il fallait bien choisir une voie.
Bravo à vous !
Pour RaspiSMS en parallèle de Gammu en mode MySQL, ça peut toujours faire l'objet d'une version 2.X, qui sait ! Comme à mon habitude, je posterai mes dernières pistes à ce sujet (entre autre). J'ai dû interrompre le développement de la gestion des accusés pendant quelques semaines vu la quantité de taf au bureau.
J'ai hâte de voir votre approche du problème des accusés.
Bonne soirée !
RaspbianFrance
commented
9 years ago À la base le projet a été pensé pour gammu et pas gammu-smsd. Par ailleurs, le mode base de données nous demanderais toujours de passer par des méthodes d'envoi utilisant les lignes de commande afin de remplir correctement l'ensemble des champs.
En revanche, il serait envisageable de créer un système permettant de faire le lien entre les deux bases de données afin de récupérer des informations plus précises, notamment sur l'état des SMS.
memento
commented
9 years ago _Attention_ : sauf erreur de ma part, votre approche ne prend pas en compte qu'un accusé de réception n'est lié qu'à une tranche de 160 caractères du message. Du coup, par exemple, pour un message de 165 caractères (2 accusés), suivit d'un message de 10 caractères (1 accusé) au même destinataire, vous recevrez 3 accusés au lieu de deux pour le même numéro. C'est la limite principale de l'approche par pile "aveugle" (sans id ou timestamp lié au message envoyé qu'il désigne).
Pour contourner ce problème, de mon côté, j'ai ajouté un champ "slices_to_confirm" (tranches à confirmer) qui est renseigné dès l'ajout du message à la table sendeds avec le nombre de sms qui composent le message (Cf. modulo et division entière de la longeur du message par l'entier 160). Ensuite, à chaque traitement d'accusé concernant le destinataire, je décrémente le champ "slices_to_confirm" et quand il arrive à zéro, j'en profite pour passer le message en "Delivered". Mission accomplie. Je me suis même permis le luxe de gérer les accusés de réception "Failed" et plus particulièrement quand, dans le flot de sms de 160 caractères, il y en avait un qui foirait ("Failed"). Résultat, je décrémente toujours le champ "slices_to_confirm" mais si par malheur j'ai un "Failed" dans le lot, je passe directement le message en "Failed" et ce dernier ne sera plus mis à jour.
On était au coude à coude, ce soir. ;)
reposez-vous bien !
RaspbianFrance
commented
9 years ago Bien vu, nous avions totalement oublié le cas des SMS de plus de 160 caractères. Nous allons regarder ça !
RaspbianFrance
commented
9 years ago Et voilà, c'est mis en place !
memento
commented
9 years ago Fantastique, je vais voir !
memento
commented
9 years ago Comme je l'ai dit plus tôt, le format local des numéros pose des problèmes.
Le dernier en date : L'acceptation du format local de numéro (0612345678) à la création du contact, ou encore à la création d'un message en utilisant le champ "Numéros cibles" _fait échouer le système de gestion des accusés de réception_. En d'autres termes, tout message envoyé à un numéro en 06 ne sera officiellement _jamais délivré_. La raison est que le réseau GSM renverra _toujours_ l'accusé de réception avec un format de numéro international.
Pour un message envoyé au 0612345678, je recevrai un accusé semblant venir du +33612345678. Cet accusé ira donc aux oubliettes. _Pire : il pourrait être lié à tort à un SMS plus ancien (envoyé en +336...), toujours pas "delivred" car perdu, par exemple._
Dans les deux formulaire, pourquoi ne pas proposer (à gauche du champ numéro) une petite combobox sympa avec un drapeau (mis par défaut sur la France) et/ou proposant l'indicatif du pays (par défaut +33) ?
La gestion des accusés de réception est une superbe valeur ajoutée pour le projet, ce serait dommage, même si ce n'est que mon avis.
Bien à vous !
memento
commented
9 years ago J'ai vu que vous utilisiez JQuery. Voilà un bon exemple pour le numéro de téléphone : ici.
ça donne ça :
RaspbianFrance
commented
9 years ago Ce système a l'air assez prometteur, je ferais peut-être quelques tests ce soir ! Le problème sera de faire cohabiter ce plugin avec celui permettant l'auto-complétion des groupes, etc. Je verrais si j'arrive à faire un système assez propre !
memento
commented
9 years ago Cool !
memento
commented
9 years ago Dans templates/scheduleds/add.php, par exemple, on a une combobox qui est surement chargée de faire de l’auto complétion. Or, on ne fais jamais appel à un historique ou autre du coup, j'ai l'impression que cette combobox ne sert à rien. Qu'en penses-tu ?
RaspbianFrance
commented
9 years ago Nous venons d'ajouter l'auto-complétion des numéros avec préfixes internationaux. Nous avons retenu la solution du plugin présenté plus haut !
Nous ajouterons un réglages permettant de choisir les langues préférées et la langue par défaut pour les numéros très rapidement !
RaspbianFrance
commented
9 years ago Nous avons ajouté les réglages sur l'internationalisation des numéros (pays par défaut et pays préférés). Nous avons également unifié les réglages.
memento
commented
9 years ago Génial !
Nico80
commented
8 years ago Bonjour, à tous, Petite question à propos du +33, comment le passer dans une URL. J'ai essayé plusieurs possibilités mais rien ne marche... http://192.168.1.35/RaspiSMS/smsAPI/?email=****************@yahoo.fr&password=*****&numbers=33623******&text=test54
http://192.168.1.35/RaspiSMS/smsAPI/?email=****************@yahoo.fr&password=*****&numbers=+33623******&text=test54 Rien ne marche...
seul le 0623****\ fonctionne. Si vous avez une idée. Merci.
RaspbianFrance
commented
8 years ago Salut, je pense qu'il faut que tu convertisses le caractère "+" en son équivalent au format url "%2B". Le 10 janv. 2016 12:45, "Nico80" notifications@github.com a écrit :
Bonjour, à tous, Petite question à propos du +33, comment le passer dans une URL. J'ai essayé plusieurs possibilités mais rien ne marche...
http://192.168.1.35/RaspiSMS/smsAPI/?email=****************@yahoo.fr&password=*****&numbers=+33623******&text=test54 Rien ne marche...
seul le 0623****\ fonctionne. Si vous avez une idée. Merci.
— Reply to this email directly or view it on GitHub https://github.com/RaspbianFrance/RaspiSMS/issues/23#issuecomment-170337722 .
Nico80
commented
8 years ago Merci bonne idée, c'est vrai j'ai pas pensé à ça... Je vais tester.
C'est bon ça marche, merci encore pour votre aide... http://192.168.1.35/RaspiSMS/smsAPI/?email=**********@yahoo.fr&password=*****&numbers=%2B3362*******&text=test55
Le 10 janv. 2016 à 13:39, Raspbian France notifications@github.com a écrit :
Salut, je pense qu'il faut que tu convertisses le caractère "+" en son équivalent au format url "%2B". Le 10 janv. 2016 12:45, "Nico80" notifications@github.com a écrit :
Bonjour, à tous, Petite question à propos du +33, comment le passer dans une URL. J'ai essayé plusieurs possibilités mais rien ne marche...
http://192.168.1.35/RaspiSMS/smsAPI/?email=****************@yahoo.fr&password=*****&numbers=+33623******&text=test54 Rien ne marche...
seul le 0623****\ fonctionne. Si vous avez une idée. Merci.
— Reply to this email directly or view it on GitHub https://github.com/RaspbianFrance/RaspiSMS/issues/23#issuecomment-170337722 .
— Reply to this email directly or view it on GitHub.
memento
commented
8 years ago Bonjour,
Merci pour le %2B à la place du +, ça peut toujours servir !
_C'est d'ailleurs quelque chose qui pourrait être ajouté à la doc, dans une partie FAQ._
Bonne journée !
Bonjour,
Concernant les contacts, il faudrait obliger l'utilisateur à entrer le numéro au format international à la création d'un contact car quand on reçoit un message en réponse, c'est toujours au format +336xxxxxxxx. Du coup, RaspiSMS l'identifie comme étant un numéro inconnu et la conversation est "cassée".
Bien à vous !