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

NEW
Unassigned

Status

()

Bugzilla
Creating/Changing Bugs
--
minor
8 years ago
5 years ago

People

(Reporter: timeless, Unassigned)

Tracking

Details

(Reporter)

Description

8 years ago
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

Comment 1

8 years ago
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?
Severity: normal → minor
OS: Mac OS X → All
Hardware: x86 → All
Version: 3.7.2 → 3.6.1

Comment 2

8 years ago
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.

Comment 3

8 years ago
Disabling the checkbox?? How do you reset the default assignee then?

Comment 4

8 years ago
oh, sorry i meant disabling the textbox.

Comment 5

8 years ago
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.