Set current location from request service point for 'awaiting pickup' items

[corylown]

Closes #974

[jcoyne]

Can you confirm you've run this with the folio_postgres_reader_spec.rb and the time isn't adversely affected?

[jcoyne]

Where will these labels come from in Searchworks? Aren't we moving toward using Folio location labels?

[corylown]

The equivalent in FOLIO for these locations would be service points, which I don't think we're doing anything with in SearchWorks yet. We might want to. But this gets us to parity with Symphony by relying on the existing Constants:LOCS mappings.

[jcoyne]

I believe the intention is to remove Constants::LOCS after migrating to Folio, so we need to handle these in some other way. (see sul-dlss/SearchWorks#3310)

[corylown]

@cbeer I'm confused about what the plan is for Constants::LOCS vs FOLIO display names. My guess is we're still going to have location codes that don't map to anything in FOLIO and we'll need to maintain a fallback list in SearchWorks (maybe I'm wrong about this). This PR is a refinement to previous work to map folio statuses to symphony locations so they'll display right in searchworks. Is this no longer what we want to do?

See:

• https://github.com/sul-dlss/searchworks_traject_indexer/pull/940/files
• https://github.com/sul-dlss/searchworks_traject_indexer/pull/973/files

[corylown]

Tried to capture post-folio work related to this in #1026

[jcoyne]

Aren't we going to be moving away from item_display and towards using item_display_struct? Do we need this change there as well?

[corylown]

Aren't we going to be moving away from item_display and towards using item_display_struct? Do we need this change there as well?

No additional change is needed. This is modifying the current_location value used to construct sirsi_holdings for FOLIO records and sirsi_holdings is what's used to construct the newitem_display_struct field (which is then used to create the legacy item_display field).

[corylown]

Can you confirm you've run this with the folio_postgres_reader_spec.rb and the time isn't adversely affected?

It's still within the expected range of 30 to 90 seconds:

Traject::FolioPostgresReader
  creates FolioRecords

Top 1 slowest examples (51.85 seconds, 100.0% of total time):
  Traject::FolioPostgresReader creates FolioRecords
    51.85 seconds ./spec/lib/traject/readers/folio_postgres_reader_spec.rb:19

Finished in 51.86 seconds (files took 1.57 seconds to load)
1 example, 0 failures