Erik Bray wrote: > +1 here. I've already removed it in my own Trac instances for the > reasons you've described. At one point I spent some time trying to > make this a little more dynamic so that columns would be re-added if > the grouping column was changed, but then you had to keep track of > whether or not that column was enabled or disabled to begin with, and > it just becomes too cumbersome.
I came to the same conclusion. It's not the first time that you mention having removed or changed something in your installations and that has been requested later independently. Any other good ideas that I could implement? I'm good at cleaning up :-) > Easier to just remove the restriction and allow users to add a column > even if the results are already grouped by that column. Some of my > users actually wanted to be able to do that so that they could include > a column when doing a CSV export, but still view the results grouped > by that column. I have implemented something slightly different: I have removed the algorithm from get_all_columns(), which is used to create the list of check boxes, so all checkboxes are always present. And I have moved it into get_default_columns(), which is used when no columns are specified in the query or URL (i.e. when coming to the query page from a [query:...] link that has no column specification). That way, existing queries should not change too much. -- Remy
signature.asc
Description: OpenPGP digital signature
