GNOME Bugzilla – Bug 274316
[IMAP] Follow-up flag lost on message move/copy
Last modified: 2014-02-19 14:09:05 UTC
Distribution: Novell Linux Desktop 9 (i586) Package: Evolution Priority: Normal Version: GNOME2.6. 2.0.4 Gnome-Distributor: Novell, Inc. Synopsis: VFolder's for 'Follow Up' Flag Fails To Show All Flagged Messages Bugzilla-Product: Evolution Bugzilla-Component: Mailer Bugzilla-Version: 2.0.4 Description: Description of Problem: Setting up a vfolder with a criteria based upon the follow-up flag does not show all messages that are flagged in that way. Only messages that are flagged and have the actual follow-up value of 'Follow-up' show in the folder. Steps to reproduce the problem: 1. Choose a message(s) and choose the 'flag to follow up' option. 2. In the dialog choose an action from the 'Flag' drop-down, ensure that some are flagged with 'Follow-up' explicitly and others are flagged with 'Review' (or any other value). 3. Create a vfolder and elect to have the criteria based on 'Follow-up' and 'Is Flagged', and then set the source to all local and active remote. 4. Click on the new vfolder. Actual Results: Only the messages that were explicitly flagged with the 'Follow-up' action will show up in the vfolder. The other messages will not show up. Expected Results: All messages that were flagged as follow up, regardless of the actual follow-up action should show up in the vfolder. How often does this happen? All the time. Additional Information: Another solution might be to provide a broad criteria for the follow-up flag, but then allow further criteria based on the actual action. Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
This is a problem with applying a follow-up flag and then moving the message to a different folder. My usual routine was to go through my inbox, assign follow-up flags and then move the message into a different folder, then move onto the next message. Also, my mailbox is on a groupwise post office, if that is relevant. But anyway, the act of moving the message from one folder to another causes the flag to be lost. My original claim about vfolders is incorrect, they pickup the flag regardless of the action I specified. The new bug is that moving the message causes the follow-up information to get lost. Please let me know if I should submit a different bug or if this one can be changed.
lyndon: please change the summary to reflect it :-)
I tested if I assigned a label or a follow-up flag, then moved the message to a different folder if those attributes would remain, and unfortunately they do not.
This is a generic issue with the Evolution mailer. It can be probably done for the IMAP/POP interfaces, but for Groupwise i dont think this is possible. Since the SOAP interface does not support user-defined flags (like follow-up). For Groupwise provider this would be an enhancement request. For IMAP/POP - a bug. So changing the summary to reflect this
evolution 2.7.3: i applied a follow-up flag and then moved the message to a different folder, and the flag was retained. this refers to local folders only.
With evolution 2.10 and evo-data-server 1.12, followup flag is lost when copying between IMAP servers. This is using the standard IMAP, not the IMAP4, server type in the configuration.
I looked into this a bit and found that IMAP is using "UID COPY" command when copying message, and because follow-up flag is about user tags, and (my) server doesn't copy these user tags too, then the flag is lost. One possible way how to do this is do that in same way as with local folders, because it works (as Andre mentioned above). The disadvantage of such solution is lose of the server side work, but it's probably better, because we keep functionality. I do now know about GroupWise, but I guess it's same as for IMAP. Any thoughts?
btw, labels are now stored in user flags and they survive (as long as sever supports user flags).
What version of evo switched to storing the user flags on the server? And if you had an older version, are they automatically migrated to the new scheme (hmm, the migration is a pretty big operation if you have big mailboxes).
Labels are there since 2.21.91 (see bug #211353), they use user flags which are now stored on a server too. I got your point, the user tags are not stored on a server, you've right. I misused user flags and user tags, I'm sorry. So seems just parse the returned COPYUID and update target message with its user tags should fix this.
I don't follow: "user flags which are now stored on a server" seems to contradict "the user tags are not stored on a server." Do you mean the flags are stored on the server, but there is no process that migrates them to the server from the old scheme? I didn't really have a point, just a question. I think I'm also confused by the relation between "labels," "user flags" and "user tags." I thought labels were a feature seen by users, kept internally as user flags. And the change was that user tags used to be kept on the client and, in newer versions, are kept on the server when the server has that capability. At any rate, I also don't follow the remark about misusing user tags and user flags.
OK, I will try to explain: Follow-Up "flag" is stored in user_tag of message info on local machine. Labels were stored as numbered flags on the server and locally, but only until fix in bug I mentioned above, since which you can have user defined flags, which are also stored on the server, but as user_flags with the message (if server supports it). The point is the user_flag of the message is something completely different from user_tag of the message, and I forgot it in my first comment (thus I misused them). With respect to migration, there is no such thing and I don't plan any at the moment. It will be easier to update user tags of the destination message.
Thank you for the explanation. If I understand the remark about migration, this means that when someone upgrades to 2.21.91 what the user sees as "flags" (e.g., follow up) will switch from being stored locally to being stored on the server when the server supports it. This means that all their flags will be lost. I think that is a significant problem. I assume that if the server does not support remote storage of user_tag things will simply continue as before. As for the original problem in this bug, preserving flags on copy, there seem to be a lot of cases: 2 kinds of message statuses: labels (kept in user_flags) and other info such as followup ("followup flag" from user perspective) kept in user_tag. I think "replied to" and similar info also is on user_tag. 3 kinds of mail boxes: local, server supporting user defined flags, server not supporting user-defined flags. 3 kinds of "copy": copying within a mail store (i.e., moving to a different folder); copying between mail stores (one server to another, local to server, ...) and "copying" between versions of the program (e.g., upgrading to 2.21.91). I would expect all message status information to be preserved in all scenarios. It sounds as if the latest enhancements address some of these issues--in particular copying between folders on a server that supports user flags--but that many scenarios remain in which message status information may disappear.
(In reply to comment #13) > Thank you for the explanation. If I understand the remark about migration, > this means that when someone upgrades to 2.21.91 what the user sees as "flags" > (e.g., follow up) will switch from being stored locally to being stored on the > server when the server supports it. This means that all their flags will be > lost. I think that is a significant problem. No no no, the only change was with Labels, and they are stored locally AND on the server too, if supported (which has the advantage of moving to other place and see your Labels). If your server doesn't support it, then you do not notice any change. There is no change in code with respect to follow-up (yet). It seems to me that user_tags cannot be stored on a server, it seems to me as a local thing. The cases you mentioned seems right for me. You've right that I'm talking in developer terminology, but user's terminology is different (they have always "follow-up flag" and they do not care/want to know where it is stored). All the changes are always done with some backward compatibility, especially any enhancement (usually) only extends functionality, doesn't want to break anything, and tries to do it with as little work for a user as possible. I think this discussion is over. :)
Created attachment 106997 [details] [review] propose eds patch (for IMAP without XGWMOVE only) for evolution-data-server; This will copy user tags when copying between folders on IMAP. This will not work for IMAP servers supporting "UID XGWMOVE" command. Whoever has GW and can check with it, then he/she can. I do not have GW server to test on.
So we checked with lakhil and XGWMOVE returns status: A00012 OK UID XGWMOVE completed and one element of untagged: * 2 XGWMOVE thus no UID(s) as with UID COPY. Maybe it keeps UID(s), but it sounds a bit strange, because they can overlap, I guess. Does anyone have any idea?
Milan, I dont have much idea on XGWMOVE. But the other part looks fine to me. I haven't tested it, just test and commit to stable/trunk.
Committed to trunk. Committed revision 8630. Committed to gnome-2-22. Committed revision 8631. I will not close this, because I will attach additional patch for XGWMODE acting in a way: if have this feature and moving mails doesn't have user tags, then use it, or use the old COPY, to keep flags. Not so nice, but should work.
Created attachment 109290 [details] [review] proposed eds patch (XGWMOVE part) for evolution-data-server; I really do not know why I didn't do that initially...
lakhil, can you apply the patch and test against GW server?
Patch attached in comment#19 neither worked against IMAP nor Groupwise server :( Follow-up flag gets lost after moving/copying mail to other folder. Let me know if i have done anything wrong.
Created attachment 109411 [details] [review] proposed eds patch ][ for evolution-data-server; Updated patch for XGWMOVE after testing with Akhil. The result is very bad. His server doesn't work as that mine. Even we call camel_folder_refresh_info on the destination folder after the copy command, then it doesn't realize our last copy on the folder, so our summary doesn't contain new message, so copy flag silently fails. We found that "NOOP" helps here, so adding it. The other thing is it seems that even the any_has_user_tag returns correctly we have a user tag, then it doesn't work for some reason which I doesn't understand at all. Maybe our test messages broke there something. When you've time, Akhil, please try one more time with this updated patch. Thanks in advance.
Akhil, I want you to test and reply today :)
Patch works fine for IMAP and Exchange back end but still no success with group wise back end. Flags get lost after moving message to other folder in group wise.
patch ][ committed to trunk. Committed revision 8719. Still keeping opened because of the above comment (doesn't work with GW)
This bug is still present in Evolution 2.28.1. At least I does not work for me with IMAP. Moving a message to a different folders results in a copy without the follow-up flag in the folder and a copy in the trash with the follow-up flag. For further details see: https://bugs.launchpad.net/evolution/+bug/490793
Potential duplicates: https://bugzilla.gnome.org/show_bug.cgi?id=597589 https://bugzilla.gnome.org/show_bug.cgi?id=580072 https://bugzilla.gnome.org/show_bug.cgi?id=274316
Still valid for 3.8.5 and Gmail.
Created commit 469359e in eds master (3.11.91+) [1] [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=469359e