Don't delete draft mails before they're sent #351
Comments
romanofski
changed the title
romanofski
added a commit
that referenced
this issue
Jun 23, 2020
Initially composeAsNew was implemented with the idea to continue draft mails. The mails are stored in the file system and indexed in notmuch. Once the draft is picked up again, the mail is unindexed and removed from the file system until it's sent. However, if we use the same function on existing mails in order to use the mail as a template for a new mail, we actually unindex and remove the mail mistakenly from notmuch and the file system. Instead all we want is a copy for composing. This is a workaround for now, since ideally we want to keep all compositions as a draft on the file system (see #351). This patch only unindexes/removes draft mails, any other mail contents are simply copied for composition. Fixes #395
romanofski
added a commit
that referenced
this issue
Jun 23, 2020
Initially composeAsNew was implemented with the idea to continue draft mails. The mails are stored in the file system and indexed in notmuch. Once the draft is picked up again, the mail is unindexed and removed from the file system until it's sent. However, if we use the same function on existing mails in order to use the mail as a template for a new mail, we actually unindex and remove the mail mistakenly from notmuch and the file system. Instead all we want is a copy for composing. This is a workaround for now, since ideally we want to keep all compositions as a draft on the file system (see #351). This patch only unindexes/removes draft mails, any other mail contents are simply copied for composition. Fixes #395
romanofski
added a commit
that referenced
this issue
Jun 24, 2020
Initially composeAsNew was implemented with the idea to continue draft mails. The mails are stored in the file system and indexed in notmuch. Once the draft is picked up again, the mail is unindexed and removed from the file system until it's sent. However, if we use the same function on existing mails in order to use the mail as a template for a new mail, we actually unindex and remove the mail mistakenly from notmuch and the file system. Instead all we want is a copy for composing. This is a workaround for now, since ideally we want to keep all compositions as a draft on the file system (see #351). This patch only unindexes/removes draft mails, any other mail contents are simply copied for composition. Fixes #395
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
When editing an e-mail we store the temporary mail in the "Drafts" folder in order for an external editor to edit it. Once that is done control is handed back to purebred and the temporary file in the Drafts folder is removed. The mail is such is sitting in it's serialised form as data in purebred.
However if purebred crashes here, the mail is lost which is not very good. The status quo is due to the fact that we currently don't have a good way to find the draft mail again in order to update it (e.g. if the user decides to re-edit it again).
Describe the solution you'd like
Store any draft (first or updated) in the "Drafts" folder until the mail has been successfully sent. I think I can live if it doesn't reflect the latest changes to the
To:field orSubject:line, but the mail body is important to not get lost.Describe alternatives you've considered
None
Additional context
I realised it when adding a test for #350 because the acceptance test asserts that the "Draft" mail is empty after editing. That is a state I don't want Purebred to be in if it wants to become a productive tool.
The text was updated successfully, but these errors were encountered: