Edgewall Software
Modify

Opened 7 years ago

Closed 7 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:

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 Changed 7 years ago by Christian Boos

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>).

comment:2 Changed 7 years ago by osimons

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 Changed 7 years ago by osimons

Like this:

  • trac/ticket/templates/query_results.html

    a b  
    8686              </tr>
    8787
    8888              <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>
    9589                <py:choose>
    9690                  <tr py:when="ticket_context.resource in context" class="fullrow">
    9791                    <td colspan="${len(headers)}">

Much nicer results. No tests affected - and likely no users bothered either ;-)

comment:4 Changed 7 years ago by Christian Boos

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.

comment:5 in reply to:  4 ; Changed 7 years ago by Christian Boos

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 in reply to:  5 Changed 7 years ago by osimons

Owner: set to osimons
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 Changed 7 years ago by osimons

Resolution: fixed
Status: newclosed

Committed in [10994] and merged to trunk in [10995].

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain osimons.
The resolution will be deleted.
to The owner will be changed from osimons to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.