Search behaviour change between 2.5.3 and 2.6.4

[Raphaël Barman]

Hello,

I have updated an AtoM installation from 2.5.3 to 2.6.4 and noticed an important behavior change in the search between the two.

Previously, when searching for two terms separated by a space "term1 term2", the search would find information objects that had a field with "term1" and another field with "term2". This is no longer the case in 2.6.4, where now a single field needs to contain both "term1" and "term2" to have a match. A workaround is to use the advanced search and to search for "term1" AND "term2", but this is not very practical.

Is it possible to somehow revert the previous behavior?

Also, is this change documented somewhere? The closest modification I found that may have caused this behavior change is the one introduced in this PR https://github.com/artefactual/atom/pull/1254. But no trace of it in the release notes.

Thanks in advance for your answer,
Best,
Raphaël

[Dan Gillean]

Hi Raphaël, 

This was not an intentional change, and I'm not currently seeing what you describe. As an example, take the following record in our demo site currently running 2.6.4:

• https://demo.accesstomemory.org/1st-coniston-wolf-cub-pack-2
  

In this record, the word "donated" appears in the Archival History field, and the word "scrapbook" appears in the Scope and content field. Neither word appears in both fields. 

A search for donated scrapbook returns 2 records, including this one:

• https://demo.accesstomemory.org/informationobject/browse?topLod=0&sort=relevance&query=donated+scrapbook&repos=

By default, using two terms to search, i.e. term1 term2, will be understood by AtoM as: 

• return results that include term1 AND term2 appearing in any indexed field

These results do not need to be adjacent or co-located in the same field. However, if you introduce quotations and search "term1 term2" then you are now telling AtoM to perform an exact search, i.e.:

• return results that include term1 term2 together in that exact order

This should have been the case in release 2.5.3 as well as the recent 2.6 releases. Here is the relevant entry in the 2.5 documentation: 

• https://www.accesstomemory.org/docs/2.5/user-manual/access-content/advanced-search/#phrases
  

If this is not behaving as expected, I recommend that you try running the search:status task to ensure that all records are indexed as expected: 

• php symfony search:status
• See: https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/cli-tools/#check-the-status-of-your-elasticsearch-index

If there are any unindexed records, you can re-index your site, clear the application cache and restart PHP-FPM, and check again. You may also want to clear your web browser cache as well, to ensure you are seeing updated results. See: 

• Populate search index: https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/populate-search-index/
• Clear cache: https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/clear-cache/
• Restart PHP-FPM: https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/troubleshooting/#restarting-php-fpm

Let us know if this helps!

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/6c4ad1d2-2f9f-45c8-bfa9-f633141c6351n%40googlegroups.com.

[Raphaël Barman]

Hi Dan,

Thanks a lot for your answer and your suggestions. You are correct, this works with text fields.

However, it seems that it does not work for access points and a text field.

For example, I added this new information object: https://demo.accesstomemory.org/randomtitle

When you search for "randomtitle randomaccesspoint", you don't find it (https://demo.accesstomemory.org/informationobject/browse?topLod=0&sort=relevance&query=randomtitle+randomaccesspoint&repos=).

But when you search for "randomtitle" and "randomacesspoint", you find it (https://demo.accesstomemory.org/informationobject/browse?sort=relevance&sq0=randomtitle&sf0=&so1=and&sq1=randomaccesspoint&sf1=&repos=&levels=&onlyMedia=&findingAidStatus=&copyrightStatus=&materialType=&topLod=0&startDate=&endDate=&rangeType=inclusive).

This behavior was not the case in 2.5.3.

Maybe by tweaking the mapping.yml file I can revert to the previous behavior. If you have any pointers on how to do that, please let me know.

Best,

Raphaël

You received this message because you are subscribed to a topic in the Google Groups "AtoM Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ica-atom-users/8fGQWAfb1_Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZJWpAw8DrtFWrAqevK%3D4gDSwf0MB13oaEhnbiHqQEfv8g%40mail.gmail.com.

[Raphaël Barman]

Hi Dan,

I further investigated and found out that this also does not work with text fields and the two words need to appear in the same field.

In  your example, both words appear in the

I found an example on the demo that does not work. On the page https://demo.accesstomemory.org/will-munro-collection, the name "Margaret" appears in several fields and the word "Moustache" in the scope and content field.

However, searching for "Margaret Moustache" does not yield any results https://demo.accesstomemory.org/informationobject/browse?topLod=0&sort=relevance&query=Margaret+moustache.

Hope this helps track the change,

Best,

Raphaël

[Dan Gillean]

Hi again Raphaël, 

Thank you for this additional information. I see what you mean, and I've now managed to properly reproduce it. It's interesting that using the Advanced Search query builder will yield the correct results - this suggests to me that boolean AND queries in the global search are accidentally being scoped to the same field, rather than anywhere in a given record. 

I've now filed the following bug ticket: 

• https://projects.artefactual.com/issues/13608
  

While I can't 100% guarantee the inclusion of a fix for this in the next major release (2.7) without sponsorship, I've marked it as a high priority and consider it an unintended regression that we should prioritize for review, as it greatly reduces the usefulness of AtoM's global search functionality. My hope is that we'll be able to address it for 2.7. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CABgFMqiTRdpw6%2BVze6Zvr_CC1LURD%2B3r8PQTj_cVKtnN64XEbg%40mail.gmail.com.

[Raphaël Barman]

Hi again Dan,

Thanks for the new bug ticket.

If this helps, I made a quick (and certainly naïve) fix because this was very important to keep this behavior. You can find the patch here: https://gist.github.com/bardocuteam/c7b109c351c6d8c7a65767fb06fb35bf.

Best,

Raphaël

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZ%2B8AdC6e%3D3nF5rH7KuRWEob6XAC-zT6E2vHq%2BVpLR8WEQ%40mail.gmail.com.

[Dan Gillean]

Thanks Raphaël!

I've added a link to your patch on the related ticket, so our team can review it. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CABgFMqg4cM5ByQLCnxmxm%2BrQa1uhYXg%2BGpywzcn_7yEOtoc19A%40mail.gmail.com.