Private user-specific saved ticket queries

[nslowes@…]

I would greatly appreciate the ability to save custom ticket queries on a per-user basis. Saved queries currently show up in the reports view as part of all the public reports and are visible to everyone. I would like an option to save a query in a separate section that only I can see. This could be another section of the Reports view called "Personal Reports".

This way I can save queries that may only be of interest to me, and do things like re-order columns and sorting to my personal preference without affecting everyone else. This seems like a relatively simple change to make that could enhance user experience. I think it would also be very useful in multiple project scenarios, which are being planned for Trac 0.13.

[Remy Blank]

This is usually done with browser bookmarks. Edit a query, bookmark it, and you're done.

Suggesting "wontfix".

[nslowes@…]

I can see the argument for not including an unnecessary feature, but I still think it would improve usability, especially for new users. I don't really want to tell people they have to save queries in their browser. What about people who use multiple browsers? Or access Trac from multiple computers? With added support for multiple projects being hosted in the same Trac instance, I think this will become a larger issue because there will be more queries you are interested in and more people using the system. Many other issue tracking systems support this type of feature.

[shesek]

I do think its a feature that might won't implementing, but it should be noted that this can also be done with a wiki page that links to those custom queries. Just create CustomReport/Username wiki page with links to all the custom queries, than there's no issue with different browsers/computers.

[shesek]

In the last comment I added I had a typo - 'that might won't implementing' was suppose to be 'that might worth implementing.

A couple more notes- in the way we use Trac, we greatly rely on wiki pages for ticket summaries - we use multiple TicketQuery macros and [query] links to create custom ticket summary/overview pages. We have the WikiStart page set-up ​like that, and some developers create their own summary pages with the queries they find the must useful, which works out quite nicely for us. Would've been ever nicer if #9574 was implemented, as it could allow us to see per-project and per-component summary pages.

[Christian Boos]

I think this could be a nice feature, reusing most of the infrastructure of #1735 which I think is an underused feature. The main difference with #1735 would be to store the query in the session, and not in the report table.

[Remy Blank]

Still, I would suggest the OP tries the bookmarks approach, and reports back with his thoughts after a while. Sharing bookmarks is now possible with most browsers (e.g. Xmarks). The reason I insist is that when I started using Trac, I also wanted this feature, and it took me a while to realize that I could just use bookmarks, with the added benefit that I can jump to the desired query in a single click, instead of having to go to the Trac page, then select "View Tickets", and finally select my query. I haven't felt the need for this feature ever since.

And frankly, I don't understand what's wrong with "telling people they have to save queries in their browser".

Can we do this in a plugin? (Yes, I know, same old story, so I won't insist, just suggest.)

[Yaniv Vararu <yvararu@…>]

I use SQL to define the reports for our team and this gives me much more flexability with the results I'd like to see (Complex reports, which most of them can't be achieved by just saving queries). This means that I can't have my team save their "personal" reports using bookmarks anyway (Correct me if I'm wrong here).

This is the reason why I also would like to see the "private reports" option (On any report, not only ones that are created by saved queries).

By the way - regarding the last comment of rblank: If and when there will be such an option, it still doesn't mean you'll have to go to Trac, then to "View Tickets" and then to look for the desired reports. You can just save the links for these reports as bookmarks as well. It doesn't contradict each other…

[Christian Boos]

Replying to Yaniv Vararu <yvararu@…>:

This is the reason why I also would like to see the "private reports" option (On any report, not only ones that are created by saved queries).

I don't get it, you create custom SQL reports, yet that's not enough you want to mark them as "private reports" somehow? Are you thinking along the lines of the report organizer suggested in #7022? If not, I'm afraid I don't really understand what you'd like to achieve here…

[mcepl@…]

screenshot of the bottom of my bugzilla page

[mcepl@…]

Replying to cboos:

I don't get it, you create custom SQL reports, yet that's not enough you want to mark them as "private reports" somehow?

I think this ticket is about reimplementing what's in Bugzilla, where everybody could have per-user a lot of predefined queries available just by clicking on the link. See the attached screenshot.

[Christian Boos]

Replying to mcepl@…:

… I think this ticket is about reimplementing what's in Bugzilla, where everybody could have per-user a lot of predefined queries available just by clicking on the link. See the attached screenshot.

Hm, you'd really need #7022 with such a number of reports ;-)

In any case, both the initial request (having private custom queries) and the variant for SQL queries can be implemented relatively easily:

• add a "[ ] Private report" checkbox to the report save form
• get the ReportModule to handle requests for private report (/report/private/<report-name>), in which case the report data is fetched from and stored in the session
  • we could implement a part of #7022 for this simply by displaying the private reports in a hierarchy defined by the "/" separator in the report names (same convention as for wiki pages)
