Tested again. The behavior described in the ticket no longer occurs. Nice work!

Commenting since this was added to the October Testing cycle in case it was completed. The behavior described in the ticket persists as of 10/27/2022.

I think I’ve finally got a solution to this involving indexing copies of the hyphenated four part ID and title fields using Solr’s whitespace tokenizer instead of the standard tokenizer. I’m going to put up a draft PR but I’d like to do more testing after our current sprint, so hopefully this can be ready to go in November.

I am having a similar issue.
On the staff interface. I have a UID that will not pull anything up when I search in the manage top container page. I have to put in the first few characters then select from a seemingly random list of records. If I search for the same resource record in the general search field, I can only get the resource record if I have the full UID. If I do a partial, the resource records do not come up at all but it will pull up a completely different resource record. So far this is only happening to two of my resource records which share the near identical UIDs except for the last character. Same thing is happening on the public site and it pulls up the exact same resource record as it does on the staff side which has a different UID altogether.

On behalf of Dev Pri sub-team: Tested this and found that even if the first component of the Identifier is "1234-abcd" all together, the typeahead will work as described in the ticket above:

• Go to any collection aside from the "id0=1234, id1=abcd" one, like this collection: http://test.archivesspace.org/staff/resources/102#tree::resource_102

• Click on the Merge dropdown

• Type in 1234-abcd

• The typeahead finds NO results.

• Change that to just 1234, without the hyphen.

• The typeahead finds a lot of results, including the 1234-abcd (in two id components; Aperture & Labs records) one at the top and the 1234-abcd (in one ID component; test).