Prevent tag name vs gid confusion
Summary:
The old code relied on the display name of the tags of the item provided
via load(const Akonadi::Item&) being set, but those aren't actually
fetched. This led IncidenceCategories to believe that an item's
categories are the gids of its tags. Saving the item without confirming
the category dialog (e.g. by only modifying the description) led to this
gid being written back to Akonadi. Opening the item again afterwards
then even leads to a corresponding Akonadi tag being created.
We reduce state in IncidenceEditor, stop matching Tags twice a
row (in onTagsFetched and matchExistingCategories), and rely more on
incidence->categories(), where no gid confusion exists.
BUG: 373257
FIXED-IN: 5.6.1
Test Plan:
I editted multiple events in KOrganizer, modifying categories or
description or title of the event, or all of them in one change.
For categories, I tried to set related subsets of my tags (a sub-
or superset of the previously selected tags), or completely unrelated
sets (deselecting all selected, and selecting previously other ones
instead). All changes were saved as expected, and no gid-named
categories were created in the process.
Reviewers: KDE PIM, dvratil
Reviewed By: KDE PIM, dvratil
Subscribers: dvratil
Tags: KDE PIM
Differential Revision: https://phabricator.kde.org/D7548