Bootstrap: Records always display Located URIs from ALL records in the metarecord group, even if search is not grouped

[Christine Morgan]

In the Bootstrap catalog, all located URIs contained in records within a metarecord group display in the record summary for any record in that group, no matter the format of the record and whether or not the record is in the search results set.

For example, if there are five bibs in a metarecord group, and each bib has one located URI, those 5 records will always show all five located URIs.

To see this behavior you will need to find (or create) a metarecord group with located URIs in some of the records.

Steps to reproduce:

- Find a metarecord group in the Bootstrap Catalog. I used Group Formats and Editions to help me find a group. Make sure the group has some records with located URIs and some records without located URIs.

-Click on the group to see all the records.

-View each record and you will see that the same set of URIs display in all records regardless of format.

Observed in 3.6.2 and a test system running Master.
I've uploaded a pdf that illustrates the display issue.

[Blake GH (bmagic)]

I found a workaround. In the meantime, if folks want a workaround:

1. Create an override for your custom OPAC for the file:
opac/parts/record/summary.tt2
2. Update this line:
        [%- merged_uris = args.uris.merge(args.online_res);
To this:

[%- merged_uris = args.uris;

Save the file.

I've been trying to work backwards and figure out how the args.online_res array is getting the values for the constituent bibs. It has to do with the order of execution. In the old OPAC, the electronic resources were displayed BEFORE the "View other formats and editions", but the BOOPAC shows the electronic resources AFTER. Which means, the args variable has been populated with all of the metarecord data at this point in the execution.

[Jeff Davis (jdavis-sitka)]

The fix for bug 1950394 appears to resolve this issue. That fix has been committed and will be included in 3.7.3 and 3.8.1. I'll mark this bug as a duplicate.