This problem isn’t exclusive to the public user interface. It occurs in the staff interface if you build an advanced search which is complex enough. Here are steps to replicate:

1. Go to staff interface (e.g. http://test.archivesspace.org/staff)

2. Enter two words in the simple search box to verify that the system is set up for implicit-AND (e.g. family papers currently returns 113 hits which is the same as family AND papers and less than family OR papers which returns 287 hits.)

3. Delete that and click the drop-down arrow to start an advanced search.

4. Try the same two-word search on just one row. It is still AND’ing them (e.g. both family papers and family AND papers return 112, while family OR papers returns 284. I assume these minor differences are because it is targeting the keyword/fullrecord field whereas the simple search is searching all fields?)

5. But if you add a second row then multiple words in either are treated as implicit-OR. (e.g. family papers on one row and* on another, returns 284 hits.)

The difference seems to be the public user interface always builds very complicated advanced_query objects, for all the extra options it gives the users, even if they don’t use them. However, the staff interface builds much simpler advanced_query objects. So I assume the problem is actually in the backend, when it converts them into Solr URLs. But I haven’t been able to track down precisely what triggers it. Possibly it is a bug in Solr but googling doesn’t bring up any promising leads. If you use the debugQuery mode in the Solr web interface, the difference between q.op=AND and q.op=OR is that the former adds + operators before most clauses (after it has split multiple words into separate clauses) so maybe something about the level of nesting is the cause.

Our users really get thrown by the default search being OR, and the ability to configure the public side to search with an AND operator by default would be immensely helpful