[Users] [Bug 4413] New: Enable "undelete" for IMAP messages

noreply at thewildbeast.co.uk noreply at thewildbeast.co.uk
Tue Nov 17 16:05:49 CET 2020


https://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=4413

            Bug ID: 4413
           Summary: Enable "undelete" for IMAP messages
           Product: Claws Mail
           Version: 3.17.8
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Folders/IMAP
          Assignee: users at lists.claws-mail.org
          Reporter: claws-bugzilla at skopos.be

Created attachment 2139
  -->
https://www.thewildbeast.co.uk/claws-mail/bugzilla/attachment.cgi?id=2139&action=edit
Patch to enable IMAP undelete

This patch adds the possibility to undelete IMAP messages.

1. To start out with the obvious: with an IMAP server, message deletion is a
two-step process: first the "\Deleted" flag is set on the message(s), next an
"expunge" command removes all messages with that flag.

This means that, in between, it is possible to "undelete" the message, simply
by removing that flag again. Many MUA's have that functionality already.

The code to toggle the IMAP flag is already present in Claws Mail (imap.c), but
it can't be used because the GUI ignores a delete command for a message that is
already deleted.

The attached patch makes that mechanism available through the GUI: successive
"delete" operations on the same message will now toggle the flag each time.


2. Of course, this will only work if "execute immediate" is not activated,
otherwise the message will have been expunged already. 

One could say that, in that case, the user wouldn't be able to invoke the
"undelete" command on it anyway, so we need not care about it, but I added a
short test anyway.

Another prerequisite for an undelete is that the message lives in an IMAP
folder.

The patch tests for these conditions, and simply ignores a second "delete"
command if the message is already deleted and the requested "undelete" is not
possible - exactly as before.


3. Now, if the above conditions are met and therefore a delete can indeed be
undone later, it is no longer needed nor desirable to ask for confirmation
first.

Of course, confirmation is still needed for irreversible deletes, i.e. for
messages that are not in an IMAP folder etc.

The patch makes the distinction and will not ask for confirmation if the action
is reversible.


4. As before, a "delete" operation works also when multiple messages are
selected. It just becomes a "multi-delete" (as before), or a "multi-undelete"
if all the selected messages are already flagged for deletion.

The question is what to do when the user selects a mix of "deleted" and "not
yet deleted" messages. If we allow that, the code would not have any problem
with it, the flags would simply be toggled for all of them. 

Clearly, this would lead to user surprises and is therefore not desirable. The
patch will simply refuse an (un)delete operation in that case. Instead, it pops
up an error message and stops processing the request.


5. What the patch does not (yet?) do is change the wording of menu items. They
continue to say "Delete...", even when the message is already deleted and they
should really say "Undelete" (note: without the dots!). 

And In the cosmetics department: if the delete can be undone, the menu item
should not have any dots after the "Delete" either (because they promise a
confirmation dialog that won't come).


6. I didn't think a new "enable_imap_undelete" preference was needed here.

But it is easy enough to add one to the patch if so desired.


7. And who knows, some day this "undelete" facility might become a building
block for a "super-duper-doitall undo button", as requested more than ten years
ago in bug 1972.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the Users mailing list