You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
** Why are these changes being introduced:
Now that there's an integration with libkey via an internal path, the
search results page needs to consult that when relevant results are
received from our discovery APIs.
** Relevant ticket(s):
* https://mitlibraries.atlassian.net/browse/use-232
** How does this address that need:
This adds fields for DOIs and PMIDs to the Primo record normalizer, on
the assumption that any given record has at most one of each of these.
If none is found, the field is left out of the normalized record.
If one is found that value is added to the normalized record.
If more than one is found, a message is sent to Sentry so we can look
further. This will help us understand how widespread the condition is.
(Any record might have _both_ a DOI and PMID, this is not problematic).
When a record has one of these values, we call the internal lookup route
via a stimulus controller. If the lookup results in an integration link
(not all DOIs or PMIDs will turn out this way), the link is added as the
first link in the UI.
If a record has both a DOI and a PMID, only the DOI is used.
I've written tests for the normalizer model, to confirm that it handles
cases with zero, one, and mulitple of each field. The tests don't deal
with the Sentry integration, however.
** Document any side effects to this change:
The integration with Sentry is a little iffy. I'm not thrilled about
directly calling Sentry from a model like this, but I want to be able
to use a consistent message text, while defining tags on each message
so that we can get the record IDs and DOIs/PMIDs to help us investigate
further.
0 commit comments