Just a couple things I want to point out...
1) su-na already exists in the CCL config as an alias for something other than "narrower term" for a subject:
2) If QueryParser is turned off, using su-br and su-rl queries will cause Zebra errors, because these aliases aren't defined in ccl.properties.
The QueryParser dynamically adds them (and su-na) using a callback which adds them to the aliases defined in the config loaded from queryparser.yaml, I believe.
To get around this, we could probably add "su-br" and "su-rl" as aliases to subject. We should probably also rename the existing su-na to something like su-nap so it doesn't get confused with the "su-na" for narrower terms during a query...
3) Even when the QueryParser is turned on, if you do a search for "Subject and Broader/Narrower/Related Terms" in advanced search, you'll always get a search that appends "wrdl" to the end of the alias. Unfortunately, QueryParser doesn't use "wrdl", so it falls back to using a non-QueryParser query, which creates the Zebra errors mentioned in Problem #2.
4) Advanced search with "more options" causes QueryParser to fail.
It seems to be that "limit=" gets added onto the query string and that this is causing QP to fall back to non-QP.
My guess is it's related to "Audience", "Content", "Format", or "Additional content types for books/printed materials", as these seem to be the only limits added when "expanded_options=1".
5) Advanced search includes a lot of "wrdl" suffixes which will cause QueryParser to fail.
(E.g. su,wrdl; se,wrdl; au,wrdl; cpn,wrdl; cfn,wrdl; pn,wrdl; pb,wrdl; pl,wrdl;)
I've tried out some of these indexes without the wrdl suffice while NOT using QueryParser, and they seem to work fine. I think we could get rid of these suffixes from the advanced search.
6) QueryParser also seems to ignore repeated indexes in a query...
kw:law || su:bulldozer || kw:test
kw:test || su:bulldozer || kw:law
It should give the exact same results...
7) If you try to use the "Search also for broader subjects" link from the search results and you don't have authorities, you'll get a database authorities unavailable error. Not the end of the world. But maybe we should hide these links if the Koha DB doesn't contain any authorities, since they'll never ever work and will just confuse users.
Admittedly, I did most of this testing in 3.14 instead of master...but this is more so a report that I can consult later and for people to find if they are having the problems outlined in this issue...
Seems to be still valid on current master [16.06]
Hard to explain why we offer those options.
What should happen with QueryParser in its current state?
(In reply to Marcel de Rooy from comment #2)
> What should happen with QueryParser in its current state?
That's a very good question. In my opinion, we should probably remove it from the code, since its use is problematic and it doesn't really have anyone to develop/maintain it. I would volunteer to work on it, but I don't have the time.
We've voted to remove the QueryParser code (https://wiki.koha-community.org/wiki/Development_IRC_meeting_4_March_2020), so I am closing this WONTFIX.