How does the username matching thingy work?
-
Continuing the discussion from The Official "Likes" Thread:
Except it clearly isn't - because it's matched Husky from 'Albertoni' ahead of AlexMedia (which has it in both the username and display name)... which means if it is doing it that way, it's doing it that way in a case sensitive fashion.
UserSearch.new(term, topic_id: topic_id, searching_user: current_user)
class UserSearch def initialize(term, opts={}) @term = term @term_like = "#{term.downcase}%" @topic_id = opts[:topic_id] @searching_user = opts[:searching_user] @limit = opts[:limit] || 20 end def search users = User.order(User.sql_fragment("CASE WHEN username_lower = ? THEN 0 ELSE 1 END ASC", @term.downcase)) if @term.present? if SiteSetting.enable_names? users = users.where("username_lower LIKE :term_like OR TO_TSVECTOR('simple', name) @@ TO_TSQUERY('simple', REGEXP_REPLACE( REGEXP_REPLACE( CAST(PLAINTO_TSQUERY(:term) AS TEXT) ,'\''(?: |$)', ':*''', 'g'), '''', '', 'g') )", term: @term, term_like: @term_like) else users = users.where("username_lower LIKE :term_like", term_like: @term_like) end end if @topic_id users = users.joins(User.sql_fragment("LEFT JOIN (SELECT DISTINCT p.user_id FROM POSTS p WHERE topic_id = ?) s ON s.user_id = users.id", @topic_id)) .order("CASE WHEN s.user_id IS NULL THEN 0 ELSE 1 END DESC") end unless @searching_user && @searching_user.staff? users = users.not_suspended end users.order("CASE WHEN last_seen_at IS NULL THEN 0 ELSE 1 END DESC, last_seen_at DESC, username ASC") .limit(@limit) end end
So, the last fallback is last_seen, I guess we could fallback to prolific posters, not sure.
-
The issue is it (generally) picks the right (ish) person, but then there's some type of reload happening when you hit tab or enter, and it picks a completely different person than the one you had selected from typing.
-
I bet its the local cache, maybe it need to flush it when a new post comes in. The participants in the topic grow so the cache can be way off.
-
Just, a general curiosity:
Why not just simplify your life and check for @sam% instead of the crazy shit you're doing right now? People generally know the starting letters for the people they want, and as it prompts them can find more right letters.
where username like :term and user_suspended = false and user_banned = false
-
Prioritizing people on the current topic is very much desired and by design. But... we really should be prioritizing username matches over full name matches, that looks like a bug to me.
-
I feel like people currently 'in topic' is less important than 'active on site'
-
And somehow fix the "matches" that don't match either. Can no longer repro, but last night got "sam" as a match for "@N".
Edit: I was replying specifically to this:
we really should be prioritizing username matches over full name matches, that looks like a bug to me.
-
Pretty sure that's the actual bug we're talking about - which is probably related to the recent list.
-
probably related to the recent list
I ran into that in the "likes" thread, and I'm reasonably sure @sam wasn't a recent contributor to that topic.
-
&& @searching_user.staff?
I suspect staff can be summoned from anywhere. (Not specifically from the code given by Sam, but in context, I think there's more there.
-
And that's kind of my point... Discourse has this idea that sounds wonderful but in practice probably isn't as wonderful as you might think and it ends up being over-engineered.
The thing here is, you're effectively trying to second-guess what the user wants. If the user knows who they're after, they will be typing the first few letters and expecting it to be based on that, not necessarily on any other criteria than name.
Here's the real question: what use case are you shooting for?
To my mind, there are two cases where you're going to be mentioning people. Either they're not in the topic in the first place and you're trying to get them in (in which case the desired solution doesn't work) or they're in the topic already and you're trying to draw attention to something (in which case the desired solution probably doesn't make a lot of difference)
-
To my mind, there are two cases where you're going to be mentioning people. Either they're not in the topic in the first place and you're trying to get them in (in which case the desired solution doesn't work) or they're in the topic already and you're trying to draw attention to something (in which case the desired solution probably doesn't make a lot of difference)
Or you're just trying to annoy them, right @presidentsdaughter?
-
Well, that's sort of an edge variation of the first case. Either way you're still talking about someone who isn't in the topic and therefore automatically on the less-desirable list.
-
I just use it as a magical summoning device.
-
Nope - that code just qualifies the search to non-suspended users.
-
Hence the qualifier in parenthesis.
-
I feel like people currently 'in topic' is less important than 'active on site'
Especially in a certain 2500+ post topic... quite a few of the people "in topic" are definitely not "active on site" anymore.
-
-
-
Wrong one.
-
Or you're just trying to annoy them, right @presidentsdaughter?
I can type @mikeTheLiar on autopilot now.
-
@mikeTheLiar is my new password
-
************ is my new password
Phew, for a minute there I thought hunter2 was your password.
-
While it's clearly well intentioned - that's not how I (and I assume a lot of other people too) expected it to work.
Filed under: Someone's doing it wrong, Discoverability is overrated anyway
-
That's kind of the problem, though. The road of good intentions is paved with all kinds of failure. But if the best will in the world tries to second-guess what a user wants to do, it's guaranteed to be wrong at least 50% of the time.
-
I think the HUGE objection here is that there is a bug where the wrong @ is sometimes selected.
I really need to repro that and fix.
name priority can drop as well, will fix that.
-
The priority thingy is almost certainly part of the overall problem that causes the wrong @-mention in the first place.
-
the wrong @-mention in the first place
not following, people are complaining that name 1 is highlighted and name 2 gets selected on enter/tab... that is super severe and egregious.
-
It's not just 'name 1 is highlighted and name 2 gets selected', though that is the most common case.
There's the separate issue when you have someone like me that can physically out-type it to the point where the cursor is already after a newline before the response has come back, which throws it off.
Then there's the case where some of the suggestions are flat out weird. Did I mention that some of the suggestions I get for
@coding
do not contain@coding
? In fact, if I type@coding
, logically I should get only one result - for the one that actually begins with 'coding'.Instead it's doing stemming because I get 6 matches that contain 'code'. For me,
@coding
returns codinghorror, CodeClown, CodeSimian, Butterfly_Coder, CodeNinja, CodeWhisperer in that order. With the exception of Jeff, all the others have the same display name as username, so it's not matching on any other criteria or anything.And that doesn't account for the cases where users type in something that simply isn't mentioned - cases of things like
@N
where there isn't an N in either the username or display name.EDIT: Also, the case of prioritising your own name in the list. Why would you want to mention yourself? I could understand that you might select it in the list but to make it the first item by default doesn't sound clever.
-
That stemming point is great, I will get it fixed, I am using a simple tokeniser there ... so weird that it is even stemming. I will also make sure I push "full name" matches to the absolute end.
Plenty of stuff to improve here.
@n
is a big bug, better get that fixed.
-
I wouldn't be surprised if somewhere along the line it's trying to do stemming with just that N. Come to think of it... I just looked at the list, which right here for
@N
isn't even consistent. At times it was me, you, Matches, Jeff (in that order, showing a priority of people in this topic even though you don't have an N in your name), other times I get Maciejasjmj, FILE_NOT_FOUND, DoctorJones, Nexzus, No_1 (in that order), but that makes some kind of sense as they all have N's in things.
-
Sam Saffron from Sidney
-
Not here. The username matcher just has sam / sam. And if it's matching anything other than username/display name for that, it really is wrong.
-
Both cases fixed and deployed, also ordering is saner.
I can also see the timing issue people are complaining about, will try to get a consistent repro.
Filed under: Mission accomplished, I just made it easier to mention bomb people
-
The repro for incorrect list seems to be ...
- Post something
- Wait N minutes
Type @n
Got to nail this down betterer.
This must be client side cache related.
-
It seems Discourse is using the first of two requests:
http://what.thedailywtf.com/users/search/users?term=&topic_id=1397&include_groups=true
http://what.thedailywtf.com/users/search/users?term=n&topic_id=1397&include_groups=trueSmells like a race condition.
-
This should be throttled on the tail end, sounds like another bug.
-
I certainly wasn't waiting minutes for it as a repro.
Yes, it could be a race condition, I'd assume that a search without a term should never actually be sent by the client, and should never be executed on the server?
-
OK, fix is now deployed
-
I get Maciejasjmj, FILE_NOT_FOUND, DoctorJones, Nexzus, No_1 (in that order), but that makes some kind of sense as they all have N's in things.
Except Maciejasjmj, who doesn't have an 'N' in their name.
-
I like that most of your fixes involve you ripping regex's out of your code.
-
@sam looking good!
-
Should we argue alphabetical ordering now?
-
Then you'll get all the inactive accounts first, won't you?
-
Yes he/she/they do/es, the display name begins "We don't need no..." which has Ns in it.
-
Holy crap and christ, they are using DISPLAY NAMES to populate the @UserName?!
-
Well, it certainly appeared that way before. Doesn't seem to be so now though.
-
We match both display name and username, e.g.
typing
@trwtf
will match @arantor because his "name" is "is TRWTF"This is a really common behavior, Slack and GitHub both do this. I don't know why it would be surprising.
-
Just because it's common does not automatically make it good.
-
It is just a fallback, last resort thing. That way @astute suggests @Nagesh which is the only sane thing to do.