Changing sort direction doesn't work

I tried to change the sort direction from ascending per date

Sat, 19 Mar 2011 13:58:29 +0000

I tried to change the sort direction from ascending per date to descending in the virtual inbox. The sort arrow changed, a viewPort request was sent and a response received, but the sort order was the same.

Obviously sorting in search results won't work. It seems th

Tue, 22 Mar 2011 00:10:59 +0000

Obviously sorting in search results won't work. It seems that the code used to disable sort changing has been lost somewhere. Probably when I removed the 'sort_limit' config option. So this needs to be added back.

> Obviously sorting in search results won't work. At leas

Tue, 22 Mar 2011 03:28:57 +0000

> Obviously sorting in search results won't work. At least from a user perspective, not sure how this is obvious?

>> Obviously sorting in search results won't work. > > At

Tue, 22 Mar 2011 04:06:50 +0000

>> Obviously sorting in search results won't work. > > At least from a user perspective, not sure how this is obvious? How so? Sorting is (or at least should be - that's the point of this ticket) disabled in search mailboxes. This is the way IMP has always worked. So it should be obvious to users, when they can't change the sort columns, that sorting is not possible in a mailbox. Simply put, this is a limitation of IMAP. IMAP searches by mailbox ONLY. Now that I have written client side sorting in the Socket driver, it is possible to do sorting among multiple mailboxes. But this will require a significant alteration of the code in Imap_Client, and won't work for all sort options (e.g. sequence/arrival sort). --- Sure enough, the commit that removed the sort_limit configuration option is what removed the ability to lock a search mailbox from being sorted: commit d08804fd706e3cea9c3ea9aa9d9901b17dcf6fa9 Author: Michael M Slusarz Date: Fri Mar 5 09:50:31 2010 -0700 Remove 'sort_limit' configuration option. This option was meant to work around slowness/inadequacies of c-client. Our Imap_Client library is much faster, so this should not be an issue moving forward (if someone really wants to sort their 1,000,000 message mailbox by thread, I guess that should be their option).

>>> Obviously sorting in search results won't work. >> >>

Tue, 22 Mar 2011 09:26:12 +0000

>>> Obviously sorting in search results won't work. >> >> At least from a user perspective, not sure how this is obvious? > > How so? Sorting is (or at least should be - that's the point of this > ticket) disabled in search mailboxes. This is the way IMP has always > worked. So it should be obvious to users, when they can't change the > sort columns, that sorting is not possible in a mailbox. No, that's not the point of the ticket. ;-) We always used to support sorting in search results, and we must still support it. We don't have to support sorting across all mailboxes, agreed, though this would be nice long-term too. But at least within in the results per mailbox, sorting must be possible.

Changes have been made in Git for this ticket: Bug #9684: R

Tue, 22 Mar 2011 10:23:41 +0000

Changes have been made in Git for this ticket: Bug #9684: Restore sorting to search folders, although this is broken behavior 2 files changed, 6 insertions(+), 3 deletions(-) http://git.horde.org/horde-git/-/commit/c129d40ae98ac480d18123caa43406ed12ab3b9d

> We always used to support > sorting in search results, a

Tue, 22 Mar 2011 10:29:07 +0000

> We always used to support > sorting in search results, and we must still support it. We don't > have to support sorting across all mailboxes, agreed, though this > would be nice long-term too. But at least within in the results per > mailbox, sorting must be possible. Well I misspoke - we were sorting search results (other than by thread). However, this is totally broken behavior because it completely breaks search display in every interface BUT imp. e.g. in dimp, sorting appears to be totally random. This is NOT going to work. I don't care what we have done in the past, but this isn't going to fly. We either need to to abandon ALL sorting in the search views or implement client side sorting. And in imp, we need to get rid of the mailbox headers separating the various search mailbox results. This is entirely inconsistent with the way we display search results in the other views. Mailboxes should be irrelevant in search results - the messages are all that matters.

>> We always used to support >> sorting in search results,

Tue, 22 Mar 2011 10:49:09 +0000

>> We always used to support >> sorting in search results, and we must still support it. We don't >> have to support sorting across all mailboxes, agreed, though this >> would be nice long-term too. But at least within in the results per >> mailbox, sorting must be possible. > > Well I misspoke - we were sorting search results (other than by > thread). However, this is totally broken behavior because it > completely breaks search display in every interface BUT imp. e.g. in > dimp, sorting appears to be totally random. > > This is NOT going to work. I don't care what we have done in the > past, but this isn't going to fly. We either need to to abandon ALL > sorting in the search views or implement client side sorting. I agree, without the mailbox headers, sorting in other views than IMP looks random. I don't want to drop sorting of search results either, so client side sorting seems to be the only way out. > And in imp, we need to get rid of the mailbox headers separating the > various search mailbox results. This is entirely inconsistent with > the way we display search results in the other views. Mailboxes > should be irrelevant in search results - the messages are all that > matters. True, but at the moment, without client-side sorting, this is the only way to indicate how the sorting works. I assume that client sorting is a big task, so maybe we can add similar indicators for the other views too? Short-term I'm fine with how it works now, even if it's kinda broken, because this how it works in IMP 4/DIMP.

Closing and moving enhancement request to a new ticket.

Wed, 23 Mar 2011 06:09:50 +0000

Closing and moving enhancement request to a new ticket.