Removing entries from call history programmatically

Applications C++
#1

Hi guys, is someone aware of, and could please point me to, some documentation or example code about how to programmatically (C++) remove entries from the call history?

Sailfish Community News, 10th October 2024 - Factory Visit
#2

So… not possible, or no one knows? :roll_eyes:

#3

Quickly checking think it’s libcommhistory → callmodel/eventmodel → deleteEvent() etc. There’s commhistory-tool on the libcommhistory repository too with c++ implementation.

3 Likes
#4

OK, thanks a lot @pvuorela for your suggestion! It seems to work fine. The following does the job for me:

CommHistory::CallModel::Sorting sorting = CommHistory::CallModel::SortByContact;
    CommHistory::CallModel::ContactResolveType resolve = CommHistory::CallModel::DoNotResolve;
    CommHistory::CallModel model;
        model.setFilter(sorting, CommHistory::CallEvent::CallType::ReceivedCallType);
        model.setResolveContacts(resolve);
        model.setQueryMode(resolve == CommHistory::CallModel::ResolveImmediately ? CommHistory::EventModel::AsyncQuery : CommHistory::EventModel::SyncQuery);

QVector<QStringList> array;
        for ( int i = 0; i < model.rowCount(); i++ )
            {
                CommHistory::Event e = model.event(model.index(i, 0));
                QString text = e.toString();
                array.append(text.split("|"));
            }

        for (int c = 0; c < model.rowCount(); c++)
                {
            if (array[c][9].contains(callingNumber))
            {
                 model.deleteEvent(array[c][0].toInt());
            }
        }

Note that I had to manually split event string to a list / array for easier processing, i.e. something like

QString text = e.toString();
                array.append(text.split("|"));

because I couldn’t make CommHistory::Event::toList() work (the result is always empty). Only CommHistory::Event::toString() works for me, and then I manually split it by the “|” character to e.g. a QStringList.

Note 2: after deleting a call event from commhistory, it doesn’t seem to disappear right away from the list in the History tab of the Voicecall-ui. Sometimes it takes closing and reopening, or even restarting voicecall-ui for it to notice it. Should it be signalled somehow for voicecall-ui to automatically refresh the history?

#6

I still have this problem and can’t find any solution:

After successfully deleting a call event from commhistory (it gets correctly deleted from both the model in the code and from the actual commhistory database), it is still visible in the History tab of the Voicecall-ui (whereas at the same time it is no longer visible on the corresponding contact’s or phone number’s details page where its full communication history is listed - that list is correctly updated and no longer includes the deleted event). But in case of the Voicecall-UI’s “History” tab, it takes killing / restarting voicecall-ui-prestart for that list to get reloaded / refreshed and no longer show the deleted event.

Does anyone know how to trigger Voicecall-ui to refresh the “History” list after deleting an event?

1 Like
#7

It should be done automatically, but sailjail is somehow filtering out the delete event. Still trying to understand why…

1 Like
#8

It is a sandboxing issue. The D-Bus signals emitted by commhistory-tool when modifying the comm history from the command-line were not allowed to enter the jail where the voicecall-ui is.

I’m proposing two PRs to fix this :

2 Likes
#9

Thank you very much for investigating this problem, Damien. I see that both PRs were approved and merged into sailfishos:master, so hopefully we’ll see it fixed soon.

1 Like
#10

Yes, the fix are part of 5.0.0.

Besides, I know you’ve been interested in call blocking and worked on a solution. With 5.0.0, will also come a call blocking function. It’s integrated in the UI, but it also provides an API for third party applications. You can register an application (with the proper rights) as a call filtering application. Then, on an incoming call, the voicemanager is broadcasting it over D-Bus, as normal, but postpones the ringing (and UI reaction) until it receives back a filtering approval over D-Bus. I don’t remember what I put, maybe something like one second or two as a grace period before the voicemanager let the incoming call pass through anyway if no filtering application is answering.

4 Likes
#11

Great news, thank you! I look forward to testing it in 5.0.0 when it comes out for the 10 III and V!