Currently, using spaces in the assignee will include the spaces in the search, to help narrow it down to a specific person. However, doing the same exact search in the CC field (with spaces) will search for each "word" separately, and can often cause the "too short" error. They should both use the same algorithm, and include the space in the search, since commas are used to indicate multiple e-mail addresses. (Incidentally, and this is probably a separate bug, but receiving the "too short" error prevents the match form from being submitted, even if there are other valid matches that were done.)
Yeah, this sounds like a reasonable behavior change to me.
Target Milestone: --- → Bugzilla 4.0
No, you shouldn't include spaces as they are not legal in email addresses. And some people (me?) separate user accounts with spaces. But I think this bug is a dupe.
Severity: normal → minor
(In reply to comment #2) > No, you shouldn't include spaces as they are not legal in email addresses. And > some people (me?) separate user accounts with spaces. Both fields search the real names of users, in addition to the e-mail addresses, so there's no reason to exclude full searches from one and not the other. I think it seems reasonable to disrupt some people's workflow in order to make room for a logical increase in functionality—especially one that is already half-implemented. > But I think this bug is a dupe. My brief search didn't turn up anything related to this, but I may have missed something.
Version: unspecified → 3.2.3
Not a bug and not limited to bug editing. If you read the source code correctly, you will notice that all user fields call the same code in the backend. The difference is that the assignee can only be a single user, so we don't do any parsing of the string passed by the user, while the CC field can accept several users at once and we split the string on commas and spaces.
Assignee: create-and-change → user-accounts
Severity: minor → enhancement
Component: Creating/Changing Bugs → User Accounts
We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved. I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.
Target Milestone: Bugzilla 4.4 → ---
You need to log in before you can comment on or make changes to this bug.