Opened 12 years ago
Closed 12 years ago
#10573 closed defect (fixed)
Why 'reported by' details when showing extra information rows in Query results?
| Reported by: | osimons | Owned by: | osimons |
|---|---|---|---|
| Priority: | normal | Milestone: | 0.12.4 |
| Component: | query system | Version: | |
| Severity: | normal | Keywords: | |
| Cc: | Branch: | ||
| Release Notes: |
Additional rows of output for query records are no longer prefixed with a 'Reported by…' line |
||
| API Changes: | |||
| Internal Changes: | |||
Description
When making a Custom Query and adding additional rows for display (such as 'Description'), each result with data will also include an extra row like:
Reported by osimons, 2 months ago.
The simple question is: Why? Seeing that both 'Created' and 'Reporter' are now available as columns, I will select the columns if I want the information. The row only represents clutter if not, and as far as I can tell it cannot be removed? Say for a 'Release Notes' custom query here at t.e.o, why would reporter and age of ticket be of interest?
It looks like the code for this in query_results.html was added quite some time ago, and likely long before 'Created' timestamp was available in query. Can we please just remove the code that injects this meta row?
(As usual I'm hoping this oversight can be labeled a 'regression' from reworked 0.12 query, and that it can be scheduled for removal from 0.12-stable so that I can actually expect to see this change in production in the not-too-distant future… ;-)
Attachments (0)
Change History (7)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
And adding a query parameter to support the option, and query code and template code to handle the toggle? All for a line of output that exists for no particular reason? I don't want to add code, I just want the output line removed for good.
I honestly cannot imagine that anyone will be sad to see it go, and "being used to it" is not a strong argument in favor of keeping something that obviously no longer belongs there. If anyone can provide a single reason why this line should appear whenever there is extended row information, I'll be happy to reschedule it for 0.13 instead.
comment:3 by , 12 years ago
Like this:
-
trac/ticket/templates/query_results.html
a b 86 86 </tr> 87 87 88 88 <py:with vars="result_rows = [t for t in row if result[t]]"> 89 <tr py:if="result_rows" class="fullrow">90 <td colspan="${len(headers)}">91 <p class="meta" i18n:msg="author, date">Reported by <strong>${authorinfo(result.reporter)}</strong>,92 ${dateinfo(result.time)} ago.</p>93 </td>94 </tr>95 89 <py:choose> 96 90 <tr py:when="ticket_context.resource in context" class="fullrow"> 97 91 <td colspan="${len(headers)}">
Much nicer results. No tests affected - and likely no users bothered either ;-)
follow-up: 5 comment:4 by , 12 years ago
I was just trying to stay true to a policy of "no visible and behavioral changes in -stable", especially now that we're late in the 0.12-stable cycle and I'd like to see people get full focus on 0.13.
For the specifics of this ticket, I quite agree on the fact that this Reported by … is an annoyance for e.g. a "Release Notes" query and could be emulated by adding extra columns in the "historical" case of query with Description. You're probably right that it's not worth adding more code just for the sake of this (non-written) policy.
In think the real problem you exposed here is rather the fact that we have a quite slow pace for making releases:
so that I can actually expect to see this change in production in the not-too-distant future…
… topic to be continued on Trac-dev ;-)
Besides, when looking at that change, I discovered a real problem with custom queries and full rows. At first, this looked like a regression on #9834 but it is not, as 0.12.2 is also affected. The problem is that as soon as there's a <pre> block in the description, the width of the result rows takes as much space as needed to show that <pre> block in full width. The other text lines are no longer wrapped and this leads to very unreadable reports, even useless ones when printed, as in this case the text lines are truncated. Trying to fix this lead me in the #10533 territory, so I'll follow-up there.
follow-up: 6 comment:5 by , 12 years ago
Replying to cboos:
For the specifics of this ticket, I quite agree on the fact that this Reported by … is an annoyance for e.g. a "Release Notes" query and could be emulated by adding extra columns in the "historical" case of query with Description. You're probably right that it's not worth adding more code just for the sake of this (non-written) policy.
… which means I'm OK with your proposed change on 0.12-stable!
comment:6 by , 12 years ago
| Owner: | set to |
|---|---|
| Release Notes: | modified (diff) |
Replying to cboos:
… which means I'm OK with your proposed change on 0.12-stable!
And the crowd goes wild! The "OK" had gone unnoticed until now. Oh, joy!
/me switches to editor & terminal
comment:7 by , 12 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Well, for that removal to not be qualified itself as being a regression (for the people who just are used to it and actually expect it), the easiest solution would be to add a last checkbox "[ ] Hide reporter details" in the Show under each result section (after a <br>).