[korganizer] [Bug 317656] Korganizer alert reminders are not reliable (they're lost after logout)

[Filipus Klutiero]

https://bugs.kde.org/show_bug.cgi?id=317656

Filipus Klutiero <chealer at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugs.kde.org/show_b
                   |                            |ug.cgi?id=282535
             Status|REOPENED                    |CONFIRMED

--- Comment #10 from Filipus Klutiero <chealer at gmail.com> ---
I must confirm that this affects both Debian 9 and Kubuntu 19.04 (KOrganizer
5.10.3). However, when KOrganizer is shut down (or restarted), either this
issue happens, or it does not happen. When it happens, all suspended reminders
fail to display. When it does not happen, all suspended reminders do display.
And in some cases, all fail to display, but display when KOrganizer is
restarted again.

Unfortunately, I have no idea when each case occurs. I tried with 1 or 2
suspended reminders, and it happened in both cases. I tried with suspended
reminder postponed until a time before or after korgac's restart, and it
happened in both cases.
However, ticket #282535 documents that this was completely broken after the
switch to Akonadi: https://bugs.kde.org/show_bug.cgi?id=282535
But the contributor who developed the fix was not familiar with Akonadi, and
wasn't sure the fix would always work. korgac's communication with Akonadi
appears to be quite a hack:

    // Check if Akonadi is already configured
    const QString akonadiConfigFile =
Akonadi::ServerManager::serverConfigFilePath(
        Akonadi::ServerManager::ReadWrite);
    if (QFileInfo::exists(akonadiConfigFile)) {
        // Akonadi is configured, create ETM and friends, which will start
Akonadi
        // if its not running yet
        setupAkonadi();
    } else {
        // Akonadi has not been set up yet, wait for someone else to start it,
        // so that we don't unnecessarily slow session start up
        connect(Akonadi::ServerManager::self(),
&Akonadi::ServerManager::stateChanged,
                this, [this](Akonadi::ServerManager::State state) {
            if (state == Akonadi::ServerManager::Running) {
                setupAkonadi();
            }
        });
    }

There's also a doubtful if in KOAlarmClient::checkAlarms():
    // We do not want to miss any reminders, so don't perform check unless
    // the collections are available and populated.
    if (!collectionsAvailable()) {
        qCDebug(KOALARMCLIENT_LOG) << "Collections are not available; aborting
check.";
        return;
    }

Unfortunately, I can't find what goes in KOALARMCLIENT_LOG on my session, so I
can't use the logs to determine if that's the problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.