User-search WebAPI match anywhere in string instead of just the start

 






 

 


  Review Request #5503
  —
  Created Feb. 18, 2014 and discarded 

 


















 

  

   Information

  





 
 

  mcote
 









 
 

  Review Board
 









 
 

  master
 









 
 

  
 









 
 

  
 






 




 

  

   Reviewers

  





 
 

  reviewboard
 









 
 

  
 






 








 





  


 
 

  
We discussed this a while ago, and I believe we agreed that it's more useful to match username, first_name, and last_name queries anywhere in the string(s) instead of just the beginning.

 








  


 
 

  
All tests pass aside from a few VCS-dependent ones, which are skipped.


I changed the user WebAPI test to search for the middle of the name ("rum" in "grumpy" instead of "gru").  I didn't bother having both searches, since matching in the middle pretty much guarantees matching at the start.

 







 









 





  








 









 






  

 








 














 





 

  

   





 SM





   

   







  

 



 

  


   

   

    
 
smacleod


    
   


  

  

  



    




  1. 
 
    
  
    
   
    Ship It!
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    2. 















  2. 
 
    
  
    
   
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    3. 




  

 
















 





 

  

   




chipx86




   

   





  

 



 

  


   

   

    
 
chipx86


    
   


  

  

  



    




  1. 
 
    
  
    
   
    Can you point me to the original discussion? I don't remember it off-hand.
    

    I'm personally not sure about this change. It doesn't feel natural to me to do sub-string matching. If I search for "an" to try to find "Anna," I don't want "Brian" to show up. It's not at all what I would expect to come up. People don't tend to think in terms of matches in the middle of a name.
    

    Remind me what the use-case is that we're trying to solve here?
    
  
    
 
    

 
    
  


    
 
    
 
      

  


    1. 
 
 
      
 
      
  
 
      
 
      
  
      Steven filled me in. There wasn't really a discussion originally about this that David and I were a part of, which is where my confusion comes form.
      

      Now that I'm caught up, here are my thoughts on it.
      

      I think breaking the matching behavior is going to piss off most of our existing users. I know I certainly knew exactly what keys to press to get my teammates in the past, and if that changed on me and I ended up selecting the wrong people (or couldn't even find them in the results due to thousands of people at the company without typing half the username/full name), I'd be really upset.
      

      The behavior you guys want is pretty Mozilla-specific. Maybe a few other companies do something similar, but it's not something that's going to be beneficial to most anybody else.
      

      So I think we want another hook or something here. Maybe a UserQueryFilterHook. If there are any registered hooks, they could provide the search logic, and if not, we default to the old code (containing the username and full name prefix matching). It's a bit of a specialized hook, but who knows, maybe it'll be useful in ways we haven't thought of yet.
      

      Thoughts on that design?
      
 
      

      2. 



    2. 
 
 
      
 
      
  
 
      
 
      
  
      Hm, seems it was all on IRC between smacleod and me.  Now that I review the logs, I'm not sure if smacleod talked to anyone else about it, but he thought it sounded like a good idea.
      

      The use case is from Mozilla's Bugzilla system.  Since usernames == email on BMO (for now, at least), people change their full names to include their IRC nicks prefaced by a colon, e.g. "Mark Côté (:mcote)".  This allows you to easily find someone on Bugzilla by their nick, since there are many users, employees sometimes use different Bugzilla emails than their official emails, and sometimes all you know of a contributor is their IRC nick.
      

      I get your point, although if autosuggest results are sorted, at least it would be really easy to find matches at the beginning of the first name; they'd all be at the top.  I guess that's not true when searching by last name, though.
      

      Admittedly, the :irc_nick convention is essentially a hack to get around the fact that usernames are email addresses on BMO.  This may be changing, but I think the convention will be around for some time, and it's essential to us, since it's ingrained in our work flow.  At the very least, we'd have to have some way to override it in our extension.
      
 
      

      3. 



    3. 
 
 
      
 
      
  
 
      
 
      
  
      That sounds fine, and yeah it probably is pretty specific to us.  How would this work?  Pass search_q (and, I guess, the request object) to a function which optionally returns a django.db.models.Q object?
      
 
      

      4. 


 
    


    

 
    

    2. 















  2. 
 
    
  
    
   
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    3. 




  

 
















 



 

  

   





 MC





   

   

  

 



 

  


   

   

    
 Review request changed

    
   


  

  

  







  

   

    Status:
   

   


    Discarded

   

  




  

   

    Change Summary:
   

   

    
Discarding this review in lieu of a hook function (submitted as review 5635).