[Fwd: Re: [scmbug-users] Error on changing status of bugs with Bugzilla 3.4.x]
Max Kanat-Alexander
mkanat at bugzilla.org
Sat Apr 17 01:27:41 UTC 2010
On 04/16/2010 05:55 AM, Yavor Nikolov wrote:
> Well, maybe that's closest to what Kristis had in mind. But seems too
> much bloating to me if we wrap each call to Bugzilla in eval and check
> each time for errors (maybe not each function in Bugzilla is throwing
> errors but for safety I'm assuming that it might throw one /some day in
> some release/).
It's not bloat. As you can see by my comments below, only one statement
in your code needed eval{}.
Functions that don't throw errors now probably won't start throwing
errors in the future.
> OK. I found that Object::update has start/commit transaction block but
> there are some other actions in Bug::update after that which I'm not
> sure about (activity log, duplicates, etc, ...)... Looking at
> process_bug.cgi I felt safer to wrap this in transaction block. (I'm not
> sure what isolation level is being used).
You don't need to wrap it in a transaction.
> - imagine we have some bulk activity - adding comments, updating
> status, resolution, etc. And same error message (e.g. invalid bug id)
> may come out from different places. We may want to know if it's a
> problem with duplicate bug id (DUPLICATE OF); or the main bug.
The error message from Bugzilla will tell you that. If it doesn't, you
can file a bug requesting that Bugzilla throw a clearer error message.
> - Or we may want to distinguish between more common user errors (bad
> argument provided: resolution status name, bug id, username, etc);
> security error; CodeError; or a more fatal one (database, etc.)
When you have a specific instance of wanting to do this, there will
most likely be a way to handle it.
> Good point (damn Perl... :-)) I got false impression that these have
> been designed as part of language... But really that seems more like a
> wish for future: http://dev.perl.org/perl6/rfc/63.pod,
Perl 6 is not the same language as Perl 5. (Confusing, I know.)
> The point is that we want to see same result as if the committing user
> itself has updated the bug.
Okay. Starting with Bugzilla 3.6, you could also write an Extension
that would help you do what you want.
> But maybe we could make that work if it's
> possible to log-in as user with sudoer user and impersonate to someone
> later - is it?
It might be possible, although sudoers can't impersonate admins. It's
not possible via the WebService, currently, though, at all.
> At first glimpse I can't see how to call
> Bugzilla::BugMail::Send( $bugid, $vars ); either.
You would never call that yourself in the WebService--it does it for you.
> I hope there is a better
> object-oriented approach (i.e. proxy to look like just as the real
> object) to call web service methods in Perl than passing around strings
The WebService is documented here:
http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService.html
It is not SOAP, if that is what you're asking. It is instead a simple
series of functions that perform specific actions. Depending on what
language you're using, there are various libraries that wrap Bugzilla's
WebService API. For Perl there's BZ::Client:
http://search.cpan.org/dist/BZ-Client/
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
More information about the developers
mailing list