Tickets :: Comment on [#13852] No Virtual Trash

* Your Email Address
* Spam protection	Enter the letters below: .__ .___.___..___. [__)[__ \| [__ \| [__)\| \| \| \|___
Comment	>>>>> - You cannot undelete messages. >>>> >>>> Fixed. >>> >>> Needs to be backported too. Thanks! >> >> Unfortunately, this isn't something that is directly backportable >> since message viewing has changed a bunch in IMP 7. Due to other >> time concerns (which I will hopefully be able to discuss very soon) I >> don't have the time to do the kind of involved backporting necessary >> for this. > > This is very pity, because even if we are working on H6, we still > need to support H5 for some time, until the next major version is > stable. > >>>>> - You can drag messages from the VT to any folder while they stay >>>>> deleted. >>>> >>>> The current behavior is correct. If you "move" a message out of >>>> Virtual Trash, it will disappear from virtual trash. But since the >>>> message has a deleted flag, it will "re-appear" when the virtual >>>> trash is explicitly refreshed (i.e. the search is run again). This >>>> is consistent semantics with every other search mailbox. >>> >>> It's not the same completely. Because if you move from a search >>> mailbox to a folder so that it doesn't match the search criteria >>> anymore, it works like a regular mailbox. >> >> Exactly my point. > > This is what I was trying to say. ;-) In this case it works correctly. > >>> And that's the more >>> important point. If we use the folder semantics with search results, >>> we need to use the folder semantics in user interaction too. Where we >>> cannot guarantee this interaction behavior, we need to disable it. If >>> we don't want to re-run the search immediately (which would be the >>> correct behavior) because it is too performance hungry, we need to >>> disable moving out of search folders. >> >> Why? Again... this is how every mailbox works... when you move a >> message out, it disappears. And all search mailboxes are not >> refreshed until explicitly told to. (There is a difference in >> semantics between search and non-search mailboxes, but that is OK >> because there is explicit visual indication - via the searchbar - of >> this difference). >> >> I guess I'm confused what you think you should be seeing. Moving a >> message out of the Virtual Trash should not cause that message to >> remain in the Virtual Trash. I'm not sure what other behavior you >> are expecting. (i.e. moving a message out of Virtual Trash to a >> different mailbox MUST cause the message to be initially removed from >> the virtual trash, since delivery to a mailbox could possibly result >> in the \deleted flag being removed, for example). > > I have to admit that in the case of moving a message out of a search > folder while still meeting the search requirements, both possible > behaviors may make sense, but may also be confusing. If I stick with > my folder semantics, the current behavior is indeed correct, the > message disappears from the current folder. It's still a bit > confusing if the message re-appears on the next visit, but probably > less confusing than the message instantly re-appearing. > > That leaves that second example of dragging from virtual trash. In > this case, it can be safely assumed that the user want's to undelete > the message, just like he would do when dragging from a regular trash > folder. What we need to do is not only to move the message to the > drop target (if it wasn't already from this folder), but also to > remove the \deleted flag. In this use case the folder metaphor not > only works instantly, but also permanently.
Attachment
Watch this ticket

Saved Queries