Add PermanentDeleteChecker to check if messages will be deleted permanently
#7731
Conversation
| * Note: This only applies to local messages. What remote operation is performed when deleting a message is controlled | ||
| * by [Account.deletePolicy]. | ||
| */ | ||
| internal class DeleteOperationDecider { |
There was a problem hiding this comment.
👍
Maybe LocalDeleteOperationDecider reflects it's purpose better or change it to an interface and provide a default implementation.
|
|
||
| sealed interface PermanentDeleteResult { | ||
| data object None : PermanentDeleteResult | ||
| data class Some(val permanentDeleteCount: Int) : PermanentDeleteResult |
| @@ -223,6 +223,11 @@ class FolderRepository( | |||
| return messageStore.getFolder(folderId) { true } ?: false | |||
| } | |||
|
|
|||
| fun isLocalFolder(account: Account, folderId: Long): Boolean { | |||
There was a problem hiding this comment.
Maybe isLocalFolderOnly would describe it better.
There was a problem hiding this comment.
This class could benefit from a test.
| return deleteOperationDecider.isDeleteImmediately(account, folderId) && !isRemoteCopyKept(account, folderId) | ||
| } | ||
|
|
||
| private fun isRemoteCopyKept(account: Account, folderId: Long): Boolean { |
There was a problem hiding this comment.
This could be a RemoteDeleteOperationDecider
| private fun getPermanentDeleteCount(account: Account, messageReferences: List<MessageReference>): Int { | ||
| return messageReferences | ||
| .groupBy { it.folderId } | ||
| .map { (folderId, messageReferences) -> |
There was a problem hiding this comment.
This threats all MessageReference related to a specific folderId in the same way. Is it possible for certain messages to be marked as "do not delete"?
cketti
added
the
status: needs work
|
I'm not quite happy with this approach. Having to perform disk I/O to be able to display a confirmation dialog (#7707) feels wrong. I think we should change the message (list) loading code to include the information necessary to answer the question whether a delete operation will permanently delete the message. Closing this PR. I will open new PRs with the useful refactorings from this PR. |
|
@cketti Have new PRs been opened for the required refactorings finally? If the code provided the information to the email list for where each email is stored, it would not only allow for the delete confirmation to be implemented for the trash specifically, but it could also allow for the addition of folder labels within the email list. For example, if you add the "Junk" folder to the unified inbox (which is useful when your email provider has a crappy, over-agressive junk filter), it is useful to specify that this was flagged as junk right from the email list. |
It's surprisingly complex to find out whether deleting a message in the app will permanently delete this message, i.e. delete the local copy and the server copy (if available).
This is required functionality for #7707.