[commhistory-daemon] Reset voicemail notification on number change.

[dcaliste]

I'm impacted by https://forum.sailfishos.org/t/4-0-1-voicemail-notifications-dont-call-voicemail-when-clicked/5049

When I tap on the notification, I'm brought to the call history, even if I've a voicemail number registered and working (long press on 1 in the dialer call the voicemail).

To reproduce on a JollaC:

• get a voice mail,
• tap on the notification, it send you to the call history,
• restart commhistoryd and tap on the notification, it calls the voice mail,
• restart ofono and tap on the notification, it brings you to the call history.

Investigating a bit, the choice between the two destination (voicemail or call history) is based on the voicemail number reported by the QOfonoMessageWaiting object. And it seems that the voicemail number is no always ready when the other properties are.

So the PR is simple : also update the notification when the voicemail number becomes available.

@pvuorela what do you think ?

[dcaliste]

Then it remains the problem that tapping on the notification does nothing, but at least the action stored in the notification is correct :

16235|x-nemo-remote-action-default|com.jolla.voicecall.ui / com.jolla.voicecall.ui dial AAAACQAAAAABAAAACgAAAAAkAHQAZQBsADoALwAvACsAMwAzADYAOQA1ADYAMAAwADAAMQAx

Or supposedly correct, see the journal :

oct. 13 00:38:50 Sailfish lipstick[5845]: Remote action failed: No such method 'dial' in interface 'com.jolla.voicecall.ui' at object path '/' (signature 'av')

[dcaliste]

Last modification before sleeping, it seems that the dial() method of com.jolla.voicecall.ui has changed its interface and not accepting string list any more. From lipstick-jolla-home/qml/main.qml, it seems that a direct number is now the rule.

I've added a commit to use the direct number and now everything is working. @blammit you may like to give your opinion ?

[pvuorela]

Didn't test but both the changes make sense to me.

[dcaliste]

Thanks, the only think that still bothers me a bit is what happens if the QOfonoMessageWaiting suddenly decides that the voicemail number is not known anymore ? The added signal will then updates the notification for the call history. It's desirable if the user actually erase or modify the voicemail number in settings. But could this happen spuriously ? I tried to read the code of OfonoMesaageWaiting to see what could trigger a change in the voicemail number, but I must admit that even if I understand the code paths, I've no idea what external changes could trigger them. So maybe it will never happen, and not having the voicemail available when the other signals are triggered in the notification manager in commhistory, like before this PR, is just a transient state from the SIM read during object initialisation.

[pvuorela]

I'd assume the changes are more related to object being constructed. Values and states appear to be coming via d-bus. And if the number goes missing, could be even justified that it's removed from the notification.

Let's have this. Thanks again for the PR!