177435 - exact match on assignee fails with user matching

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, defect)

Description

[Dave Miller [:justdave]]

See the attached URL on bugzilla-tip on landfill.

Make any change to that bug and commit.  You'll get the following error:

Assignee:   [e-mail]  did not match anything

a) I didn't change the assignee.
b) it better match because it was prefilled on the form already when I loaded it.

Comment 1

[Dave Miller [:justdave]]

Oh, and the usermatchtype param is set to "search" rather than "wildcard"

Comment 2

[Joel Peshkin]

The key item here is that the user's account is disabled.  How would we like to
handle this?  Should exact matches include disabled accounts and the rest not?



mysql> select login_name, realname, disabledtext from profiles where login_name
 like '%bluemartini%';
+----------------------+----------------+---------------------------+
| login_name           | realname       | disabledtext              |
+----------------------+----------------+---------------------------+
| [e-mail] | Chris Yeh      | No longer at this address |
| [e-mail] | Tara Hernandez |                           |
| [e-mail] | NULL           |                           |
| [e-mail]  | Tom Jones      |                           |
+----------------------+----------------+---------------------------+
4 rows in set (0.01 sec)

Comment 3

[Dave Miller [:justdave]]

ok, the disabled thing makes sense.  I'd prefer not to match disabled accounts.

On the other hand, I shouldn't be forced to changed something that was already
on the bug before I touched it.  That's the main problem here...  I didn't check
the box to reassign the bug, so it shouldn't be doing anything with the assignee
address.  QA Contact would be a little harder to detect...

Comment 4

[Joel Peshkin]

OK, so the proposal is as follows...

An exact match should work even for a disabled account within the
wildcard/substring matching code.  This gets us back to the behavior we would
have had without the matching code.  Then, process_bug can decide if the
disabled account is a valid choice.

Comment 5

[Dave Miller [:justdave]]

right, and substring/wildcard matches would continue to match only active
accounts, but an exact match could still match a disabled account.

Comment 6

[Dave Miller [:justdave]]

of course, there's people like timeless, that have an email address in the
realname field that happens to also be another account.

So it should still present any available choices if there's more than one...

IF you're entering something new.  If the address was already on the page it
should use what was there.  Maybe the fields that you can't tell if they're
changed or not need to include a list of user-ids of the users already filled in
on them as a hidden field, and if the user id matches the name that's in that
field then continue using it without doing a match lookup of any kind, and only
do match lookups on newly-entered addresses.

Comment 7

[Joel Peshkin]

That is the crux of the wildcards versus substring debate.  not_erik implemented
both.  Using the wildcards without enabling the substring match solves this
problem, but requires more technical users.

My personal preference is to use wildcards explicitly when you want them and not
doing a substring search, so that is the way that my sites are being set up.  

I'm open to suggestion on this, but changing this to make it continue searching
even if it gets an exact match would be a big change that I would have
difficulty  supporting.

Comment 8

[Erik Stambaugh]

Attachment: No longer tests to see if a login is disabled on exact matches

This one-line patch stops disabled user checking on exact matches, which should
address the stated problem on this bug.

re: comment 6

> of course, there's people like timeless, that have an email address in the
> realname field that happens to also be another account.
>
> So it should still present any available choices if there's more than one...

Exact matches preempt substring matches, and only match against the login name,
so entering the email address will have the same effect it did before, and if
someone wishes to force a search, they can always wrap it in asterisks.


re: comment 7

> That is the crux of the wildcards versus substring debate.  not_erik
> implemented both.  Using the wildcards without enabling the substring match
> solves this problem, but requires more technical users.

I would be willing to sit and argue about what kind of technical expertise it
requires to understand what '*' does.  But not here.
 

> I'm open to suggestion on this, but changing this to make it continue
> searching even if it gets an exact match would be a big change that I would
> have difficulty  supporting.

Trouble is, when you do that you may as well not test for an exact match in the
first place.

If we're concerned about someone having an email address that's a substring of
someone else's address, and a person tries searching for the longer address by
unwittingly using ther shorter address, getting the wrong person, that's (a)
highly unlikely, and (b) the reason I made the confirmation screen an option.

Comment 9

[Myk Melez [:myk] [@mykmelez]]

>If we're concerned about someone having an email address that's a substring of
>someone else's address, and a person tries searching for the longer address by
>unwittingly using ther shorter address, getting the wrong person, that's (a)
>highly unlikely, and (b) the reason I made the confirmation screen an option.

and (c) all such mistakes can be undone, so not only should Bugzilla continue
assume an exact match is correct, it also doesn't need a confirmation screen,
because it will almost always do what people want and will always provide a way
for them to correct it.

Comment 10

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 104776 [details] [diff] [review]
No longer tests to see if a login is disabled on exact matches

Works, looks good. r=myk, check it in

Comment 11

[Joel Peshkin]

Comment on attachment 104776 [details] [diff] [review]
No longer tests to see if a login is disabled on exact matches

2xr=joel

Comment 12

[Joel Peshkin]

Checking in Bugzilla/User.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/User.pm,v  <--  User.pm
new revision: 1.5; previous revision: 1.4
done

Comment 13

[Dave Miller [:justdave]]

fixing target