Check whether ISBN already exists if manually adding a book

[onnotasler]

When searching for a book or author, it is sometimes not found. Searching for an ISBN might cause a delayed import that will not be found immediately.

In that case, I feel inclined to manually import a book. Despite entering the ISBN, there is no check whether this ISBN already exists. This might cause duplicates.

Describe the problem that you'd like solved

If I enter an ISBN in the add book page, there should be a background check on whether this ISBN already exists to prevent duplicates.

If a work already exists, I should get a notification and be asked whether those books might need to be merged or an error needs to be reported (for example, because an edition is connected to the wrong work).

Proposal & Constraints

The author field has a similar functionality, which looks for author with similar spellings.

Additional context

#3473
#7055

Stakeholders

@mekarpeles @cdrini

[MingdaMa]

Hi, I will start working on this issue

[mekarpeles]

Maybe when the patron clicks on the isbn field, if they have js enabled, then we will check /isbn/{isbn} to see if the item exists and if so, show a popup with the existing matching books and say "go to book" or "keep adding" (please actually come up with better text than those examples)

[mekarpeles]

@MingdaMa please let us know if you need help with this issue:

1. look in plugins/openlibrary/js/ for the right place to add code for the import /addbooks page
2. after an isbn is pasted in the field (debounced) then lookup the isbn with a fetch to openlibrary.org/isbn/{isbn}
3. If the API returns data back, then inject a html snippet into the page which shows the matching book with a message "an existing book was found with ISBN {isbn}: openlibrary.org/isbn/{isbn}"

[MingdaMa]

@MingdaMa please let us know if you need help with this issue:

1. look in plugins/openlibrary/js/ for the right place to add code for the import /addbooks page
2. after an isbn is pasted in the field (debounced) then lookup the isbn with a fetch to openlibrary.org/isbn/{isbn}
3. If the API returns data back, then inject a html snippet into the page which shows the matching book with a message "an existing book was found with ISBN {isbn}: openlibrary.org/isbn/{isbn}"

Thanks for the instruction, it's my first time working on this project so I'm a bit slow. I'll keep working on it!

[scottbarnes]

@MingdaMa, are you still interested in this? If you are, then great! Please ask any and all questions you have. But if not, I'd like to make it a bit easier to find for those who might wish to work on this.

[MingdaMa]

@MingdaMa, are you still interested in this? If you are, then great! Please ask any and all questions you have. But if not, I'd like to make it a bit easier to find for those who might wish to work on this.

Thanks for checking in! I am still interested in this, the problem I have right now is when I try to call the api, I will get a CORS error and I'm still trying to figure this out.

[github-actions]

Assignees removed automatically after 14 days.

[Dwayne-Lacey]

Hey @jimchamp can this be assigned to me?

[jimchamp]

@Dwayne-Lacey, you've been assigned. Let me know if you have any questions or run into any issues.

[Dwayne-Lacey]

Hey @jimchamp so I've been working on adding the fetch request and I was having some issues getting any sort of response when using openlibrary.org/isbn/0553381687 to test. I was wondering if there might've been something I was missing or if the endpoint should be something else.

This was the snippet of my test code, just trying to look at what the response itself would look like, but I kept receiving a timeout due to typeError

const fetchPromise = fetch('https://openlibrary.org/isbn/0553381687');
        fetchPromise.then(resp => {
            console.log(resp);
        });

[jimchamp]

Sorry for the delay! The /isbn/{isbn_number} endpoints ultimately redirect to a book page. I think that the handler for those endpoints also attempts to fetch book data from third-parties when an ISBN is missing (citation needed... this functionality may have been disabled recently).

Try using the .json endpoint for this case: /isbn/{isbn_number}.json.

If that doesn't help, you may want to open your browser's devtools and check request and response in the "Network" tab.

[scottbarnes]

It's poorly documented and that is something I want to improve, but this comment has a bit of an explanation of the /isbn endpoint, which has been re-enabled as of the last deploy: #8690 (comment).

The short of it is that to immediately attempt an import by ISBN and return JSON, the request would be to, e.g., https://openlibrary.org/isbn/0553381687.json?high_priority=true

[jimchamp]

@scottbarnes, do these /isbn endpoints always attempt to import a book? If so, is this going to lead to redundant records? Is the record that was submitted by the patron going to get clobbered by the import?

[jimchamp]

@mekarpeles, if the isbn matches an existing book, do we prevent the add book form from being submitted? Today, whenever a add book from with an invalid isbn is submitted, the submitter is prompted to confirm that they actually want to add the invalid ID. Should we give the same option for these cases?

[scottbarnes]

/isbn should not try to import by default, even if high_priority=True is passed. I sadly still only have documentation in that comment, but I am getting closer to this endpoint.

That said, when one queries /isbn:

1. First the Open Library database is searched for that ISBN, and if a match is found, that matched edition is returned;
2. If no existing match is found, the import_item table will be checked for staged entries that match, an imported will be attempted based on that match, and a new edition if any will be returned;
3. Finally, in the default case the ISBN will either be staged for import via the affiliate-server (and the browser will get a 'not found' message). If high_priority=True an import will be attempted for the ISBN if matching data is found via the affiliate-server, and the new edition, if any, is returned.

In terms of what this means for clobbering, I guess that depends on the mechanics of the change. I do not think it would clobber anything from the patron, though. From the current PR my understanding is that if a match is found, that is reported back to the patron (and we need to do decide what to do), and if a match isn't found, then if any metadata was found in step (3), it would be staged for import via the affiliate-server (so that the same metadata doesn't need to be looked up again via the affiliate-server).