[Tickets #12473] Re: Allow undelete message option

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12473
------------------------------------------------------------------------------
  Ticket             | 12473
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | Allow undelete message option
  Queue              | IMP
  Version            | Git master
  Type               | Enhancement
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2013-07-18 13:12) wrote:

> Thanks for your reply.  First, let me say that I never said the  
> above quote.  I would never assume that if a function exists in one  
> view, it should also exists in another.

I apologize.  I may be mixing various threads/tickets.  But at least  
one person in the past has said Undelete should appear because it is  
in at least one other view.  I was just trying to point out that is  
entirely irrelevant as to whether Undelete should appear in a  
different view.

> If you do allow for delete and provide a button for it, the I see  
> the case where a user will accidentally hit the delete button,  
> delete the message and have no way to undo what they did.

There are obviously drawbacks for not allowing the Undelete button.   
This is the primary one.  But the other factors I previously listed  
outweigh this drawback, IMHO.

The bigger issue is that the idea of keeping deleted messages in the  
mailbox is, from an implementation perspective, the absolute worst way  
to handle deleting messages.  From an implementation perspective, the  
only paradigm that makes sense is a Trash mailbox.  In other words, on  
a server that only offered a smartmobile instance, nobody would ever  
offer anything but delete w/Trash.

The issue comes when you are trying to support multiple UIs using the  
same backend.  Deleting in place is a valid use-case when you have a  
screen with sufficient information density to not affect work flow.