mirror of
https://github.com/jberkel/sms-backup-plus.git
synced 2026-04-25 17:05:59 +03:00
[GH-ISSUE #835] Include SMS drafts in backup #660
Labels
No labels
AM+RCS
FAQ
awaiting response
backup
bespoke
bug
calendar
call log
cannot reproduce
cloudless
device-specific
documentation
dual- & multi-SIM
duplicate
feature-request
fixed in beta
good first issue
half-missing
help wanted
helpful
meta
misattribution
mms
other message sources
pull-request
question
rejuvenation
restore
schedule
security
stale
task
thanks
v1.5.1
v1.5.10
v1.5.11
v1.5.2
v1.5.3
v1.5.3
v1.5.4
v1.5.4
v1.5.5
v1.5.5
v1.5.6
v1.5.7
v1.5.8
v1.5.9
v1.6β
xoauth
~$ bounty $~
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/sms-backup-plus-jberkel#660
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @vladutm on GitHub (Dec 29, 2017).
Original GitHub issue: https://github.com/jberkel/sms-backup-plus/issues/835
Unfinished SMS that are not sent and are only saved as drafts in the default app are not backed up to google account. Neither automatic nor manual backup seems to work.
Device: Huawei P10
Android version: 7.0
SMS Backup+ 1.5.10
Log: https://gist.github.com/vladutm/d7d77d90f2ff4f93fde07e9079840625
@jberkel commented on GitHub (Mar 28, 2018):
I'm not sure if the app should really back up drafts. This is the first and only request for such a feature.
@vladutm commented on GitHub (Mar 29, 2018):
Well, I would like that drafts to be backed up since I have a few drafts and the information in them is not irrelevant. For now, drafts are missing from my backup, but I guess I'll have to turn to another app/solution then for my need.
@jberkel commented on GitHub (Mar 29, 2018):
Another problem with drafts is that they can change. You do a backup, copy the draft. The user then makes modifications to the draft. What do you do on the next backup run? Replace the existing copy of the draft (difficult with email)? Copy another version of the draft? There would be all sorts of potential problems/edge cases.
@ildar commented on GitHub (Mar 29, 2018):
BTW are drafts stored in SMS storage or in app's storage?
@vladutm commented on GitHub (Mar 29, 2018):
I understand your point. From my side, the existing copy of the draft should be replaced to match the one on the device. Anyhow my drafts are not going to change.
What you said reminds me of another thing I wanted to mention/suggest: in the email sms are kept not only with the recipient number but with the name of the contact also(if that setting is chosen). But in the case of change of the contact name, in the email the name will not update and the old one will remain, making it difficult to search for a specific contact name in the email when you have two or more different names for the same person. I realize this suggestion of mine will be difficult to implement and although nice to have maybe it's not very useful.
@jberkel commented on GitHub (Mar 29, 2018):
@ildar there's a special content_uri for draft messages (https://developer.android.com/reference/android/provider/Telephony.Sms.Draft.html), so I assume they are accesible from other applications.
@vladutm what you're suggesting is indeed difficult to implement. usually once emails are stored they aren't touched again. there might be some specialized email tools which can do rename operations like that
@kurahaupo commented on GitHub (Jul 15, 2020):
IIRC, when the Gmail app shows messages without a human name in the From: header, it can search for a matching contact or Gmail account and use the name from there.
Maybe the solution to this problem is to entirely avoid putting a name in the From: header.
That said, I have some friends who swap SIMs (and thus phone numbers) and/or email addresses between family numbers, so handling this well is part of a much larger problem.
-Martin