PublicFolders using Maildir and INDEXPVT in Dovecot v2.2

[Panayiotis Fafakos]

Dear Timo,

thank you very much for your answer and for the wonderful DOVECOT project.

Can you please tell us where is the code that moves the index record for 
the specified email,
so that we can perhaps provide a manually updated list of users, that we 
want dovecot to update also.

This would be a custom code modification which we would need to 
keep-up-to-date,
and we could also publish it if anyone would be interested.
We are supporting companies up to 10 users, so this minor change would 
not be a problem to maintain.
i.e. we could have a list of users in the main departmental public folder
who's index would also be updated once an email in the underlining 
folder structure changes folder.

We are also a software company and would be very interested in investing 
to get to know more for the dovecot project.

Thank you in advance for your support,

Panos.

On 8/5/2015 18:42, Timo Sirainen wrote:
> On 08 May 2015, at 18:24, Panayiotis Fafakos <pfaf at wisdomsoftware.net> wrote:
>> Do we have a way to keep the user \Seen flags in public folders
>> when an email is moved in another folder?
>>
>> Sample test to reproduce:
>> Step a - UserA and UserB have both read the email in PublicFolderA.
>> Step b - UserA moves the email to PublicFolderB. UserA still sees the email as read (with the \Seen flag), this is expected behaviour and we are ok with this.
>> Step c - UserB sees the email in PublicFolderB as an unread message!? He is puzzled since he has already read this message and asks why this is happening. Can we correct this behaviour?
> No, there's no way to fix this without major changes to how Dovecot works.
>
> Per-user seen flags are stored in private per-user index files. When user A moves mail to another folder the shared index and user A's index are updated to copy the flags. User A doesn't know what other users might have the folder accessible (and especially both source and destination folder). Even if it did know, now moving a mail might involve updating a lot of indexes every time a mail is moved, which is way too slow.
>
> One possible future solution would be to move more towards GMail-like labels instead of folders. We have beginnings of such code. I'm not sure yet how that could be made to work with shared folders.
>
>