You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We store message info locally since #2064. As of #2796 we store a non-standard important flag in the cache table. The problem is that we lose the info in many cases. Like when a message is moved from the INBOX to the archive or the sent mailbox, the message technically vanishes in one mailbox and is found as new in the other. There is currently no mechanism to detect this move. Even if we did it manually, like move, sync and update the cache manually, this wouldn't solve the problem of other IMAP clients (e.g. mobile) doing the move where we have no control over the process.
The best solution I can come up with right now would be to have an extension table, that is, another table just for the non-standard flags. As identifier we can then use the MessageId as that is supposed to be unique. We can then join the tables to get our logical representation of what properties a message has. And if a message is moved and shows up in a new Mailbox, we can still link the two together.
This will also help with #2048, which requires a non-standard flag to be stored in the database.
Summary
Create a table that extends mail_messages and link them via the message ID.
The text was updated successfully, but these errors were encountered:
Feature Request
We store message info locally since #2064. As of #2796 we store a non-standard important flag in the cache table. The problem is that we lose the info in many cases. Like when a message is moved from the INBOX to the archive or the sent mailbox, the message technically vanishes in one mailbox and is found as new in the other. There is currently no mechanism to detect this move. Even if we did it manually, like move, sync and update the cache manually, this wouldn't solve the problem of other IMAP clients (e.g. mobile) doing the move where we have no control over the process.
The best solution I can come up with right now would be to have an extension table, that is, another table just for the non-standard flags. As identifier we can then use the
MessageId
as that is supposed to be unique. We can then join the tables to get our logical representation of what properties a message has. And if a message is moved and shows up in a new Mailbox, we can still link the two together.This will also help with #2048, which requires a non-standard flag to be stored in the database.
Summary
Create a table that extends
mail_messages
and link them via the message ID.The text was updated successfully, but these errors were encountered: