Fix deletion of messages quickly deleted after sending (#3685) #5382
Conversation
|
Another problem is that a quickly deleted message still remains on the server. Should be fixed too. |
iequidoo
force-pushed
the
iequidoo/keep-tombstones
branch
from
8f5ba8c
to
23f7318
Compare
|
|
||
|
|
||
| def test_deleted_msgs_dont_reappear(acfactory): | ||
| (ac1,) = acfactory.get_online_accounts(1) |
There was a problem hiding this comment.
bcc_self doesn't need to be set, we anyway send the message to self. But it's an interesting question: why we do so? Maybe if we send a message to self and bcc_self is disabled, just store it locally?
There was a problem hiding this comment.
For the test at least I'd set bcc_self explicitly.
There was a problem hiding this comment.
I agree. Anyway, why do we smtp-send self-messages at all if bcc_self is unset? This looks like an exception from what we have for chats in general (1:1, group, etc.)
iequidoo
changed the title
|
|
||
|
|
||
| def test_deleted_msgs_dont_reappear(acfactory): | ||
| (ac1,) = acfactory.get_online_accounts(1) |
There was a problem hiding this comment.
For the test at least I'd set bcc_self explicitly.
iequidoo
force-pushed
the
iequidoo/keep-tombstones
branch
from
9a90848
to
5edff1c
Compare
| @@ -910,6 +910,13 @@ CREATE INDEX msgs_status_updates_index2 ON msgs_status_updates (uid); | |||
| ) | |||
| .await?; | |||
| } | |||
| if dbversion < 111 { | |||
| sql.execute_migration( | |||
| "ALTER TABLE msgs ADD COLUMN deleted INTEGER NOT NULL DEFAULT 0", | |||
There was a problem hiding this comment.
If message is a partial download, it gets trashed with deleted=0 and then MIN(deleted) over such message is always false even if user explicitly deletes message? This deleted column is only used in a fix for outgoing deleted messages so far, but it seems to be wrong for incoming messages and outgoing large messages if they are received from other device. The fix for this particular case is working, but it seems to be very difficult to describe what is stored in the deleted column. Could you add a comment for the column describing what exactly does it store?
There was a problem hiding this comment.
Fixed this, see receive_imf::add_parts(). But there's still a problem: if the server modifies Message-ID, the fix doesn't work. But it's a corner case and maybe it's not worth fixing. Added a comment here also.
iequidoo
force-pushed
the
iequidoo/keep-tombstones
branch
from
5edff1c
to
3a1e2b6
Compare
iequidoo
force-pushed
the
iequidoo/keep-tombstones
branch
2 times, most recently
from
20ed740
to
8257c10
Compare
iequidoo
force-pushed
the
iequidoo/keep-tombstones
branch
2 times, most recently
from
c2ace28
to
172d27e
Compare
|
It's funny that a new |
This is a way to prevent redownloading locally deleted messages. Otherwise if a message is deleted quickly after sending and `bcc_self` is configured, the BCC copy is downloaded and appears as a new message as it happens for messages sent from another device.
…on IMAP later Before, if the user deleted a message too quickly after sending, it was deleted only locally. The fix is to remember for tombstones that the corresponding message should be deleted on the server too.
iequidoo
force-pushed
the
iequidoo/keep-tombstones
branch
from
172d27e
to
53add2d
Compare
See commit messages.
Fix #3685
Fix #5379