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)

Product:
Bugzilla
Component:
Creating/Changing Bugs
Version:
2.10
Type:
enhancement

Tracking

()

Status:
RESOLVED DUPLICATE of bug 42946

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
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.
see also bug 22353.
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.

*** This bug has been marked as a duplicate of 42946 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
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 → ---
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
...
"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?".
sounds reasonable
Status: REOPENED → NEW
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.
Target Milestone: --- → Bugzilla 2.16
Priority: P3 → P2
moving
Assignee: tara → myk
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: other → 2.10
*** Bug 96938 has been marked as a duplicate of this bug. ***
I like this one, but b.m.o. is busy enough nowadays to warrant us checking the
last few bugs.

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
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
Whiteboard: [content:summary] enter_bug
Maybe summary changes should trigger this check, too?
Whiteboard: [content:summary] enter_bug → [content:summary]
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
*** Bug 117871 has been marked as a duplicate of this bug. ***
Severity: normal → enhancement
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
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 → ---
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.