Thanks to the daily Kubuntu KDE Stable CI packages, I'm currently testing a 15.08.1-pre build which already contains the fix for Bug #352015. Unfortunately, categories still are basically usuable in this version: * For all of my existing events created with kOrganizer 4.x, no categories are selected if I edit this event's category list. * The same also holds (most of the time?) for newly created events - add an event called "Test", open the category list, add a new category called "Test", select it and save the event. The event's tooltip in the calendar view will show the category, but opening the editor again will show no category selected - but two (!) unselected categories called "Test". (See next issue, below.) * Categories get duplicated endlessly just by editing events (see attached screenshot). If categories assigned to the event cannot be matched in the category editor - which is nearly always the case - the category will be displayed twice, both times unselected. Clicking "Ok" and saving the event will cause the category to be duplicated, so that there are two identically named categories in the category list. * In the rare case that a category in an event's category editor is displayed as selected, unselecting it and trying to save the event will cause the following error dialog to appear: "Error while trying to modify calendar item. Error was: Akonadi::Exception: No objects specified" It is impossible to save the event in this case. * Categories cannot be deleted reliably in the category editor. First of all, the "X" icon only appears if the category list is focused. So if you don't know you have to click into it before you're able to delete categories, you're left clueless. Second, it seems to be random if a category can actually be deleted or not - sometimes after clicking the "X", the "X" only disappears but the category is not deleted, and you get not feedback at all why this happened. In other cases, deletion works and you get a dialog asking for confirmation. In this case it also seems to be possible to delete categories still in use, maybe because kOrganizer does not notice that the category is in use due to the matching problem described above? * The category editor lists all categories in random order, making it difficult to find specific categories if you have quite a few of them. Reproducible: Always
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. ***