I noticed today the first time, that the SMS app do not want / do not allow me to send a sms to a number that is one digit longer as usual. Without the country prefix 12 instead 11 digits. The send button is deactivated and I can not type any text. A test with the manually typed in number shows that behaviour. [Provider in DE / SFOS 4.5.0.25].
Anyone seeing this? What controls this?
Since nobody answers… I tried on mine (10iii, 4.5.0.25), I can enter a phone number of any length and the Send button and message typing areas stay activated.
It only deactivates the Send if the phone number is only composed of non-numerical characters, such as letters or special characters. In this case it displays a message just below the number, and deactivates the Send.
It still lets me type the message in all cases.
As soon as at least one numerical character is added to the number, it activates the send.
I did not try to press Send.
Thanks for taking a look. I tested it again, just to avoid some UTF8/16 compat issues, the number is entered manually, without success.
The last digit is the culprit, without it the send button stays activated.
PS:
The info message when greyed out, says “Sender does not support replies”.
Maybe someone knows, where the code has such conditional line.
Are you able to actually send to this number on other phones? How come is is a nonstandard length?
The only way i was able to provoke a greyed-out send button was to not have nay content in the message - and i can’t help but noticing yours at least looks empty in the first picture.
I can type an arbitrarily long phone number, even with +49 and the button stays enabled (though it perhaps doesn’t match any area codes or anything like that).
But FWIW, probably this is based on libphonenumber, and what type of number it thinks it is.
Edit: updated possible length of german mobile phone numbers by DerKobe · Pull Request #3384 · google/libphonenumber · GitHub
(Directed to google internal issue tracker).
PS. don’t look at the commit history, it looks horrendous.
Edit2: Google Issue Tracker
Right now, I am sending to the same number via CLI and dbus calls. Delivery successful.
Could it be the Messaging application recorded this number as one-way? Could it be that you have received messages from this number in the past that came tagged with this property? Did you try other unrelated phone numbers of the same length, or change one or two numbers inside +49…42?
This should be the cause. Does someone knows how to ping Jolla to incorporate a patch for it?
I backported the above mentioned patch to the current (SFOS4.5.0.25) libphonenumber-8.12.33 and rebuild it. Unfortunately, this does not solve my problem. There must be more to do …
How to burn time! Ok, I found the problem. The contact was imported via VCF file with:
...
TEL;CHARSET="UTF-8";TYPE=CELL,HOME:+4912345678901
...
This seems to not be handled very well by jolla-messages application.
When doing the import as
...
TEL;CELL;HOME:+4912345678901
...
I am able to write a message now!
This observation isn’t consistent with your solution blaming the encoding. What is the difference?
The number must not be in the address book as such …