Closed Bug 281845 Opened 20 years ago Closed 20 years ago

Possible to delete users who are initial QA contacts

Categories

(Bugzilla :: User Accounts, defect)

2.17.1
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Bugzilla 2.18

People

(Reporter: shane.h.w.travis, Assigned: shane.h.w.travis)

Details

(Keywords: regression)

Attachments

(1 file)

Under Bugzilla 2.16, it was not possible to delete a user who was either an Initial QA Contact, or an Initial Owner. Under 2.18 (as of 2.17.1, actually) this changed to Initial Owner only. This appears to be an unintentional regression brought on by the landing of bug 43600; the patch author mistakenly used components.id here instead of components.product_id. Given that it's been this way for three years now, and nobody else seems to have noticed, I'm guessing it hasn't terribly inconvenienced many people... :) Patch to follow.
Attached patch Code patch for 2.18 and tip (deleted) — Splinter Review
Should be a pretty trivial review. :)
Attachment #173985 - Flags: review?
Flags: blocking2.18.1+
Target Milestone: --- → Bugzilla 2.18
Comment on attachment 173985 [details] [diff] [review] Code patch for 2.18 and tip Doh!
Attachment #173985 - Flags: review? → review+
For the record, this was caused by the checkin for bug 43600 on 2002 Aug 11.
Flags: approval2.18+
Flags: approval+
2.18: Checking in editusers.cgi; /cvsroot/mozilla/webtools/bugzilla/editusers.cgi,v <-- editusers.cgi new revision: 1.61.2.6; previous revision: 1.61.2.5 done Tip: Checking in editusers.cgi; /cvsroot/mozilla/webtools/bugzilla/editusers.cgi,v <-- editusers.cgi new revision: 1.74; previous revision: 1.73 done
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
- "WHERE products.id = components.id " . + "WHERE products.id = components.product_id " . Hmmm... I can't see any legitimate reason for comparing one ID field with an ID field from a different table as was mistakenly done here. I don't suppose there's any way to make the DB IDs 'type-safe', so that each tables's primary key would be a different data type, but keys referencing that key would be the same data type? Perhaps this could be configured in a way to cause a DB error (or at least warning) from the query leading to this bug. (obviously this would be a separate RFE if this is remotely feasible)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: