[Patch] Query module column reordering

[ebray]

This is a patch I came up with at PyCon specifically because some of my users need it, but I think something like it could go into Trac core.

First of all it solves the problem of the poor scalability of the UI for selecting columns to display, which is pretty unusable in situations where there are something on the order of 50 custom fields (which I've seen, and it's ugly).

I also needed the ability to let users reorder the columns, which this solves. I'm not sure how the Trac devs will feel about this. It replaces the 'col=' query arguments with arguments in the form 'col#=', where # is the order that that column should be displayed in. This works fine for URL query strings. But I haven't updated the TracQuery syntax to support column reordering. Other than that it seems to work fine, and includes support for non-JavaScript users.

[hyugaricdeau@…]

Some of the diffs may be from my editor removing stray whitespace, which may be annoying.

[hyugaricdeau@…]

Forgot to set all the other fields, oops.

[Christian Boos]

I tried the patch and it works great. I think the UI is perfect for the non JavaScript case, but with JavaScript enabled, I'm sure we could even make this more intuitive in the future by providing the possibility to simply dragg the column name up and down.

I'm not sure about passing the ordering info (coln). Currently, we simply rely on the order of the col arguments in req.args['col'] to be the same as they appear in the query string. Is there a situation were this wouldn't work? If not, I think the code could be simplified a lot. At the very least, the col parameters without a number should still be supported for backward compatibility and for example, added at the end after the numbered columns.

[ebray]

I didn't know that arguments of the same name were guaranteed to appear in the list in the same order that they appear in the query string. But if so, then that definitely simplifies matters greatly. I'll have to try it out and see what I can come up with.

I thought I did maintain backwards compatibility by listing col arguments after the coln arguments. But maybe I just thought it but never did it. Oh well, if the above is true then it's a moot point.

Dragging of columns would definitely be nice, but that would probably make sense to do once jQuery UI is included with Trac, which there seems to be some talk about doing.

[ebray <hyugaricdeau@…>]

Simplified patch without modifying url query strings.

[ebray <hyugaricdeau@…>]

Here's a much simpler version of the patch that does not depend on the coln query string arguments, as long as the col= arguments are listed in order it works fine.

[ebray <hyugaricdeau@…>]

Simplified patch without modifying url query strings.

[ebray <hyugaricdeau@…>]

Ignore the previous attachment. I did the diff on the wrong directory.

[ebray <hyugaricdeau@…>]

Ignore that version of the patch too.. It had a weird stray line left in it. This is the one you want.

[ebray <hyugaricdeau@…>]

An updated version of this patch with a somewhat improved implementation. The UI for adding and removing columns is now more similar to the UI for adding/removing filters.

[Remy Blank]

This would have to be re-adapted on top of the new query UI and the query.js rewrite using jQuery. I suggest moving back to 0.13.

I would also argue in favor of direct drag-and-drop of columns when JavaScript is enabled.

[Christian Boos]

Agreed (especially the d'n'd part ;-) ).

But let's move it to 0.13 once all the current 0.13 are retargeted to the next-major milestone.

[ebray]

I readapted it to go with the other changes in my own Trac, but I'd have to redo the patch for it to fit into trunk. Regardless, I agree that it could use some rework in general. Drag and drop sounds nice :)

[Remy Blank]

To be done in 0.13 (which doesn't exist yet).

[Steffen Hoffmann]

just finishing the intended ticket triaging

In fact, considering especially the depreciation note at TracReports to get rid of that module, respecting a custom defined column order is an absolute must-have for TracQuery.

[Christian Boos]

Well, unless you're willing to provide yourself a patch (and hammer it until it gets included!), please don't schedule things for 0.13 (see the policy note on the milestone).

We're thinking on closing 0.13 sooner rather than later, and this will rather mean moving things away from 0.13 and finishing (the many) contributions that are already in a good shape.

[Jun Omae]

I implemented ​th:TracFlexibleQueryUiPlugin as a plugin for this feature.

[Ryan J Ollos]

Replying to Jun Omae:

I implemented ​th:TracFlexibleQueryUiPlugin as a plugin for this feature.

Looks really nice! Do you think the plugin is suitable for integration to Trac? I did a code drop in log:rjollos.git:t7026_query_column_reordering, and it seems to be functional. There would need to be a significant amount of refactoring in areas where the plugin was working around the Trac API. Any advice or recommendations on moving forward with this? I might try to spend some time on it, but before I pursue it I'd want to know if you think this is the right approach to adding the feature in Trac, or if you'd take a different approach.