No Virtual Trash

After turning off the Trash folder, I don't get the Virtual

Mon, 09 Feb 2015 17:22:54 +0000

After turning off the Trash folder, I don't get the Virtual Trash folder instead.

I'm confused... if you disable Trash (i.e. Trash = None), wh

Tue, 10 Feb 2015 19:05:17 +0000

I'm confused... if you disable Trash (i.e. Trash = None), why would Virtual Trash appear? Virtual Trash should only appear if you explicitly select it (which I verify works).

What do you mean with "if you select it"?

Tue, 10 Feb 2015 19:24:43 +0000

What do you mean with "if you select it"?

Trash Mailbox drop-down selection list in "Deleting and Movi

Tue, 10 Feb 2015 19:32:32 +0000

Trash Mailbox drop-down selection list in "Deleting and Moving Preferences" pref page. Second option in that list (after "None") is "Use Virtual Trash".

Now that's one of a hidden setting. I never use Virtual Tras

Tue, 10 Feb 2015 19:49:10 +0000

Now that's one of a hidden setting. I never use Virtual Trash, so when has it been moved there? Now that I was able to enable Virtual Trash, it's broken though: - You still see deleted messages in the regular mailboxes. - You cannot undelete messages. - You can drag messages from the VT to any folder while they stay deleted.

Changes have been made in Git (master): commit cad459b54d0a

Wed, 25 Feb 2015 07:04:21 +0000

Changes have been made in Git (master): commit cad459b54d0a2ea63a0c6cb27ef4164199408205 Author: Michael M Slusarz Date: Wed Feb 25 00:03:34 2015 -0700 Bug #13852: Fix display of delete-related options when using virtual trash imp/js/base.js | 28 +++++++++++++++------------- imp/lib/Ajax/Application/ListMessages.php | 14 ++++++++++++-- imp/lib/Dynamic/Mailbox.php | 6 ------ 3 files changed, 27 insertions(+), 21 deletions(-) http://github.com/horde/horde/commit/cad459b54d0a2ea63a0c6cb27ef4164199408205

> Now that's one of a hidden setting. I never use Virtual Tr

Wed, 25 Feb 2015 07:06:46 +0000

> Now that's one of a hidden setting. I never use Virtual Trash, so > when has it been moved there? Between IMP 4 and IMP 5. > Now that I was able to enable Virtual Trash, it's broken though: > - You still see deleted messages in the regular mailboxes. Can't reproduce. > - You cannot undelete messages. Fixed. > - 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.

>> Now that's one of a hidden setting. I never use Virtual T

Wed, 25 Feb 2015 07:27:31 +0000

>> Now that's one of a hidden setting. I never use Virtual Trash, so >> when has it been moved there? > > Between IMP 4 and IMP 5. I found the old behavior with a checkbox to enable the virtual trash more intuitive. But I don't have a strong opinion about this either. >> Now that I was able to enable Virtual Trash, it's broken though: >> - You still see deleted messages in the regular mailboxes. > > Can't reproduce. > >> - You cannot undelete messages. > > Fixed. Needs to be backported too. Thanks! >> - 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. 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. If we don't want to undelete message after moving from a virtual trash for whatever reasons (which would be the correct behavior too), we again need to disable moving.

>>> Now that's one of a hidden setting. I never use Virtual

Wed, 25 Feb 2015 07:37:30 +0000

>>> Now that's one of a hidden setting. I never use Virtual Trash, so >>> when has it been moved there? >> >> Between IMP 4 and IMP 5. > > I found the old behavior with a checkbox to enable the virtual trash > more intuitive. But I don't have a strong opinion about this either. Having separate "trash" and "virtual trash" options was completely unintuitive. They are the same thing. Virtual Trash is a *type* of trash mailbox; it's not a separate entity. >>> Now that I was able to enable Virtual Trash, it's broken though: >>> - You still see deleted messages in the regular mailboxes. >> >> Can't reproduce. >> >>> - 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. >>> - 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. > 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).

>>>> - You cannot undelete messages. >>> >>> Fixed. >> >

Wed, 25 Feb 2015 08:19:23 +0000

>>>> - 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.

Needs at least backporting of the fix to H5

Fri, 27 May 2016 17:02:10 +0000

Needs at least backporting of the fix to H5