derived from editusers.cgi

*** Bug 91475 has been marked as a duplicate of this bug. ***

-> timeless

No, really this time... -> timeless

We could offer this as option, when a cc address is rejected.

yeah maybe... but for that i've been thinking of a slightly different algorithm. something along the lines of [ti]?[tim][ime][mel][ele][les][ess][ss]? @[be]?[bem][ema][mai][ail][il.][l.o][.or][org][rg]? + search of realname using some split of account w/ sorting and scoring based on closeness to original string. ^this semicomplicated algorithm could be implemented later, while a basic fallback of a link to find users on failure could be implemented immediately after landing findusers.

Comment on attachment 21265 [details] based on -r1.17 editusers.cgi text/perl confuses Mozilla. Please don't use bogus MIME types. Gerv

Review comments: Any new CGI files should be templatised. It should contain a proper MPL Exhibit A. The code should show the first 10 hits when there are too many. It should exclude disabled accounts. We should abstract out the common code with editusers.cgi, or add this ability to that script and rename it. We should do fuzzy matching on no hits using SQL LIKE. Gerv

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.

Comment on attachment 21265 [details] based on -r1.17 editusers.cgi Marking needs-work per Gerv's comment 9. Is the point of this bug to separate search logic from editusers or to allow more complex searches or what? Is the findusers going to be admin only (as the component would indicate) or no (as some odd logic would say)?

Some code in the Request Tracker (bug 98801) does something very similar to this. This code should probably ultimately be broken out into a User.pm module.

part of the goal was to allow non blessed users to do searches. I didn't pick the component, this bug predates the bugzilla b.m.o product, and there isn't really a better component, feel free to change it.

If this is aimed at not-only-admins, let's slump this into bugzilla-general then.

*** Bug 168447 has been marked as a duplicate of this bug. ***

> part of the goal was to allow non blessed users to do searches. It would be helpful to just have a UI like "Edit users" (but read-only) for non- admins. Spam isn't a concern for my group since our Bugzilla is internal but if anyone is concerned about spam, there could be a param to enable this.

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.

What is the relation with bug 365079 ?

This appears to have already been implemented in a much cleaner way by virtue of the user autocomplete that now exists in current versions.