Buglist results using atom ctype do not display users with empty real names

RESOLVED FIXED in Bugzilla 3.4

Status

()

Bugzilla
Query/Bug List
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: reed, Assigned: reed)

Tracking

3.4.4
Bugzilla 3.4
Bug Flags:
approval +
approval3.6 +
approval3.4 +

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

8 years ago
It seems that if the reporter or assignee does not have a real name set, nothing is displayed in Atom results. If I go to the buglist link in the URL field, I see Atom results like the following:

    <author>
      <name></name>
    </author>
...
      &lt;/tr&gt;&lt;tr class=&quot;bz_feed_reporter&quot;&gt;
        &lt;td&gt;Reporter&lt;/td&gt;
        &lt;td&gt;&lt;/td&gt;

The reporter for bug 537663 does not have a real name set.

Here's some code from buglist.cgi...

    my @email_fields = qw(assigned_to reporter qa_contact);
...
    foreach my $col (@email_fields) {
        my $sql = "map_${col}.login_name";
        if (!Bugzilla->user->id) {
             $sql = $dbh->sql_string_until($sql, $dbh->quote('@'));
        }
        $special_sql{$col} = $sql;
        $columns{"${col}_realname"}->{name} = "map_${col}.realname";
    }

It's only looking at .realname, which can be empty.

Comment 1

8 years ago
That's not what I call a major bug. The realname is not displayed, that's all. If the whole bug was missing from the buglist, this would be another story.
Severity: major → normal
(Assignee)

Comment 2

8 years ago
(In reply to comment #1)
> That's not what I call a major bug. The realname is not displayed, that's all.
> If the whole bug was missing from the buglist, this would be another story.

Except that if there isn't a realname, _nothing_ is displayed, which can cause problems to people using that format for things.

Comment 3

8 years ago
(In reply to comment #2)
> Except that if there isn't a realname, _nothing_ is displayed, which can cause
> problems to people using that format for things.

Nothing as in the guy's identity isn't displayed, or as in the bug is totally missing from the list?
(Assignee)

Comment 4

8 years ago
(In reply to comment #3)
> Nothing as in the guy's identity isn't displayed, or as in the bug is totally
> missing from the list?

The guy's identity isn't displayed.
(Assignee)

Comment 5

8 years ago
Created attachment 419996 [details] [diff] [review]
patch - v1

Something like this...
Assignee: query-and-buglist → reed
Status: NEW → ASSIGNED
Attachment #419996 - Flags: review?(LpSolit)

Comment 6

8 years ago
For the record, this bug exists since Bugzilla 2.20, see bug 82878. From what I can read in buglist.cgi line 730, we append required fields for Atom *after* the fallback added at line 705, so bug.assignee and bug.reporter could as well be undefined in the Atom template. Please check this point.
(Assignee)

Comment 7

8 years ago
Created attachment 420008 [details] [diff] [review]
patch - v2

Indeed, added reporter and assigned_to to that list and tested it on landfill. Works.
Attachment #419996 - Attachment is obsolete: true
Attachment #420008 - Flags: review?(LpSolit)
Attachment #419996 - Flags: review?(LpSolit)

Comment 8

8 years ago
Comment on attachment 420008 [details] [diff] [review]
patch - v2

Those need to be email-filtered, no?
(Assignee)

Comment 9

8 years ago
(In reply to comment #8)
> (From update of attachment 420008 [details] [diff] [review])
> Those need to be email-filtered, no?

I don't think it needs to be, no, as Util::email_filter() just does the same thing that the buglist.cgi does earlier:
        if (!Bugzilla->user->id) {
             $sql = $dbh->sql_string_until($sql, $dbh->quote('@'));
        }

Is there some other use case of which I should be aware that would apply here?
(Assignee)

Comment 10

8 years ago
(In reply to comment #9)
> I don't think it needs to be, no, as Util::email_filter() just does the same
> thing that the buglist.cgi does earlier:

s/the/this/

Comment 11

8 years ago
(In reply to comment #9)
> Is there some other use case of which I should be aware that would apply here?

  Ah, no, that handles it. That should be fine. :-)

Comment 12

8 years ago
Comment on attachment 420008 [details] [diff] [review]
patch - v2

r=Lpsolit
Attachment #420008 - Flags: review?(LpSolit) → review+

Comment 13

8 years ago
You will have to fix the bitrot for 3.4. You use so many context lines that you catch unrelated changes.
Flags: approval3.6+
Flags: approval3.4+
Flags: approval+
Target Milestone: --- → Bugzilla 3.4
(Assignee)

Comment 14

8 years ago
Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/trunk/                       
modified buglist.cgi
modified template/en/default/list/list.atom.tmpl
Committed revision 7033.

Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/3.6/                         
modified buglist.cgi
modified template/en/default/list/list.atom.tmpl
Committed revision 7005.

Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/3.4/                         
modified buglist.cgi
modified template/en/default/list/list.atom.tmpl
Committed revision 6732.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.