grouped query output

[ThurnerRupert]

additionally to list view, the result of a query could also displayed grouped. one possibility would be "ticket status by <something to choose>", like in the view of a milestone.

an example what i tried to do: how do i get a view like milestone:0.10 for a user, i.e. the users/groups open tickets per component and the status?

[Matthew Good]

anonymous: don't close a ticket without a comment.

[Matthew Good]

The query page has the "Group results by" field below the Filters.

[ThurnerRupert]

but this is still a "list of items" and not a grouped bar chart like in the milestone view?

[sid]

This sounds like a duplicate of #2497.

[Christian Boos]

For implementing this:

an example what i tried to do: how do i get a view like milestone:0.10 for a user, i.e. the users/groups open tickets per component and the status?

I think one possibility would be to add another output format to the TicketQuery macro (like progressbar) and base this on the patch in #2314.

[sid]

+1 to making this part of the TicketQuery macro. How about barchart?

[sid]

Adds a progressbar option to the TicketQuery macro

[sid]

Adds a progressbar option to the TicketQuery macro (incorrect upload before)

[sid]

Oops, can't delete or overwrite my bad upload on the 1st file. But the second upload should be the right one.

The patch is against trunk, and adds a progressbar option to the TicketQuery macro that will display a progress bar similar to the one on the Roadmap and Milestone View pages.

[Christian Boos]

Probably not for 0.11.

For 0.12, it could be interesting to have that on the "user" page.

[Christian Boos]

#8347 was closed as duplicate.

About the patch attachment:ticket_query_progressbar_4155-2.diff​, it doesn't look like it actually takes the results of the current query into account (and returning a template filename?!).

The correct approach would be to build stats data from the query results, and generate an HTML document fragment, similar to what is done with the table format.

[psuter <petsuter@…>]

The following patch expands [[TicketQuery(...,format=progress)]] to a roadmap-style progress bar. Grouping using [[TicketQuery(...,format=progress, group=...)]] gives similar 'bar charts' as are shown on the milestone page.

Circular imports between trac.ticket.roadmap and trac.ticket.query gave me some trouble, avoided by switching the respective from import to plain import statements. Is there a better solution?

Most code was copied from MilestoneModule._render_view. Should it share the code somehow? Parts from milestone_view.html are rebuilt using tag calls. Should the macro (re)use a template instead? (Similar to how format=table uses the query_result.html template?) And the roadmap.css #stats section was duplicated and tweaked for the new .progressquery class. Better ideas?

[psuter <petsuter@…>]

TicketQuery(format=progress) patch against trunk @10747

[Remy Blank]

Replying to psuter <petsuter@…>:

The following patch expands [[TicketQuery(...,format=progress)]] to a roadmap-style progress bar. Grouping using [[TicketQuery(...,format=progress, group=...)]] gives similar 'bar charts' as are shown on the milestone page.

Looks very nice!

Circular imports between trac.ticket.roadmap and trac.ticket.query gave me some trouble, avoided by switching the respective from import to plain import statements. Is there a better solution?

You can perform the imports in the function where you need the symbols, so they will be executed at run time instead of module load time.

Most code was copied from MilestoneModule._render_view. Should it share the code somehow?

It would be nice if the common code could be extracted into a function, yes.

Parts from milestone_view.html are rebuilt using tag calls. Should the macro (re)use a template instead?

The repeated call to chrome.render_template() may be an indication that a template would be better, but both approaches are valid.

And the roadmap.css #stats section was duplicated and tweaked for the new .progressquery class. Better ideas?

You could combine the selectors with identical content:

#stats legend, .progressquery legend { white-space: nowrap }
#stats table, .progressquery table { border-collapse: collapse; width: 100% }
...

A minor nitpick: to get the statistics provider, you should use RoadmapModule(self.env).stats_provider rather than self.env[roadmap.RoadmapModule].stats_provider (the latter can return None if the component is disabled).

[psuter <petsuter@…>]

Replying to rblank:

A minor nitpick: to get the statistics provider, you should use RoadmapModule(self.env).stats_provider rather than self.env[roadmap.RoadmapModule].stats_provider (the latter can return None if the component is disabled).

Ah, thanks for the hint. I actually wondered what the difference between these was. When should the env[] approach be used?

[Remy Blank]

Replying to psuter <petsuter@…>:

Ah, thanks for the hint. I actually wondered what the difference between these was. When should the env[] approach be used?

When you want to get the component if it is enabled, but you don't want to instantiate it if it's disabled. See for example roadmap.py​, where we only generate links to ticket queries if the QueryModule is enabled.

If we used QueryModule(self.env), the QueryModule would be instantiated regardless of whether it's enabled or not.

[psuter <petsuter@…>]

Replying to rblank:

When you want to get the component if it is enabled, but you don't want to instantiate it if it's disabled.

Oh ok, now that seems obvious in retrospect.

The following updated patch should fix this and the other issues. (Avoiding circular imports using function scope imports; extracting duplicated code to new helper function grouped_stats_data() and combining identical CSS selectors.)

Thanks again for the helpful feedback!

[psuter <petsuter@…>]

Updated patch incorporating input from comment:13

[Remy Blank]

Replying to psuter <petsuter@…>:

The following updated patch should fix this and the other issues.

Awesome work! Patch applied in [10750], and refactored somewhat in [10751]:

• Instead of duplicating the CSS selectors, added two new classes trac-progress and trac-groupprogress and applied these classes in the milestone views as well.
• Moved the grouped progress bar rendering into a separate template, and re-used it in the macro rendering instead of duplicating the logic.

[psuter <petsuter@…>]

Replying to rblank:

Awesome work! Patch applied in [10750], and refactored somewhat in [10751]:

Nice, thanks.

• Instead of duplicating the CSS selectors, added two new classes trac-progress and trac-groupprogress and applied these classes in the milestone views as well.
• Moved the grouped progress bar rendering into a separate template, and re-used it in the macro rendering instead of duplicating the logic.

Looks good! I wasn't sure how acceptable it would be to refactor existing code, templates and styles for a small macro feature, but it definitely helps to keep things clean.

[Steffen Hoffmann]

Funny, I was actually about to implement additional progress bars for subtopics of milestones in a new wiki macro. Seeking for reusable code somehow I stumbled over this ticket. So all I have to do is to add the currently missing i18n for it. The message catalogs don't hold the required msgid's right now. Thanks a bunch for the effort, Peter.