While troubleshooting a bug with the recently added next/previous thread links, I noticed that getToplevelMessages[1] was not behaving as I expected it to. Specifically, there were two places where I wanted different behavior:
1. The function takes an optional boolean argument, recent_first. When true, the method sorts the threads by their modification dates, with the thread with the most recent response listed first. Unexpectedly (at least to me), when recent_first is false (the default), the threads are returned sorted by their dates, i.e., by when the initial message was sent. Thus this is *not* necessarily the reverse ordering from when specifying recent_first = True. 2. getToplevelMessages also takes optional start and end arguments for specifying a date range. Again, this range uses the dates and not the modification dates of the messages. This leads to confusion, particularly when sorting on the modification, since you will likely not get the results you expect (e.g., you'll likely get messages that you thought should have been filtered out). I'd like to modify the function to both sort and filter by modification_date. This seems to me to be more sensible behavior, particularly because it provides the expected behavior when dealing with threads. I've grep'd through the code and it doesn't look like it will break anything, but I wanted to shoot an e-mail out to the list to make sure no one was relying on the current behavior or had some reason to prefer it. Thanks, -Nick [1] getToplevelMessages is defined here: http://dev.plone.org/collective/browser/Products.listen/trunk/Products/listen/utilities/archive_search.py -- Archive: http://www.openplans.org/projects/listen/lists/listen-dev/archive/2009/01/1232731995822 To unsubscribe send an email with subject "unsubscribe" to [email protected]. Please contact [email protected] for questions.
