[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:


	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:

Competent, Friendly Bugzilla and Perl Services. Everything Else, too.

More information about the developers mailing list