Contacts search form is case sensitive

[almereyda]

When searching for the name of a person whose email address is different or an abbreviation, the entry is not found, despite the substring is present in the first name or last name field.

It could be nice if all string fields were searchable in the contacts list.

[wmnnd]

The search function already includes first name, last name, and email address. If you need more sophisticated filter criteria, you can also use the segments feature.

The search function on the contacts page actually uses the same filtering code as the segments and builds this segment query from the search string:

%{
  "$or" => [
    %{
      "first_name" => %{"$like" => "%#{search}%"}
    },
    %{"last_name" => %{"$like" => "%#{search}%"}},
    %{"email" => %{"$like" => "%#{search}%"}}
  ]
}

[almereyda]

Actually it does, but it is case sensitive. Sorry for not having tested it that far. I just didn't find what I needed and thought the journey to be over.

Search forms in other places nowadays often expose case-insensitive fuzzy globbing to end users, which makes it really simple to skim through entries. E.g. when searching for a person called John, used to such fuzzy search facilities, I would only type 'joh' and search for that instead. Needing an exact match to find a recipient may be harder in international settings, where finding the correct spelling of a name can be a challenge.

It could also be nice if the search form for subscribers was as reactive as the segment editor search. When I only change one character, changes appear instantly there. But this is probably a separate issue.

[wmnnd]

Ah, good catch! I’ve changed it so that ILIKE is used instead of LIKE at the database level for the $like query operator in e7a3a9555d227e0be5665c328c618752c2d735c7.

[wmnnd]

… and fixed in 411c52f :smile:

[almereyda]

Hooray!