mahara-contributors team mailing list archive

[Aaron Wells <1612481@xxxxxxxxxxxxxxxxxx>]

Hi Dmitri,

It worked for me on the admin page. I'll use [square brackets] to
enclose strings below, to try to avoid confusion when I'm talking about
strings that contain double quotes.

1. Clean install of Mahara
2. Log in as admin
3. Go to Content -> Profile and change my first name to: [Ad min]
4. Go to the Administration -> Extensions -> Search/Internal config page and verify that exact search is on.
5. Go to Administration -> Users -> User search (admin/users/search.php) and search for ["Ad min"]

Result: The admin user shows up in the search results.

I agree that it's still bad usability, though. I think many users would
expect [ad min user] or ["ad min user"] to work, but in fact you have to
enclose the first name and/or last name *by itself* in quote marks,
which I would probably not have thought of doing, and there isn't even a
help bubble on the page to explain that we support the quote mark search
operator.

Currently the behavior is this:

1. PluginSearchInternal::split_query_string() splits the search query
into search terms. Any quote-enclosed strings become a search term. The
remaining non-quoted text is split up by space characters into separate
search terms.

2. PluginSearchInternal::match_user_field_expression() writes a SQL
expression to compare each applicable database field to each search
term.

2a. If exact search is on, it does an exact match: lower(<field>) =
lower(<search term>)

2b. If exact search is off, it does a wildcard match: lower(<field>)
like lower('%<search term>%')

So what Kristina said is not exactly true. An "exact search" for [Jon
Smith] will actually pull up Jon Paul, and Mike Smith. It just excludes
Jonathan Smithson.

That said, it's tricky to come up with a way to support [ad min user]
while still honoring the original exact search use case, which I guess
is roughly "Each part of the search query must be an exact match to a
part of the user's name". I can think of two ideas:

1. Robert's suggestion of adding search terms for all adjacent
combinations of space-separated unquoted elements in the query. So [a b
c] would yield these search terms: [a], [b], [c], [a b], [b c], and [a b
c]. The downside is that the number of search terms scales geometrically
with the number of spaces in the search query. Also, it may be tricky to
handle partly-quoted search queries such as [a "b c" d], although that's
a corner case.

2. Compare the entire search query against a concatenation of the
firstname and lastname fields. So the SQL would be something like
"u.firstname = <query> || u.lastname = <query> || u.firstname ||
u.lastname = <query> || u.lastname || u.firstname = <query>". (For
quoted search terms, we could just remove the quote marks.) This would
be hard to fit into the existing code, though, which handles each search
field quite separately.

-- 
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1612481

Title:
  "Exact user search" doesn't work intuitively with names containing
  spaces

Status in Mahara:
  Confirmed

Bug description:
  Steps to replicate:

  Make sure that the setting "Exact user searches" set to Yes on
  admin/extensions/pluginconfig.php?plugintype=search&pluginname=internal

  Create a user with multi word lastname, e.g Bla Bla Bla
  Navigate to /admin/users/search.php
  Type this in search form:

   Bla Bla Bla

  Expected result: User is in the search results, because you've typed their exact last name.
  Actual result: User is not in the search results

  Workaround: Enclose the firstname and/or lastname *by itself* in
  double quotes. e.g., for the user Aaron von Wells, search for:

    Aaron "von Wells"

To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1612481/+subscriptions