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)
Tracking
()
RESOLVED
FIXED
Bugzilla 2.18
People
(Reporter: shane.h.w.travis, Assigned: shane.h.w.travis)
Details
(Keywords: regression)
Attachments
(1 file)
(deleted),
patch
|
justdave
:
review+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•20 years ago
|
||
Should be a pretty trivial review. :)
Attachment #173985 -
Flags: review?
Updated•20 years ago
|
Flags: blocking2.18.1+
Target Milestone: --- → Bugzilla 2.18
Comment 2•20 years ago
|
||
Comment on attachment 173985 [details] [diff] [review]
Code patch for 2.18 and tip
Doh!
Attachment #173985 -
Flags: review? → review+
Comment 3•20 years ago
|
||
For the record, this was caused by the checkin for bug 43600 on 2002 Aug 11.
Flags: approval2.18+
Flags: approval+
Assignee | ||
Comment 4•20 years ago
|
||
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
Comment 5•20 years ago
|
||
- "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.
Description
•