122922 - (bz-bugwrite) Use Bug.pm to write changes and new bugs to the database

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, enhancement, P1)

Description

[John Vandenberg]

This version of Bug.pm provides a useful Bugzilla API, although it suffers from
the globals of Bugzilla.  Given the extent to which this branch improves Bug.pm,
I would be great if only the current functionality of Bug.pm is required to be
tested, the rest then able to be tested and fixed as developers find the need.

Comment 1

[John Vandenberg]

Attachment: patch to use allow previously blank fields

Comment 2

[John Vandenberg]

Attachment: testcase, requires editing

Comment 3

[Bradley Baetz (:bbaetz)]

Comment on attachment 67384 [details] [diff] [review]
patch to use allow previously blank fields

Can we get a patch against current CVS?

Also, I'd like to know that someone plans on using this before hand, so that it
doesn'tsuffer bitrot.

Comment 4

[Dave Miller [:justdave]]

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

Comment 5

[Gervase Markham [:gerv]]

Is it fair to say that this branch is now so old that nothing can be salvaged
which it wouldn't be easier to reimplement?

Gerv

Comment 6

[Dave Miller [:justdave]]

Believe it or not, it's not.  There's a ton of useful stuff in here that never
made it on the trunk.  Although I'm sure we'll do it better, there's code in
here we can certainly take :)

Comment 7

[Bradley Baetz (:bbaetz)]

Theres lots of concepts, although I'm not sure how much code; I've rewroked
Bug.pm a fair bit in the mean time.

Comment 8

[Gervase Markham [:gerv]]

Dave said:
> There's a ton of useful stuff in here that never made it on the trunk.

Can you be more specific?

Gerv

Comment 9

[Dave Miller [:justdave]]

All 2.18 bugs that haven't been touched in over 60 days and aren't flagged as
blockers are getting pushed out to 2.20

Comment 10

[Dave Miller [:justdave]]

Changing bug to reflect the current scope of what we want.  Not sure how much is
on that branch that'll actually be usable anymore.  I'm fairly certain the API
it was using isn't what we want.

What needs to be done here is to get all of this "changing the bug" code from
post_bug, process_bug, and attachment.cgi, and get it implemented as methods of
Bug.pm, and allow Bug.pm to write back to the database, including access
control, so that the Bugzilla::Bug object itself enforces who is allowed to make
what changes (the CGI would then look at return codes or exception objects or
something along those lines to decide if it needed to throw an error).  The Bug
object should also handle updates to the activity records, so that code is
centralized (currently, activity table updates are duplicated in a few different
places (attachment.cgi comes to mind)).  This would also greatly simplify life
for the inbound email code, which currently duplicates a LOT of code from
post_bug and process_bug.

Comment 11

[Max Kanat-Alexander]

I think that in order to allow mass-updates of bugs using Bug objects, there
should be an "fail_on_error" param when you create a bug -- if "fail_on_error"
is true, then we ThrowUserError for errors. If "fail_on_error" is false, we pass
back an error status. That way, not every caller has to check if we failed, only
the mass-read or mass-update callers.

Comment 12

[Frédéric Buclin]

The trunk is now frozen to prepare Bugzilla 2.22. Enhancement bugs are retargetted to 2.24.

Comment 13

[Max Kanat-Alexander]

The rest of this bug will be done in 4.0. Bug 367914 may still be a 3.2 blocker, though.

Comment 14

[Max Kanat-Alexander]

This is now done. :-)