Closed Bug 191085 Opened 22 years ago Closed 22 years ago

process_bug.cgi: FetchSQLData vs. FetchOneColumn and other oddness


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




Bugzilla 2.18


(Reporter: burnus, Assigned: bbaetz)


(Keywords: regression)


(2 files, 2 obsolete files)

I was told that one gets this in process_bug.cgi:
 You tried to change the product field from 1 to ZEDV, but only the owner or
 submitter of the bug, or a sufficiently empowered user, may change that

This seems to be fixed by:
--- process_bug.cgi     28 Nov 2002 10:49:41 -0000      1.172
+++ process_bug.cgi     29 Jan 2003 10:34:33 -0000
@@ -218,7 +218,7 @@
 if ( $::FORM{'id'} ) {
     SendSQL("SELECT name FROM products, bugs " .
             "WHERE = bugs.product_id AND bug_id = $::FORM{'id'}");
-    $::oldproduct = FetchSQLData();
+    $::oldproduct = FetchOneColumn();

Using my test accound (no extra rights at all): If I load a bug and do
absolutely no changes and hit "Submit" I get:
  Changes submitted for bug 42
  Email sent to: no one
  Excluding: (all others [my real account should get all)
This is still the case with this patch and might be related to bug 187861.

(One might change this for consistancy, but it is not needed:
@@ -775,7 +775,7 @@
 # to which the bug is restricted.
 if ( $::FORM{'id'} ) {
     SendSQL("SELECT group_id FROM bug_group_map WHERE bug_id = $::FORM{'id'}");
-    my ($havegroup) = FetchSQLData();
+    my $havegroup = FetchOneColumn();
Bug 187861 is only related to multipart POST; ie only attachment.cgi

Where do you get that message where you shouldn't? I can't repro this.

Waht perl/DBI version?

Those two should be identical...
> Bug 187861 is only related to multipart POST; ie only attachment.cgi
> Where do you get that message where you shouldn't? I can't repro this.
I think I cannot reproduce it in the moment either. Simply ignore that part.

The attachement fixes:
-    $::oldproduct = FetchSQLData();
+    $::oldproduct = FetchOneColumn();

and changes for consitency
-    my ($havegroup) = FetchSQLData();
+    my $havegroup = FetchOneColumn();

If you don't like the latter, ignore that ;-)
Attachment #113023 - Flags: review?(justdave)
Oh, hang on. Bleh, my mistake.

Untested patch coming
Keywords: regression
Priority: -- → P1
Target Milestone: --- → Bugzilla 2.18
Attached patch fix (obsolete) — Splinter Review
The eval I added hid the wantarray-ness from the caller, and so we always got
an array which was then coerced into scalar context - ie the number of

Doing the return directly from within the eval seems to not work, so try this

Can someone pleae verify that this fixes this problem, and that it does not
regress bug 189446?
Attachment #113023 - Attachment is obsolete: true
jussi, please see comment 4. You reported that other bug...
Yes, the problem in bug 189446 comes back when I use this patch.
jussi: What perl version? What if you also localise ->{HandleError} as well?
Attachment #113023 - Flags: review?(justdave)
Re comment 7:

I'm still seeing the bug after adding: 
local Bugzilla->instance->dbh->{HandleError};
perl version is 5.6.1
Jussi. Hmm. With that patch, can you:

a) change _handle_error so taht you can check whether its still being called.
b) Turn on tracing (add a call to ->trace(2, "trace.out") after conncting in
Bugzilla::DB::_connect), and attach that log.

What DBD::mysql version?
a) Yes, _handle_error is called with the modified patch (with HandleError)

Checking for		 DBI (v1.32)   ok: found v1.32
Checking for	  DBD::mysql (v2.1010) ok: found v2.1014
Hmm. Maybe try setting those attribtues on the sth, rather than the dbh?

ie |local $_current_sth->{RaiseError};| ?
Yes, that works!
Attached patch take 2Splinter Review
Disable ->{RaiseError} on the sth, not the dbh.
Attachment #113080 - Attachment is obsolete: true
Comment on attachment 113321 [details] [diff] [review]
take 2

ok, looks sane to me, assuming the intention is to make it ignore the error...
Attachment #113321 - Flags: review+
Flags: approval+
Closed: 22 years ago
Resolution: --- → FIXED
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.