Why was this change made?

Some Bodleian records were missing titles and title extraction macros were missing test coverage

How was this change tested?

Local transform

Which documentation and/or configurations were updated?

n/a

Why was this change made?

Some Bodleian records didn't have a title in the raw record

How was this change tested?

Local transform

Which documentation and/or configurations were updated?

n/a

Why was this change made?

Some Bodleian records were missing titles and title extraction macros were missing test coverage

How was this change tested?

Local transform

Which documentation and/or configurations were updated?

n/a

Why was this change made?

several auc configs were returning NOT FOUND errors for language values

How was this change tested?

local transform

Which documentation and/or configurations were updated?

n/s

Why was this change made?

Adds missing lang keys

How was this change tested?

local transform

Which documentation and/or configurations were updated?

n/a

Why was this change made?

Fixes some errors in the config.

How was this change tested?

Local transform.

Which documentation and/or configurations were updated?

n/a

Why was this change made?

A new test to catch missing language keys was written. This PR adds keys to fields that are missing them so that PR can be merged.

How was this change tested?

local transform

Which documentation and/or configurations were updated?

n/a

Yeah, I saw the error in the config, but there is an error in the raw data files as well. We can fix the config to ignore the iiif manifest in those cases and grab the url from the raw data but it won't actually fix these urls until QNL updates them and we re-harvest.

I'm not sure we want to display our image placeholder if the thumbnail is not valid. I think we want to suppress the record once we have the auto harvest worked out. In that case if the url breaks, we will not reload it and it the provider fixes the error the record will get loaded on the next auto harvest. Does that make sense?

This is captured in the google doc, but maybe first we should check to see if they are valid. I'm pretty sure the application doesn't break when a url doesn't resolve as long as its valid. It seems to only break when you pass something that doesn't look like a valid url. The other issue, of course, is when we re-harvest a set we should test urls and suppress those that no longer resolve so we keep the site clean or broken urls.

Currently if a bad url is loaded in the agg_preview field (probably agg_is_shown_at as well), the following error message is displayed when clicking on the set of records containing the bad url (e.g. through selecting the data contributor): Selecting exhibit dashboard to unload the records results in the same message.

Loading bad urls is part of the transformation process. I have error checking locally but it only tests if the url is valid not if it is resolvable. I also forget to run that check sometimes. In some cases, particularly when the collection is large, it is difficult to find the record with the bad url.

Desired behavior:

• [ ] The application will not break completely when a bad url is loaded; it should still be possible to access the exhibit dashboard to unload the records.
• [ ] The error message will indicate that the url will not resolve and return the dlme_source_file value (if available) and the id instead of "We're sorry, but something went wrong."

A few QNL records have bad thumbnails leading to pages that will not render in the application:

• https://app.honeybadger.io/projects/53082/faults/80088751/01FB4G4F3PB8QZT061807CR2C0#notice-summary

• For example, we can draw this page: https://dlmenetwork.org/ar/library/catalog?f%5Bdate%5D%5B%5D=1400&page=12565

• but not this one: https://dlmenetwork.org/ar/library/catalog?f%5Bdate%5D%5B%5D=1400&page=12561

Known bad ids are:

• 81055/vdc_100023618815.0x000007 from record qnl/british-library-combined/data/group7/qnl-combined-6815.xml
• 81055/vdc_100023618815.0x000005 from record qnl/british-library-combined/data/group17/qnl-combined-16488.xml

Need to:

• [ ] reharvest QNL
• [ ] see if the data is the same and revise mapping config, if needed

Why was this change made?

The resource urls changes since last harvest

How was this change tested?

Local transform and load in dev

Which documentation and/or configurations were updated?

n/a