Some fields should not be displayed in bugmail for new bugs

RESOLVED FIXED in Bugzilla 4.0

Status

()

Bugzilla
Email Notifications
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: Frédéric Buclin, Assigned: Frédéric Buclin)

Tracking

({regression})

3.7.2
Bugzilla 4.0
regression
Bug Flags:
approval +
approval4.0 +
blocking4.0 +

Details

Attachments

(1 attachment)

(Assignee)

Description

8 years ago
Creation date: 2010.07.30 18:55
 Last changed date: 2010-07-30 18:55:38
          Deadline: 1970-01-01

These fields should not be displayed in bugmail we get for new bugs. The creation and last changed dates are totally useless as the bug just got created, and the deadline should not be displayed either when not set (no idea why it falls back to 1970 when left empty).

This is a regression in 4.0. Bugzilla 3.6.1 doesn't have these problems. Note that in_new_bugmail => 1 has been added by bug 289357 in Bugzilla 3.0 (for some obscure reason).

No idea what changed between 3.6 and 4.0 in the email notification area which triggered these regressions.
Flags: blocking4.0?

Comment 1

8 years ago
The Deadline thing is almost certainly Pg-specific.

But the other fields should not appear, I agree.

Updated

8 years ago
Flags: blocking4.0? → blocking4.0+
(Assignee)

Comment 2

8 years ago
(In reply to comment #1)
> The Deadline thing is almost certainly Pg-specific.

No, this happens on MySQL too. I found the culprit. In BugMail.pm, we have:

 elsif ($name eq 'deadline') {
     $value = time2str("%Y-%m-%d", str2time($value));

If $value is empty, time2str() returns 1970-01-01. It is also responsible for all these warnings in the web server error log:

Use of uninitialized value $time in localtime at /opt/perl/lib/site_perl/5.12.1/Date/Format.pm line 121.
(Assignee)

Comment 3

8 years ago
Created attachment 461980 [details] [diff] [review]
patch, v1

This fixes 2 things:
- creation_ts and delta_ts are no longer in_new_bugmail
- don't format estimated_time nor deadline if not set.

$bug->estimated_time returns "0.00", and so "return unless $value" sees $value as being true instead of wrong, which is why I force it to be 0 when not set, so that this field is correctly skipped.
Assignee: email-notifications → LpSolit
Status: NEW → ASSIGNED
Attachment #461980 - Flags: review?(mkanat)
(Assignee)

Comment 4

8 years ago
At least for deadline, this is a regression due to bug 395451.
Depends on: 395451

Comment 5

8 years ago
Comment on attachment 461980 [details] [diff] [review]
patch, v1

Ah, very cool. :-) Looks good. :-)

It would be nice to reverse things to "($value == 0)" instead, though, on checkin. (I think it's usually clearer to have positive booleans.)
Attachment #461980 - Flags: review?(mkanat) → review+

Updated

8 years ago
Flags: approval4.0+
Flags: approval+
(Assignee)

Comment 6

8 years ago
Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/trunk/
modified Bugzilla/BugMail.pm
modified Bugzilla/Field.pm
Committed revision 7419.

Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/4.0/
modified Bugzilla/BugMail.pm
modified Bugzilla/Field.pm
Committed revision 7362.
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.