From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Description of problem: Evolution does not notice changes made to a displayed folder until another folder is selected for viewing, and then the original is selected again. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Open Evolution 2. Open Outlook on another machine 3. Using Outlook, delete a message or mark an unread message as read Actual Results: Even after checking for new messages, Evolution shows the deleted message in the index or continues to show the read messages as unread. Display can usually be refreshed by switching back and forth from another folder (Inbox->Deleted Items->Inbox). Expected Results: Attributes and messages should be updated while checking for new messages. Additional info: I have not tried this between two copies of Evolution running against Exchange or using Evolution + Outlook Web Access, only a copy of Evolution with a copy of Outlook.
Thanks for filing this report. I've looked through the code; Evolution appears to correctly handle notifications about new/removed messages and status changes in the messages it receives from the evolution-exchange-storage backend, but does no global monitoring for change information of this kind. Your suggestion would involve a full rescan on Send/Receive, which could work, but I'm uneasy about the performance implications. I'm marking this bug as ASSIGNED since it's correctly assigned to me. However, it currently has a very low position in my priority queue, and is not likely to get fixed in forthcoming updates (although I plan to ensure that the problem is addressed in RHEL 5). If this issue is important to you, please contact Red Hat Support to get it reprioritized. Thanks.
This is by far the most courteous and professional response I've received from any Red Hat employee. It's not a high priority for me, I just wanted to make the issue known to Red Hat. I like bug reports because I imagine that they give the developer the opportunity to prioritize, rather than choosing to filter low-priority tasks. I appreciate your response. I'm tempted to forward it to the support guys as an example of everything a reply to a customer should include.
Add to FC6Destop tracker
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.