This seems to be the result of having the syspref QueryAutoTruncate set to "automatically." Disabling QueryAutoTruncate makes these searches work.

Not for me it doesn't, Jared.  The site I am wrestling with is using XSLT.  If you edit the search string generated by the XSLT to exclude [();], then it works, with or without QueryAutoTruncate turned on, so that may be the best way to go, at least for XSLT-based sites.

It's possible to escape parentheses. I'll get a patch for this written.

Looking at this problem, I suspect that the problem is not in the parentheses but in the use of an index (like se) together with a number of search operands between spaces.
Search.pm interprets this as a ccl query. But ZOOM does not like this query since it expects operators between the operands. In other words, it does not like query [Field1=Value1 Value2]; it does like: [Field1=Value1 or Value2] or even better: [Field1=Value1 or Field2=Value2]. (Brackets for visibility only!) 

In case you would really want to do a phrase search, you need to tell Koha something like [se,phr: "Value1 Value2"]
Note that such a phrase search with parentheses could even work:
se,phr: "(Low countries)" worked for me;
se,phr: "Low (countries)" worked as well.
But I wonder if a regular user would ever come up with such searches..

This problem should be solved by refactoring Search.pm; especially routine buildQuery is here the problem.
The Advanced Search could offer some more assistance in making the difference between word and phrase search.

In our catalog, the problem is in clicking on a link from /cgi-bin/koha/opac-detail.pl  such as Vicksburg (Miss.) -- Directories. which in the MARC record would be a 651 $aVicksburg (Miss)$vDirectories.  
A search for “kw,wrdl: vicksburg miss. directories"  does work  but the parenthesis when clicking on the link from the opac-detail doesn't.

the fix of enclosing in quotes for bug 6553 may also work for this.  Please test.

Created attachment 6499 [details] [review]
Bug 5369: se queries with paranthesis fail

This patch does several things to make the search work better:

1) Adding "" around search terms for queries on index se.
2) Make links for 8xx obey the UseControlNumber system preference
3) Fix the indexing for 8xx fields, as they were not included in the se index before

Note: Make sure you copy the new record.abs into your koha-dev directory and reindex
before testing.

To test:
1) Add records using the following fields:
440$a
490$a ind. 1 = empty or 0
490$a ind. 1 = 1
800$a, 810$a, 811$a or 830$a

Example value taken form bug description, should only work after applying the patch:
DHEW publication no. (HSM) 73-1804

Please also test with other examples.

Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>

Nice work, Katrin! A follow-up patch from me converting the series tracings to se,phr: is forthcoming.

The second patch still requires sign-off. The first patch has been signed off. Please note that the second patch depends on the first patch.

Created attachment 6507 [details] [review]
[SIGNED-OFF] Bug 5369: Make series tracings use phrase indexes

By definition, series tracings should search for other records in the same
series, i.e., those with the exact same series title. This patch forces the
tracings to use phrase indexes for series tracings.

Note that this patch DOES NOT respect TraceCompleteSubfields. While that may be
desirable, it is outside the scope of the current patch. An additional follow-up
patch could be written to add support for TraceCompleteSubfields, if community
concensus is that series tracings should obey TraceCompleteSubfields.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Thx for the follow up and sign off Jared :)

Just a few questions on the first patch before looking further:

1) Should Title-series be only in 800$t, 810$t and 811$t? It is added to $a now too..
2) From LOC: 840 - SERIES ADDED ENTRY--TITLE (R) [OBSOLETE] Should we rather delete it?

(In reply to comment #13)
> Just a few questions on the first patch before looking further:
> 
> 1) Should Title-series be only in 800$t, 810$t and 811$t? It is added to $a now
> too..

That's by design. Title-series is the index used for all series searching, so if someone is interested in a series that's stored in an 800, 810, or 811, they can't search for it using the series index without that change.

> 2) From LOC: 840 - SERIES ADDED ENTRY--TITLE (R) [OBSOLETE] Should we rather
> delete it?

No, libraries still use obsolete fields all the time. I actually was just looking at a library that uses 840 
for analytics that are part of a series.

(In reply to comment #14)
> That's by design. Title-series is the index used for all series searching, so
> if someone is interested in a series that's stored in an 800, 810, or 811, they
> can't search for it using the series index without that change.
Design? Could you please comment on the distinction between $a and $t.

(In reply to comment #15)
> (In reply to comment #14)
> > That's by design. Title-series is the index used for all series searching, so
> > if someone is interested in a series that's stored in an 800, 810, or 811, they
> > can't search for it using the series index without that change.
> Design? Could you please comment on the distinction between $a and $t.

That was poorly worded, sorry. The *patch* does that by design, because Koha incorrectly handles series indexing. 8xx$a is not a "title," per se, but Koha only accepts "Title-series" when searching for series. This would be a prime example of why I recommend a strong aperitif before looking at indexing in Koha. I would argue that the results of the change are correct, since Koha misapprehends the semantics of these indexes anyway.

(In reply to comment #16)
> That was poorly worded, sorry. The *patch* does that by design, because Koha
> incorrectly handles series indexing. 8xx$a is not a "title," per se, but Koha
> only accepts "Title-series" when searching for series. This would be a prime
> example of why I recommend a strong aperitif before looking at indexing in
> Koha. I would argue that the results of the change are correct, since Koha
> misapprehends the semantics of these indexes anyway.

You are right about that. Quality here is a relative thing ;)

Another QA Comment however (sorry..)

I notice that in the xslt the resulting url contains only one double quote at the beginning (meaning the character ").
Example: http://libdevelop.rijksmuseum.nl:8009/cgi-bin/koha/catalogue/search.pl?q=se,phr:%22Rembrandt-reeks
The last %22 is what I mean. There should be a closing one too?

Could you resolve that?
Thanks.

Created attachment 7049 [details] [review]
Signed follow up for quotes

QA Comment:
See also above. Code further looks good. Issue with quotes has been resolved. Marking all three patches as Passed QA.

patch pushed, please test

QA comment: checked UNIMARC record.abs, the problem does not exist