Bugzilla

Note:
- This bug requires that "Leave messages on server until I delete them" is set.
- We delete the original local message and recreate a new one without attachments.
- Deleting the original message then triggers "mark for deletion on server" per the above pref (but should not in this case, so we probably need to distinguish plain vanilla message deletion from "delete for recreation w/o attachments" here).
- As long as things work like this, fixing this bug will then mean that deleting the new, trimmed local message will *not* effect deletion of the full original message on server, somewhat contrary to expectation. I guess that's acceptable because first deleting only attachments, then later deleting the rest of the message might be an unlikely scenario (should be easier to just archive the entire message in your file system then, or to move it to local folders, assuming that triggers server deletion too). It's definitely better to err in favor of data preservation.

Note:
- This bug requires that "Leave messages on server until I delete them" is set (which is default setting).
- We delete the original local message and recreate a new one without attachments.
- Deleting the original message then triggers "mark for deletion on server" per the above pref (but should not in this case, so we probably need to distinguish plain vanilla message deletion from "delete for recreation w/o attachments" here).
- As long as things work like this, fixing this bug will then mean that deleting the new, trimmed local message will *not* effect deletion of the full original message on server, somewhat contrary to expectation. I guess that's acceptable because first deleting only attachments, then later deleting the rest of the message might be an unlikely scenario (should be easier to just archive the entire message in your file system then, or to move it to local folders, assuming that triggers server deletion too). It's definitely better to err in favor of data preservation.

Note:
- This bug requires that "Leave messages on server until I delete them" is set (which is default setting).
- We delete the original local message and recreate a new one without attachments.
- Deleting the original message then triggers "mark for deletion on server" per the above pref (but should not in this case, so we probably need to distinguish plain vanilla message deletion from "delete for recreation w/o attachments" here).
- As long as things work like this, fixing this bug will then mean that manually deleting the new, trimmed local message will *not* effect deletion of the full original message on server any more, somewhat contrary to expectation. I guess that's acceptable because first deleting only attachments, then later deleting the rest of the message might be an unlikely scenario (should be easier to just archive the entire message in your file system then, or to move it to local folders, assuming that triggers server deletion too). It's definitely better to err in favor of data preservation.