Bug 78500 - Sharing IMAP accounts in KMail (not "shared folders")
Summary: Sharing IMAP accounts in KMail (not "shared folders")
Status: RESOLVED DUPLICATE of bug 67504
Alias: None
Product: kmail
Classification: Applications
Component: IMAP (show other bugs)
Version: 1.6.1
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-26 16:33 UTC by Gavin Hamill
Modified: 2007-09-14 12:17 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gavin Hamill 2004-03-26 16:33:13 UTC
Version:           1.6.1 (using KDE KDE 3.2.1)
Installed from:    Debian testing/unstable Packages
Compiler:          Whatever Debian uses... 
OS:          Linux

(originally posted to kdepim-users)

Hullo :)

I'm using KDE 3.2.1 on a 30-workstation call centre, to which all agents have access to the 'service mailbox'. This contains enquiries from customers held in an IMAP mailbox (Courier-IMAP on Debian woody) to which the same username/password is used by all agents.

All agents have the "automatically compact folders (expunges deleted messages)" option set in their IMAP account.

Agent 1 replies to a customer, and then deletes the original message. The message vanishes from their list. They move onto the next email.

Agent 2 refreshes the mailbox and sees the same e-mail as non-deleted, so also replies. Result, customer gets two seperate emails - undesirable.

Yes, this problem could be kludged by getting them to move a message to a 'work in progress' folder first, but that is clumsy, and they will forget.

When the message is deleted, the filename on the IMAP server changes from

1080301798.42609_1.emo.nation-net.com,S=2513:2,S

to

1080301798.42609_1.emo.nation-net.com,S=2513:2,ST

By speaking IMAP to the server directly, it is clear that the flags ARE being updated by Agent 1's KMail installation as soon as they delete the message.

1 login username password
2 select INBOX.gdh_test
3 fetch 1:4 (flags body[header.fields (subject)])

and the response of the deleted message changes from

* 3 FETCH (FLAGS (\Seen) BODY[HEADER.FIELDS ("subject")] {61}

to 

* 3 FETCH (FLAGS (\Seen \Deleted) BODY[HEADER.FIELDS ("subject")] {61}

but even if Agent 2  refreshes their KMail on that account, they still see the message as 'non-deleted'.

Of course, when Agent 1 selects File -> Empty Trash, or browses to another folder, the message is fully deleted from the IMAP server.

Ideally the flags sent back by the IMAP server should be taken more note of, but as an interim measure, can I have a more forceful "auto-expunge on delete" rather that just expunging on Empty Trash or changing folders?

Cheers,
Gavin.
Comment 1 Carsten Burghardt 2004-07-08 23:10:18 UTC
The only real solution for this is the IMAP idle command as this gives the client a chance to react on server changes. To "force" other updates of the folder would have a bad impact on performance. I therefore mark your report as duplicate.

*** This bug has been marked as a duplicate of 67504 ***