No results returned when filtering by multi-word value

Ah, yes, that's actually deliberate, but of course still nonsense. At least 90% of people won't expect this behavior, but rather want a "normal" search in that field when they set a filter.
We actually want to get rid of this in Drupal 8 (cf. #2044393: Changes in search query functionality), but since the behavior isn't really documented/specified/required anywhere, we can probably just fix it in Drupal 7, too.

Patch attached, please see if it works for you.

Good to hear, thanks for testing!
Committed.

This seems to be causing a conflict with the patch from #1773440: Use q.alt instead of fq for “filter only” queries which is causing differing behavior on my local machine before and after the commit that introduces this patch. I have a View with exposed filters, one of which is the "State" field from an Addressfield. Compare the query before:

14257625 [qtp24433162-21] INFO  org.apache.solr.core.SolrCore  – [collection1] webapp=/solr path=/select params={q.alt=(tm_field_contact_address$administrative_area:"OR")+(index_id:"member_index")+(hash:ffg1x1)&json.nl=map&fl=item_id,score&start=0&sort=sort_search_api_aggregation_1+asc&rows=25&wt=json} hits=39 status=0 QTime=2 

to after:

14158093 [qtp24433162-17] INFO  org.apache.solr.core.SolrCore  – [collection1] webapp=/solr path=/select params={q.alt=(tm_field_contact_address$administrative_area:(OR))+(index_id:"member_index")+(hash:ffg1x1)&json.nl=map&fl=item_id,score&start=0&sort=sort_search_api_aggregation_1+asc&rows=25&wt=json} status=400 QTime=1 

…though the latter line is proceeded with an org.apache.solr.parser.ParseException barf - the "OR" in the query is now throwing it off.

(Incidentally, the "OR" is already throwing off Acquia's Solr configuration even before this patch, which I can't replicate locally… yeah, last couple days have been a world of Solr hurt.)

Attached patch escapes "AND", "OR", and "NOT" to bring back the previous behavior… locally, anyway.

Oops - that patch included an extra experiment to fix my woes. Here's just the patch for this issue.

Oh, brilliant! Didn't know you could actually escape whole words with a backslash – you never stop learning … (I also quickly verified that it works in Solr 3.x as well.)
So, thanks for the new information and the great patch – looks very good!
Committed. Thanks again!

However, apart from this problem, for indexing state abbreviations, type "String" is much better suited than "Fulltext", since you don't want stemming or anything on that – just finding that exact letter combination. By indexing the field as "String", you could also have avoided this problem.

I just stumble on this issue, this change is breaking one of my queries.
Granted, I might be doing things wrong.
I have a simple "ss_" text field set up as String (not Fulltext) in the index.
I was doing a query on solr on that text field (with start=0 rows=1) to check if there was on solr a document with that specific and precise field value.

Now with the parenthesis behavior the search simply does not return nothing if the field set up as String (not Fulltext) in the index.
If on the other hand the field is configured as Fulltext the search works by being more fuzzy and returning more results (but that's not the behavior I want).

So I'm wondering if the quoting

      case 'text':
        return '(' . call_user_func(array($this->connection_class, 'escape'), $value) . ')';

should be done only for fulltext fields and not String fields?

Or simply I'm doing it wrong and there's a better way to do the query I want?