Tickets :: Comment on [#12473] Allow undelete message option

* Your Email Address
* Spam protection	Enter the letters below: ._.. .. ..___.__ \| \ /\| \|[__ [ __ _\|_ \/ \|__\|\| [_./
Comment	>> 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.
Attachment
Watch this ticket

Saved Queries