Bug 352645

Created attachment 94529 [details]
kOrganizer category editor with unwanted category duplicates.

Bug exists in Kubuntu 15.10 with korganizer 4:15.08.2-0ubuntu1, KDE Frameworks 5.15.0, Qt 5.4.2.

An ugly workaround to remove the duplicates : 

mysql -D akonadi -S $HOME/.local/share/akonadi/socket-$(hostname)/mysql.socket -e "delete from tagtable where typeId = 2"

For unknown reasons, every time a tagged event (i.e, with category) is edited, an entry is added in tagtable in this form :

 id | gid                                  | parentId | typeId
 43 | c8b4e689-be91-4127-85d6-db12602279b3 |     NULL |      2

and another linked entry is added in tagattributetable :

id | tagId | type | value
41 |    43 | TAG  | ("TestCategory" "" "" "" "0" () () "-1")

Those duplicates in tagtable always have a value 2 in typeId column. Deleting those entries cascade in related tables.

Let's hope the devs fix this longstanding bug.

This workaround restores normal expected use of categories and colours.
First, clean tagtable as per my above post.
Next, log in MariaDB :

mysql -D akonadi -S $HOME/.local/share/akonadi/socket-$(hostname)/mysql.socket

Create this trigger :

DELIMITER $$
CREATE TRIGGER tagtable_before_insert BEFORE INSERT ON tagtable
FOR EACH ROW
BEGIN
    IF NEW.typeId > 1 THEN
        SET NEW.gid = NULL;
    END IF;
END
$$ DELIMITER ;

It prevents annoying and disrupting inserts in tagtable whenever an event with a category is edited. I'm using New.typeId > 1 for a default KDEPIM installation and usecase. Look in tagtypetable where tagtable.typeId is explained.

If you need to delete the trigger, when the bug is hopefully addressed :

DROP TRIGGER tagtable_before_insert;

In case it helps.

I can confirm the abovementioned issues with categories on Arch Linux with korganizer 15.12.1.

These issues also appear in openSUSE Tumbleweed with Kontact/Korganizer 15.12.1.  This bug should probably be a tracker, depending on each of them.

I can also confirm this, assigning several ToDo items the same category apparently makes duplicates of said category as well.

Arch Linux, Version 15.12.1
Help->About KOrganizer->Version mentions "Version 5.1.1", KDE Frameworks 5.18.0, Qt 5.5.1

Further confirmation in openSUSE Tumbleweed with 15.12.2, Frameworks 5.19.1, Qt 5.5.1. 

nmset's workaround worked for me. Thanks for that!

*** This bug has been confirmed by popular vote. ***

The bug also occurs in Gentoo with KDE Apps 15.12.3, Frameworks 5.20.0, Qt 5.5.1.

When I try to connect to .local/share/akonadi/$(hostname)-socket/akonadiserver.socket using the mariadb-10.0.23 client, I just get a "system error 95: Operation not supported". Can such triggers be added via akonadiconsole?

I tried to connect to akonadiserver.socket because mysql.socket did not exist. I fixed my akonadiserverrc and it now uses a local mysqld instance. All tables were initialized during the last akonadi startup, so I suppose that I started from a fresh, clean DB. The bug still persists. The only existing categories after the initialization were birthday and anniversary.

I was now also able to apply nmset's workaround, and it works perfectly. I also noticed that no categories are created when I edit tasks or events that already have some categories set. I suppose the TRIGGER is responsible for that.

On the other hand, if I edit an event whose category was created after the DB initialization, but for which I have not set the category explicitly since the init, the edit form is not able to induce the correct category and the category field stays empty. So it seems that the categories of events can be distinct from the categories akonadi knows even if they have the same name.

