Summary | No Virtual Trash |
Queue | IMP |
Queue Version | Git master |
Type | Bug |
State | Assigned |
Priority | 1. Low |
Owners | jan (at) horde (dot) org |
Requester | jan (at) horde (dot) org |
Created | 02/09/2015 (3747 days ago) |
Due | |
Updated | 05/27/2016 (3274 days ago) |
Assigned | 05/27/2016 (3274 days ago) |
Resolved | |
Milestone | |
Patch | No |
Assigned to Jan Schneider
Taken from Michael Slusarz
State ⇒ Assigned
to support H5 for some time, until the next major version is stable.
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.
when has it been moved there?
more intuitive. But I don't have a strong opinion about this either.
unintuitive. They are the same thing. Virtual Trash is a *type* of
trash mailbox; it's not a separate entity.
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.
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.
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).
when has it been moved there?
more intuitive. But I don't have a strong opinion about this either.
- You still see deleted messages in the regular mailboxes.
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.
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.
when has it been moved there?
- You still see deleted messages in the regular mailboxes.
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.
commit cad459b54d0a2ea63a0c6cb27ef4164199408205
Author: Michael M Slusarz <slusarz@horde.org>
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
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.
Preferences" pref page.
Second option in that list (after "None") is "Use Virtual Trash".
State ⇒ Feedback
Virtual Trash appear?
Virtual Trash should only appear if you explicitly select it (which I
verify works).
Milestone ⇒
State ⇒ Assigned
Patch ⇒ No
Assigned to Michael Slusarz
Queue ⇒ IMP
Summary ⇒ No Virtual Trash
Type ⇒ Bug
Priority ⇒ 1. Low
folder instead.