Open Bug 582919 Opened 14 years ago Updated 12 years ago

user matching should not be processed if the reset checkbox is checked

Categories

(Bugzilla :: Creating/Changing Bugs, defect)

Product:
Bugzilla
Component:
Creating/Changing Bugs
Version:
3.6.1
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

People

(Reporter: timeless, Unassigned)

Details

steps: 0. enable javascript for bugzilla 1. load bug 580705 2. change the assignee to 't' 3. change the product from whatever to bugzilla 4. ensure that the 'reset assignee' checkbox is checked 5. click submit actual results: Bugzilla was unable to make any match at all for one or more of the names and/or email addresses you entered on the previous page. Please go back and try other names or email addresses. Assignee: t was too short for substring match (minimum 3 characters) expected results: Verify Version, Component, Target Milestone You are moving the bug(s) to the product Bugzilla, and the version, component, and/or target milestone fields are no longer correct. Please set the correct version, component, and target milestone now: Version: Component: Target Milestone: Verify Bug Group
pyrzak, I think that when "Reset Assignee/QA contact to default" is checked, the assignee/QA contact text field should be disabled, and only become editable when the checkbox is unchecked. This would fix this problem I think. What do you think?
URL: show_bug.cgi?id=580705
Severity: normal → minor
OS: Mac OS X → All
Hardware: x86 → All
Version: 3.7.2 → 3.6.1
The only problem with this is sometimes the checkbox gets checked without the user noticing it (when you change component) and then they might not realize it. I think the right thing to do is put a check on the back end to ignore the field if that checkbox is checked. So I would think the right fix is to fix it in process_bug.cgi not in the UI. But disabling the checkbox might be an easier fix.
Disabling the checkbox?? How do you reset the default assignee then?
oh, sorry i meant disabling the textbox.
Note however that we've had this behavior for many years now and nobody has before filed a bug (meaning that no significant part of the userbase has run into the problem) so it's not a very high-priority issue.
You need to log in before you can comment on or make changes to this bug.