[Kde-pim] [REGRESSION] Pop3 message status change is broken on Enterprise branch

[Volker Krause]

On Friday 01 February 2008 12:25:34 Volker Krause wrote:
> On Sunday 27 January 2008 13:01:29 Ingo Klöcker wrote:
> > On Sunday 27 January 2008, Ingo Klöcker wrote:
> > > On Sunday 27 January 2008, Ismail Dönmez wrote:
> > > > Hi Volker,
> > > >
> > > > Thursday 20 December 2007 12:51:49 tarihinde Volker Krause şunları
> > >
> > > yazmıştı:
> > > > > Since apparently only the triggering of the status change
> > > > > operation is broken and not the actual status changing itself,
> > > > > the only thing I could think of are the XMLGUI .rc files,
> > > > > although that would usually hide the action altogether. Also,
> > > > > there is nothing special for local folders in that area. Do you
> > > > > still have the old files for comparison?
> > > >
> > > > Sorry for the late reply, attached is the problematic kmailrc file.
> > > > Issue is still reproducable with Enterprise branch according to
> > > > users.
> > >
> > > FWIW, with the very latest enterprise version I have noticed a
> > > similar problem. It occurs intermittently with messages in IMAP
> > > folders. Most of the time it's just the last message in a thread that
> > > cannot be marked as unread. When I mark the whole thread as unread
> > > then the status of the problematic message is also marked as unread.
> > > I'll keep an eye on it to make out a pattern.
>
> I've seen this as well by now, on IMAP, mostly when marking messages as
> unread that just have been downloaded and marked as read. But I've been
> unable to reproduce it reliably so far.
>
> > I have made a quick test trying to mark all messages in a thread as
> > important. You can see the result of the test in the attached
> > screenshot.
> >
> > The only pattern I can make out (also in a few other threads where I
> > have tested it) is that if a message is affected by the problem then
> > all of its children are affected as well. The level of a message in the
> > thread does not seem to be the looked for pattern as one of the
> > messages on level 2 could be marked as important. OTOH, I have noticed
> > that the problem is more likely to occur with message on level 2 and
> > beyond.
> >
> > > Now that I think about it I have a theory:
> > > Maybe for some reason KMail sometimes changes the status in the
> > > KMMessage object, but not in the corresponding KMMsgInfo object (or
> > > vice-versa?). So this bug might have been introduced by my change
> > > which prevents crashes due to the former KMMsgInfo object by
> > > KMMessage object replacement. Now the KMMsgInfo object is no longer
> > > destroyed, but kept around and re-used when the KMMessage object is
> > > destroyed. I have warned about possible inconsistencies due to
> > > changes in the KMMessage object not being applied to the KMMsgInfo
> > > object. Anyway, it's just a guess. Maybe there's still another
> > > problem.
> >
> > The above observation makes my theory very unlikely.
>
> My guess is that's caused by some of our changes to
> KMFolderImap::flagsToStatus(), but I haven't investigated that yet.

Should be fixed in revision 770912 in 3.5 branch (ports to enterprise and 
trunk follow shortly).

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20080204/db0e2725/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/