352699 - bug creation time not available on bug creation

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, defect)

Description

[Frédéric Buclin]

Bugzilla::Bug::create() deletes creation_ts before inserting the new bug into the DB for security reasons (prevent making it visible before group bits are set). But when creation_ts is finally inserted into the DB for this new bug, the bug object itself has already been created and will be returned with creation_ts remaining undefined. This makes the creation date to not be displayed on bug creation:

<b>Opened:</b> [% bug.creation_ts FILTER time %]

because bug.creation_ts = undef.

The fix is trivial. Patch coming soon.

Comment 1

[Frédéric Buclin]

Attachment: patch, v1

Comment 2

[Max Kanat-Alexander]

Comment on attachment 238465 [details] [diff] [review]
patch, v1

<mkanat> LpSolit: I'm uncomfortable with the way the creation_ts one is fixed.
<LpSolit> mkanat: why?
<mkanat> LpSolit: I'd like to see Bugzilla::Bug pull creation_ts out of the DB directly, and then have the accessor format it, instead of having the DB format it during construction and perl format it during create().
<mkanat> LpSolit: And I'd like the accessor to just read it directly out of the DB if it's not set yet.

  Since we're not frozen, let's take the time to fix this really well. I've always thought that new() shouldn't be formatting the date, anyhow.

Comment 3

[Frédéric Buclin]

(In reply to comment #2)
> I'd like to see Bugzilla::Bug pull creation_ts out of the DB
> directly, and then have the accessor format it, instead of having the DB format
> it during construction and perl format it during create().

I disagree. The DB should always format date values itself as the date may be stored in a format that perl cannot understand.


> <mkanat> LpSolit: And I'd like the accessor to just read it directly out of the
> DB if it's not set yet.

Well, creation_ts is normally always set on the bug object creation. The only place where it's not is when creating the bug object, because we delay the insertion of creation_ts into the DB for security reasons.

Comment 4

[Max Kanat-Alexander]

(In reply to comment #3)
> I disagree. The DB should always format date values itself as the date may be
> stored in a format that perl cannot understand.

  I'm not so sure about that. Per the ANSI standard, DBs are always supposed to store dates in the same way, and Bugzilla definitely understands that.

  MySQL and PostgreSQL both store dates this way, and we don't currently support any DB that doesn't store dates that way. So let's not worry about a problem we've never actually experienced.

> Well, creation_ts is normally always set on the bug object creation. The only
> place where it's not is when creating the bug object, because we delay the
> insertion of creation_ts into the DB for security reasons.

  Right. I just don't think that it should be formatted on creation, really. Just like deadline shouldn't be formatted on creation. We already use a lot of dates directly out of the DB, like delta_ts.

Comment 5

[Frédéric Buclin]

*** Bug 356976 has been marked as a duplicate of this bug. ***

Comment 6

[Olav Vitters]

Attachment: Patch v2

Do not format $timestamp when updating the bug instance.

Comment 7

[Frédéric Buclin]

Comment on attachment 242936 [details] [diff] [review]
Patch v2

Yeah, post_bug.cgi defines $timestamp as:

my $timestamp = $dbh->selectrow_array(q{SELECT NOW()});

so this has the same effect as querying the DB again. And I checked, bug/comments.html.tmpl does the formatting itself:

 <b>Opened:</b> [% bug.creation_ts FILTER time %]

where FILTER time is:

 time => \&Bugzilla::Util::format_time,

So this fix is correct. r=LpSolit

Comment 8

[Olav Vitters]

Checking in Bug.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Bug.pm,v  <--  Bug.pm
new revision: 1.160; previous revision: 1.159
done