If I just confirm the edit without modifying anything, the category is yet preserved. If I click on the three dots next to the category field, none of the categories is selected (not even the one with the same name as the event's category), and just confirming the category selection dialog results in the old event's category being removed.

Example: Event A has some category B. I reinitialize the akonadidb and A has still category B. When I then edit A, the category field of A is empty and the selection dialog only presents Birthday and Anniversary. Confirming this dialog directly removes B from A. It is now necessary to explicitly create B and select it for A.

Even though categories with the same name can be distinct, category colors are applied for all events that contain a category of a given name.

However, everything seems to work fine right now, and it hasn't for a long time. Thanks a lot, nmset!

Also confirming the bug for Korganizer 5.2.0 (KDE Applications 16.04) on OpenSUSE Leap 42.1, KDE Frameworks 5.21.0 and Qt 5.6.0.

The workaround from nmset did the trick for me and for now.

I'm seeing the multiplication of categories happening, on kubuntu 16.04, using version 5.1.3.

I've tried the workaround -- the first step does clear the duplicate entries, but the trigger seems to be accepted by the database but does not prevent categories being duplicated.

I've reset akonadi and started from the beginning without any change... any ideas? This is a serious bug!

(In reply to Edward Ando from comment #13)
> I'm seeing the multiplication of categories happening, on kubuntu 16.04,
> using version 5.1.3.
> 
> I've tried the workaround -- the first step does clear the duplicate
> entries, but the trigger seems to be accepted by the database but does not
> prevent categories being duplicated.
> 
> I've reset akonadi and started from the beginning without any change... any
> ideas? This is a serious bug!

The workaround works here as expected. I assume you have not set the trigger correctly. This can be verified by running "select * from tagtable where typeId = 2". If you see any new entries here after you have added the trigger, run KOrganizer and edited some tags , the trigger was not created as intended (i.e. it is definitely a database level problem with the workaround).

> The workaround works here as expected. I assume you have not set the trigger
> correctly. This can be verified by running "select * from tagtable where
> typeId = 2". If you see any new entries here after you have added the
> trigger, run KOrganizer and edited some tags , the trigger was not created
> as intended (i.e. it is definitely a database level problem with the
> workaround).

Thanks you're right -- I pasted the whole thing in, instead it has to go in line by line, I can use my calendar again!

Thx@nmset , the workaround did it for me :)

https://phabricator.kde.org/D2423
https://phabricator.kde.org/D2433

Git commit c32d82e481568e41d11e5426005b6c9634f2e9b8 by Daniel Vrátil, on behalf of Denis Kurz.
Committed on 26/08/2016 at 13:26.
Pushed by dvratil into branch 'Applications/16.08'.

Set initial categories for non-cached incidences correctly

The old implementation tried to match loaded and existing tags on the
akonadi server side. A new CreateTag job was sent to the server, with
the name of the new tag and the hint to first check if this tag already
exists. The server, however, does not know about any tag names, and
tried to match the new tag by global id, which is completely random in
the TagCreate job.

Now, the matching is done on the client side, where the concept of tag
names is located. We fetch all tags from the server and check if the
categories of the loaded category match the names of these tags. For
every category that was not found in the tag list returned from the
server, we send a TagCreate job.

As a side benefit, we now also keep track of tags that failed to be
created on the server. We now report all tags that were selected,
as well as all categories that were set when the editor was opened
and for which no corresponding tag could be created. This reduces
the risk of losing categories.

Test Plan:
Opening the incidenceeditor from korganizer's eventviews for variuos
cached and non-cached items did not produce a single tag duplicate.
Also, the TagWidget's content is set correctly after the incidenceeditor
is created. Without the patch, everything reported in Bug 352645
happened here, too.
Related: bug 357236
FIXED-IN: 16.08.1

Differential Revision: https://phabricator.kde.org/D2423

M  +63   -11   src/incidencecategories.cpp
M  +16   -9    src/incidencecategories.h

http://commits.kde.org/incidenceeditor/c32d82e481568e41d11e5426005b6c9634f2e9b8

*** Bug 361475 has been marked as a duplicate of this bug. ***

*** Bug 375493 has been marked as a duplicate of this bug. ***