• creating and saving custom queries as private report should be possible even without the REPORT_CREATE permission, as there's no risk associated with this (TICKET_VIEW should be enough)

PatchWelcome ;-)

[fbrettschneider@…]

I don't know if it belongs to here but people here wished Trac wouldn't forget with every custom query which columns one selected in its previous query. I mean that set of checkboxes for all the fields. Can this be stored in the session, please?

[Christian Boos]

Replying to fbrettschneider@…:

I don't know if it belongs to here but …

For quick suggestions for which you don't think it's worth creating a new ticket for (perhaps because you don't have a patch to propose? ;-) ), you could use the TracIdeas pages (here TracIdeas/TracQuery). But… I just tested and it seems we do remember which columns are selected. If you have a reproduction recipe (on this Trac or one of the demos one, if it's version specific), please create a defect ticket.

[fbrettschneider@…]

Replying to cboos:

… I just tested and it seems we do remember which columns are selected. If you have a reproduction recipe …

Today on t.e.o.: main menu click 'View Tickets' → click 'Custom Query' → expand 'Columns' → select 'Component' → click 'Update' button → click main menu 'Wiki' → again click main menu 'View Tickets' → click 'Custom Query' → expand 'Columns' ⇒ Oops checkbox 'Component' is not on anymore (was not stored to session)

Is this a new defect ticket? Thanks

[Christian Boos]

Replying to fbrettschneider@…:

Replying to cboos:

… I just tested and it seems we do remember which columns are selected. If you have a reproduction recipe …

Today on t.e.o.: main menu click 'View Tickets' → click 'Custom Query' → expand 'Columns' → select 'Component' → click 'Update' button → click main menu 'Wiki' → again click main menu 'View Tickets' → click 'Custom Query'

Well, that's indeed different from the Return to Last Query one… Custom Query will start a fresh custom query. Maybe adding a hint will make this clearer.

[fbrettschneider@…]

Replying to cboos:

Well, that's indeed different from the Return to Last Query one… Custom Query will start a fresh custom query. Maybe adding a hint will make this clearer.

People here use Custom Query from time to time, but usually rather than safed reports (parameters vary too often) but want to reuse their old query (at least the output settings).

[Christian Boos]

Replying to fbrettschneider@…:

Replying to cboos:

Well, that's indeed different from the Return to Last Query one… Custom Query will start a fresh custom query. Maybe adding a hint will make this clearer.

The following change will make the current behavior more obvious:

• [f4ab7cd6/cboos.git] 1.0.2dev: Custom Query links renamed to New Custom Query, as that's what they actually do.

All of the changed links go to /query.

Contrast this with Back to Query (from a ticket) and Return to Last Query (from the report list), which go to req.session['query_href'].

People here use Custom Query from time to time, but usually rather than safed reports (parameters vary too often) but want to reuse their old query (at least the output settings).

Then they really should take the habit of doing 'View Tickets' → click 'Return to Last Query'. At 2 clicks distance from anywhere, I think we can't do much better and that reusing some constraints only for a for a new custom query would be all but confusing.

[fbrettschneider@…]

Replying to cboos:

The following change will make the current behavior more obvious:

…snip commit link…

Then they really should take the habit of doing 'View Tickets' → click 'Return to Last Query'. At 2 clicks distance from anywhere, I think we can't do much better and that reusing some constraints only for a for a new custom query would be all but confusing.

Agreed. And IMO with [f4ab7cd6/cboos.git] it's solved now well enough. Thanks a lot for your fast help.

[awilliam@…]

FWIW, another vote (from Red Hat…we use trac quite a lot in Fedora, thanks!) for the initial request here. It'd be kinda useful, plus as another factor in support, I think sometimes users might expect it to behave this way, and if you have a carefully-tended list of custom queries, a user saving a bunch of their own could screw it up. If it at least defaulted to each user having a private list of saved queries and admins only being able to save system wide, I think that'd be spiffy.

[Christian Boos]

Replying to fbrettschneider@…:

Replying to cboos:

The following change will make the current behavior more obvious:

…snip commit link…

Then they really should take the habit of doing 'View Tickets' → click 'Return to Last Query'. At 2 clicks distance from anywhere, I think we can't do much better and that reusing some constraints only for a for a new custom query would be all but confusing.

Agreed. And IMO with [f4ab7cd6/cboos.git] it's solved now well enough. Thanks a lot for your fast help.

Fast is relative… see follow-up in #11847.

[figaro]

Keyword typo