Issue

The sort order for discussions is un-intuitive. Discussions should be listed by the date they were last 'active' (ie: last updated). Currently discussion lists look like they do in the attachment, with a jumbled order.

Investigation

The view does not properly take into account when a discussion and its replies were updated in the sort order: it uses MAX(Content: Updated date) (desc). It should sorting on (Replies) MAX(Content: Last updated date (child/parent)). Sorting on this does not correct the order though, even though the same field displays the correct date when it is a field in the view.

This could be because the 'Last updated (child/parent)' field has a custom handler when it is used as a field (views_handler_field_oa_last_date in oa_discussion module), but there is no custom handler for when it is used as a 'sort'. Therefore the logic that combines the updated dates of parents and children is not applied.

Edit: There is also no custom handler for when it is used as a filter, so attempting to filter by this field also doesn't work.

Proposed solution

Create a custom handler 'views_handler_sort_oa_last_date' that applies the field logic from the field handler, so that Views can sort them correctly. Then upate the OA Discussion views to use the 'Last update (child/parent)' field as the sort order.

Also create a custom handler for when the field is used as a filter.

CommentFileSizeAuthor
discussion-order.jpg220.93 KBjkingsnorth

Comments

jkingsnorth’s picture

Issue summary: View changes
jkingsnorth’s picture

OK, this is much more complicated than I thought to fix.

I've created a custom views handler for the field, but...

When we change the field aggregation settings to 'Maximum' then a different Views handler gets involved and overrides the custom Views handler I specified. Views switches to using 'views_handler_sort_group_by_numeric'.

I've not yet figured out how to override that handler, anyone have any ideas?

jkingsnorth’s picture

OK, so this perhaps isn't even possible at the moment, see #2231895: Allow custom aggregation handlers

I'm going to stop wading through this quagmire now, I was hoping to just use a custom sort handler, but it looks like the only way to achieve this might be by using extra custom code (altering the view output, using a different module or something). If someone knows a better way to proceed then please do let me know, surely there's a way for Views to achieve this; or a way using a custom views handler that I'm missing...

jkingsnorth’s picture

Perhaps if there were a number of 'helper' custom views fields, like there are when dealing with comments?

Eg: A coded Views field handler for 'Number of replies', 'Last updated or replied date'.

Then we wouldn't have to use Views aggregation. This would make the View simpler (although it would mean more custom code), make it much easier to create custom Views and make it possible to order the existing discussion Views correctly.

Views already has this kind of thing for comments. I can see why OA isn't using comments for discussion replies - but that would have made the whole discussion system a lot simpler.

dehacker’s picture

I echo this sentiment that the Discussion Posts section is unintuitive and not optimally utilized with the default config.

If the intention of Discussion Posts is to provide threaded discussions, similar to a forum, then the most recent replies should move the entire child/parent to the top of the OA Discussion Widget.

If I reply to an older Post, who's going to know, if it's already rolled off the discussion widget?

Also the reply form is called "New Reply" vs "Reply". Are there other types of replies than new?

Another related feature that would be useful is the ability to expand the entire child/parent thread in the discussion widget.

mpotter’s picture

Well, "Replies" are those that are already posted. The form is for adding a New Reply. Our feedback showed this was just a bit more intuitive.

But to the OP, yes, the sort order is currently an issue and as shown in this thread, it's a very difficult problem. The other problem with the discussion topics widget is that it doesn't have the normal "Active Space", "Active Section" selectors.

Honestly, the problem is with the complexity of how Views handles the aggregation. This was a view created early in the OA2 development process and we really wanted to use Views as much as possible. But now with hindsight I think this is an example of a widget that should be a custom widget instead of a View. We have many examples of non-views widgets in OA2 right now. Making this a custom widget would allow us to do the direct SQL query(s) that are needed rather than trying to force Views to do it for us.

However, the "Active Space" and "Active Section" filters currently only work with Views. We are currently working on making field formatters for those that can be used on any custom panels pane widget. Once this is done then we will tackle the discussion listing.

This would also allow us to do stuff like expanding the entire thread within the widget via Ajax calls, which is something we can't do as easily with Views.

hefox’s picture

> Perhaps if there were a number of 'helper' custom views fields, like there are when dealing with comments?

Comments have a table to track information like node comment number, last reply. This could work for some of the fields, but doesn't work for number of new replies since user last view, which means the aggrgation would have to stay anyway (or direct queries to find that info).

We're currently planning to keep the view as a view but add the space/section filters. The sort needs to be addressed still. Seems like doing a views query alter might be the simpliest.

mpotter’s picture

Status: Active » Closed (fixed)

hefox fixed this in 2.30 so re-open if it's still an issue.