<table><tr><td style="">dkurz added a comment.</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D2423" rel="noreferrer">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
          color: #6B748C;
          font-style: italic;
          margin: 4px 0 12px 0;
          padding: 8px 12px;
          background-color: #F8F9FC;">
<div style="font-style: normal;
          padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D2423#45545" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;" rel="noreferrer">D2423#45545</a>, <a href="https://phabricator.kde.org/p/knauss/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;" rel="noreferrer">@knauss</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><p>We also did this on kolab branches already:</p>

<p><a href="https://git.kolab.org/rKPbecae4738c14ef" class="remarkup-link" target="_blank" rel="noreferrer">https://git.kolab.org/rKPbecae4738c14ef</a></p></div>
</blockquote>

<p>The categories to be checked can always be obtained from mLoadedInstance, so there's no need to pass them along with the job. I can't figure out from the "specifications" of Akonadi whether it is a good idea to use (if at all) the plain category name as the tag's global ID. According to README.md in kde:akonadi, the global ID has some kind of meaning for some items or tags, but I can't figure out what it is. There are already tags around that have random GIDs. Having some tags with GID == name and some with GID != name does not seem an optimal solution to me. Also, having the name of a category twice per tag in the Akonadi DB might leed to problems later.</p>

<p>The above patch applies the TagFetch changes also to the TagSelectionDialog. This is only reasonable if we assume that one clicks on the "..." button before the TagWidget has completed the creation of the missing tags. But then the missing tags would be created by both the TagWidget and the TagSelectionDialog.</p>

<p>Maybe we should block the TagSelectionDialog (by disabling the "..." button?) until all necessary tags exist? At any rate, I think this should be addressed in another patch.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p><a href="https://git.kolab.org/rKPea164d5531331" class="remarkup-link" target="_blank" rel="noreferrer">https://git.kolab.org/rKPea164d5531331</a></p></blockquote>

<p>This assumes that GID == category name in some cases, see above.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p><a href="https://git.kolab.org/rKP5928ec8451f24" class="remarkup-link" target="_blank" rel="noreferrer">https://git.kolab.org/rKP5928ec8451f24</a></p></blockquote>

<p>I think this is more related to the category color problem than to this patch, doesn't it? I will try to address this later, but not as part of this patch.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p><a href="https://git.kolab.org/rKP136b203127db2" class="remarkup-link" target="_blank" rel="noreferrer">https://git.kolab.org/rKP136b203127db2</a></p></blockquote>

<p>I think I also fixed this issue, although by accident because I didn't know that onTagsReceived never happens if there are no tags to fetch.</p>

<p>Maybe the mCategoriesToCheck approach can be made to be more robust than my approach. My code does not recover from failed TagCreateJobs at all. I'll try to fix that.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>rINCIDENCEEDITOR PIM: Incidence Editor</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D2423" rel="noreferrer">https://phabricator.kde.org/D2423</a></div></div><br /><div><strong>EMAIL PREFERENCES</strong><div><a href="https://phabricator.kde.org/settings/panel/emailpreferences/" rel="noreferrer">https://phabricator.kde.org/settings/panel/emailpreferences/</a></div></div><br /><div><strong>To: </strong>dkurz, KDE PIM<br /><strong>Cc: </strong>knauss, kde-pim, spencerb, dvasin, winterz, smartins, vkrause, mlaurent, dvratil<br /></div>