From 53572fce5c899b26084409d2078e23983b3e815f Mon Sep 17 00:00:00 2001
From: iequidoo <dgreshilov@gmail.com>
Date: Tue, 14 Jan 2025 02:44:05 -0300
Subject: [PATCH] fix: migration: Set bcc_self=1 if it's unset and
 delete_server_after!=1 (#6432)

Users report that in a setup with Android (1.50.4 from F-Droid) and Desktop (1.48.0 x86_64 .deb
release) and chatmail account `bcc_self` was reverted to 0 on Android, resulting in messages sent
from Android not appearing on Desktop. This might happen because of the bug in migration #127, it
doesn't handle `delete_server_after` > 1. Existing chatmail configurations having
`delete_server_after` != 1 ("delete at once") should get `bcc_self` enabled, they may be multidevice
configurations:
- Before migration #127, `delete_server_after` was set to 0 upon a backup export, but
  then `bcc_self` is enabled instead (whose default is changed to 0 for chatmail).
- The user might set `delete_server_after` to a value other than 0 or 1 when that was
  possible in UIs.
So let's add another migration fixing this. But still don't check `is_chatmail` for simplicity.
---
 src/sql/migrations.rs | 25 ++++++++++++++++++++-----
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/src/sql/migrations.rs b/src/sql/migrations.rs
index 27172ef337..f0849a1bcb 100644
--- a/src/sql/migrations.rs
+++ b/src/sql/migrations.rs
@@ -1123,11 +1123,7 @@ CREATE INDEX msgs_status_updates_index2 ON msgs_status_updates (uid);
 
     inc_and_check(&mut migration_version, 127)?;
     if dbversion < migration_version {
-        // Existing chatmail configurations having `delete_server_after` disabled should get
-        // `bcc_self` enabled, they may be multidevice configurations because before,
-        // `delete_server_after` was set to 0 upon a backup export for them, but together with this
-        // migration `bcc_self` is enabled instead (whose default is changed to 0 for chatmail). We
-        // don't check `is_chatmail` for simplicity.
+        // This is buggy: `delete_server_after` > 1 isn't handled. Migration #129 fixes this.
         sql.execute_migration(
             "INSERT OR IGNORE INTO config (keyname, value)
              SELECT 'bcc_self', '1'
@@ -1156,6 +1152,25 @@ CREATE INDEX msgs_status_updates_index2 ON msgs_status_updates (uid);
         .await?;
     }
 
+    inc_and_check(&mut migration_version, 129)?;
+    if dbversion < migration_version {
+        // Existing chatmail configurations having `delete_server_after` != "delete at once" should
+        // get `bcc_self` enabled, they may be multidevice configurations:
+        // - Before migration #127, `delete_server_after` was set to 0 upon a backup export, but
+        //   then `bcc_self` is enabled instead (whose default is changed to 0 for chatmail).
+        // - The user might set `delete_server_after` to a value other than 0 or 1 when that was
+        //   possible in UIs.
+        // We don't check `is_chatmail` for simplicity.
+        sql.execute_migration(
+            "INSERT OR IGNORE INTO config (keyname, value)
+             SELECT 'bcc_self', '1'
+             FROM config WHERE keyname='delete_server_after' AND value!='1'
+            ",
+            migration_version,
+        )
+        .await?;
+    }
+
     let new_version = sql
         .get_raw_config_int(VERSION_CFG)
         .await?