Opened 17 years ago
Closed 16 years ago
#7179 closed defect (fixed)
report grouping broken
Reported by: | Christian Boos | Owned by: | Christian Boos |
---|---|---|---|
Priority: | high | Milestone: | 0.11 |
Component: | report system | Version: | devel |
Severity: | normal | Keywords: | |
Cc: | kamil@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
It seems that the __group__
feature of the TracReports doesn't work anymore, likely due to r6842.
This is visible on t.e.o with {21} (all results fit in a page, so the paging support is not in cause).
Attachments (1)
Change History (10)
comment:1 by , 17 years ago
Owner: | changed from | to
---|
comment:2 by , 17 years ago
I fix the problem with this patch (report_grouping.patch). In the SQL query no ordering was made since it was using the column indexes to sort. I change it to use the column names.
by , 17 years ago
Attachment: | report_grouping.patch added |
---|
comment:3 by , 17 years ago
Status: | new → assigned |
---|
Thanks for the patch.
But I'm afraid it's not enough to completely fix the sorting for groups: if we take sort col to be __group__
, then we have no way to sort on the value as opposed to the name, like done in r6842. We probably need an extra __groupvalue__
special name for this.
comment:5 by , 17 years ago
Cc: | added |
---|
The fact that the report's SQL query is wrapped by another SELECT
query (presumably for pagination support) is also messing up ordering in PostgreSQL. With the patch, if I use __group__
in my report, the order of the tickets returned not preserved within each group.
eg: If they were originally sorted by ticket #, the sort order will be pretty much random. Try the following query to see this effect:
SELECT milestone AS __group__, id AS ticket, summary, component, version, t.type AS type, severity, owner, status, time AS created, changetime AS _changetime, description AS _description, reporter AS _reporter FROM ticket t, enum p WHERE status <> 'closed' AND p.name = t.priority AND p.type = 'priority' ORDER BY ticket
comment:6 by , 16 years ago
I can confirm this bug exists in 0.11rc1. I just upgraded my environment to the RC and noticed immediately that my report groupings are broken.
comment:7 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Fix verified and committed as [7130], many thanks Jasmin!
comment:8 by , 16 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
This fix 'doesn't fix' the error occurring with Timing and Estimating Plugin
http://www.trac-hacks.org/wiki/TimingAndEstimationPlugin
The reports now are totally 'blank'.
comment:9 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Sorry, that's not the place where that plugin is maintained, and you don't even say what is that error with this plugin.
You have to report the error to the plugin maintainer, and if he thinks Trac is doing something wrong, then he'll be the more appropriate person to (re)open a bug in this Trac.
Shouldn't delay rc1, but needs to be fixed before 0.11.