flag remains set but inaccessible, when product changes

RESOLVED FIXED in Bugzilla 2.18

Status

()

defect
RESOLVED FIXED
16 years ago
7 years ago

People

(Reporter: michaell+bmo, Assigned: mkanat)

Tracking

unspecified
Bugzilla 2.18
Dependency tree / graph
Bug Flags:
approval +
blocking2.18 +

Details

()

Attachments

(1 attachment)

b.m.o. bug 227727 was filed on the Firebird product, and the blocking0.8? flag
was set.  The bug was then reassigned to the Browser product.  It still has the
blocking0.8? flag set, and so shows up in queries, but it's not possible to
change the flag to blocking0.8- (without changing the product back, changing the
flag, and changing the product again).

Flags which don't apply to the new product should be cleared when the product is
changed (or alternatively, set flags should continue to show even after the
product changes, but that doesn't seem like the way to go to me)
Blocks: rt-clean-up
I understand the SQL pretty well from fixing bug 228917, now, and having
hours-long discussions with Matty about it. I could probably take this. I figure
that you've already got more Bugzilla bugs assigned to you than anybody else,
myk. If you want it, though, feel free to take it back.

-M
Assignee: myk → mkanat
OS: Windows 2000 → All
Hardware: PC → All
You are welcome to it. :-)
I'm on it. -M
Status: NEW → ASSIGNED
Um, bug 232705 may explain this...? -M
Oh, no, bug 232705 isn't related. That takes a type_id, and we're talking about
a single bug_id, here. -M
Posted patch Minimal fixSplinter Review
I believe that this is the minimal fix needed for this code to work. I'm not
sure *what* this code was doing before -- I certainly hope that random flags
weren't disappearing. :-)

I've tested this, a bit. The SQL so far seems to return the correct results and
to clear flags correctly. Anybody care to test it further? I'll test it more
later, if I get some time.

-M
Comment on attachment 140287 [details] [diff] [review]
Minimal fix

My testing shows this to be correct, if unwieldy and strange.

bbaetz, I recall that you actually understood this code, last time we talked
about it... I think... :-)
Attachment #140287 - Flags: review?(bbaetz)
Comment on attachment 140287 [details] [diff] [review]
Minimal fix

Yeah, this looks right. Myk, do you want to double check this?
Attachment #140287 - Flags: review?(myk)
Attachment #140287 - Flags: review?(bbaetz)
Attachment #140287 - Flags: review+
Flags: blocking2.18?
Flags: approval?
Flags: blocking2.18? → blocking2.18+
Target Milestone: --- → Bugzilla 2.18
this is still waiting for myk's review.  he said on irc yesterday he hadn't got
to it yet.
Flags: approval?
Comment on attachment 140287 [details] [diff] [review]
Minimal fix

Looks good, works right. r=myk
Attachment #140287 - Flags: review?(myk)
Flags: approval+
Checking in Bugzilla/Flag.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Flag.pm,v  <--  Flag.pm
new revision: 1.17; previous revision: 1.16
done
Status: ASSIGNED → RESOLVED
Closed: 16 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.