Hide IA cover upload button if most recent cover upload is from IA

[emggeorge]

Closes #10933

Technical

This PR introduces logic to the covers/add.html template that determines if the most recently added cover was from IA. I haven't been able to test it fully (more below), but the code is intended to:

1. Get recent changes of the edition
2. Initialize the boolean ia_upload that will only turn off if it is certain the most recent cover is from IA
3. Loop through each change in recent history
   a. At the first instance of an "add-cover" action, check if the associated url for this change matches the url for the IA cover. If the urls match, then the ia_upload is set to False
   b. The for loop breaks after the first "add-cover" action. I'm assuming each cover upload overrides the last, so it is not necessary to look at out dated cover edits
4. Render the IA upload button if ia_upload is True

Testing

I do not think local works have edit history beyond their upload information. I was able to make sure these commits don't break the current button, but haven't been able to test it on any works where the IA upload button should be turned off.

I tried uploading works with the correct edit history, but the history didn't import locally. I'm hesitant to try to just upload covers in my local environment because the Loading Production Book Data doc advises against it.

Is there a way to manually update the history of a work for local testing?

Screenshot

Stakeholders

@RayBB

[accesslint]

There are accessibility issues in these changes.

[accesslint]

This image is missing a text alternative. This is a problem for people using screen readers.

[RayBB]

@emggeorge there's a merge conflict now in the code, could you resolve it? I'll try to review this week

[emggeorge]

@RayBB yes, I'll be able to look into it tomorrow or Wednesday evening and can let you know if I come across any issues.

[emggeorge]

@RayBB Conflicts are resolved, although I am still unsure how I might test this locally (as described in the Testing section). Do you think you could you describe for me what you did to test the Wikidata cover upload that you added recently?

[RayBB]

@emggeorge you can test it by adding an ocaid to a book on testing. Pick any book from the production homepage with that ID and add it to open library locally then you should be able to test.

[cdrini]

Nice work @emggeorge ! The history API will only show the img_url in this way if it was uploaded via the UI; books that get a cover while imported, which is many of our IA books, will not have that field set, I believe.

What we can do is use the .get_covers() method, which has metadata about source_url, eg https://covers.openlibrary.org/b/id/9485916.json .

Also note how the URL ends with /cover. Our covers could either be /cover or /title. The endpoint we use currently for the "Upload image" form shows a different endpoint /default.jpg, which will let IA determine which to use. This is problematic, because this differs from what we have in our covers DB/what happens during import.

To fix all these, I think we can:

1. Remove the default.jpg url and display both /cover and /title images. This will give folks a choice which is nice, and remove the ambiguity of the /default.jpg endpoint.
2. Switch from history field to cover's source_url field, which will more consistently have the right info, and iterate over existing covers and check the source_url field to see if already set
   • existing_urls = set(image.info().get('source_url', '') for image in doc.get_covers())
3. If already in uploaded copies, disable the button and add a message to bottom of form.

This will also require two small extensions:

1. Update the button style when disabled to look disabled. Currently looks the same.
2. To avoid people randomly just clicking "Upload image" now that there are two options, let's fix the "Manage covers" button, to launch the manage covers modal, instead of the add covers modal. This is a bug.

This is a slightly larger issue now I'm afraid, so let us know if you're still interested in tackling it! We're happy to help with any questions 😊

[emggeorge]

Thanks @cdrini! I would still be interested in working on it as long as it works with your timeline. I have time this weekend and would expect to be able to have an updated PR by this coming Monday.

Out of curiosity, could you explain how you knew to look at the .get covers() method? I ask because I'm trying to get better at planning solutions in the Open Library code base and think it would be helpful to understand how other people approach issues.