Closed
Bug 46843
Opened 24 years ago
Closed 18 years ago
Bugs with same subject as the last one should warn user
Categories
(Bugzilla :: Creating/Changing Bugs, enhancement, P2)
Tracking
()
People
(Reporter: bugzilla, Unassigned)
References
Details
(Whiteboard: [content:summary])
If a person files a bug and the bug filed just before (one number smaller than the current one) the user should be asked if he really wants to file two bugs with the same subject. This would be a way to eliminate the many duplicates there are filed because of bugzilla being slow or users pressing Commit twize.
doing this would mean instead of doing one sql insert, there would have to be one sql query, one perl compare, and then one sql insert. you have to the lock the tables while you do this too, so that "last bug entered" doesn't change underneath you. i think the performance slowdown of doing this wouldn't be worth it for large installations
Comment 2•24 years ago
|
||
On the other hand, if this is a semi-regular occurrence, this should reduce the size of the database a bit by avoiding duplicate reports, which would probably have a speedup effect on most operations. The lock issue could be dramatically improved by putting the last value in a view, its own table or a parameter somewhere. This would probably tend to get cached on a large installation as well.
Comment 4•24 years ago
|
||
A better way is my proposal for (42946), get the last bug from that user and check if it has the same subject. No need to lock the db.
Reporter | ||
Comment 5•24 years ago
|
||
*** This bug has been marked as a duplicate of 42946 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Comment 6•24 years ago
|
||
Not a dup. This is a possible solution to the problem caused by bug 42946, which is a database lock/timing issue.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 7•24 years ago
|
||
Any reason why we shouldn't just look for another bug report with the same summary? i.e., not just from this user? Is there any reason to have two bugs with the same summary?
Summary: Browser Crashes Summary: Browser Crashes1 Browser Crashes2 ...
Comment 9•24 years ago
|
||
"Browser Crashes" is a very poorly chosen subject line. "Crash when a page contains a <span> inside a <table> before a <tr>" is a better subject line. So: if we find a match, we should say "is this a duplicate? or is your subject line too broad?".
Comment 11•23 years ago
|
||
I once resolved a bug as as duplicate and changed the summary of the still open bug to match the summary of the resolved-dup-bug, because I thought it was better. So there you have an example of two bugs with the same subject. But I agree that when creating a new bug the subject should be unique.
Updated•23 years ago
|
Target Milestone: --- → Bugzilla 2.16
Updated•23 years ago
|
Priority: P3 → P2
Comment 12•23 years ago
|
||
moving
Assignee: tara → myk
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: other → 2.10
Comment 13•23 years ago
|
||
*** Bug 96938 has been marked as a duplicate of this bug. ***
Comment 14•23 years ago
|
||
I like this one, but b.m.o. is busy enough nowadays to warrant us checking the last few bugs.
Comment 15•23 years ago
|
||
The simple solution, then, is to cache the last few subjects in a small table. 10 subjects should be enough. This way, the query is instantaneous. Gerv
Comment 16•23 years ago
|
||
I think it would be far less expensive to just search the main bugs table. When you're searching for only one or two values on a simple equality basis, the searches are really fast. When you're talking about writing and deleting from a cache table every time you submit a bug (which is the other option) the added speed from the short table query is immediately lost in the updates to the short table. SELECT bug_id,short_desc FROM bugs WHERE short_desc='$usersdescription' ORDER BY bug_id
Updated•23 years ago
|
Whiteboard: [content:summary] enter_bug
Comment 17•23 years ago
|
||
Maybe summary changes should trigger this check, too?
Whiteboard: [content:summary] enter_bug → [content:summary]
Comment 18•23 years ago
|
||
We are currently trying to wrap up Bugzilla 2.16. We are now close enough to release time that anything that wasn't already ranked at P1 isn't going to make the cut. Thus this is being retargetted at 2.18. If you strongly disagree with this retargetting, please comment, however, be aware that we only have about 2 weeks left to review and test anything at this point, and we intend to devote this time to the remaining bugs that were designated as release blockers.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
Comment 19•23 years ago
|
||
*** Bug 117871 has been marked as a duplicate of this bug. ***
Comment 20•20 years ago
|
||
Enhancements which don't currently have patches on them which are targetted at 2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. Consideration will be taken for moving items back to 2.18 on a case-by-case basis (but is unlikely for enhancements)
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Comment 21•20 years ago
|
||
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004. Anything flagged enhancement that hasn't already landed is being pushed out. If this bug is otherwise ready to land, we'll handle it on a case-by-case basis, please set the blocking2.20 flag to '?' if you think it qualifies.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Assignee: myk → create-and-change
QA Contact: mattyt-bugzilla → default-qa
Target Milestone: Bugzilla 2.22 → ---
Comment 22•18 years ago
|
||
Bug 42946 has been fixed and prevents a user from reusing twice the same form to enter bugs, either by clicking twice the "Commit" button (or the "Refresh" button), or by clicking the "Back" button and committing the new bug again (with the same bug summary or not). So bug 42946 largely covers what is requested in comment 0 and both cover the same issue. -> dupe! *** This bug has been marked as a duplicate of 42946 ***
Status: NEW → RESOLVED
Closed: 24 years ago → 18 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•