Princeton-CDH / mep-django

Shakespeare and Company Project - Python/Django web application
https://shakespeareandco.princeton.edu
Apache License 2.0
5 stars 1 forks source link

As a content editor, I want the card image URLs in footnotes updated to resolve to Figgy after content is migrated so that I can access images in their new location. #225

Closed rgmunson closed 4 years ago

rgmunson commented 5 years ago

Notes for testing

See #373 for testing related functionality for display of manifest/canvas thumbnails in the admin site

rlskoeser commented 5 years ago

Note: some of the accounts that were split out have correct file paths in the location part of the footnote but are associated with the wrong card bibliography record - @elspethgreen and I have determined this is not worth editing manually, since it will be tedious and can probably done programmatically. Probably makes sense to clean that up when we do the figgy url migration.

I'll increase estimate from 2 to 3 to account for the additional work.

rlskoeser commented 4 years ago

Increasing to 5pt to account for the additional work resolving repeated paths in the spreadsheet and the cleanup needed in the footnote locations.

rlskoeser commented 4 years ago

Here's the script output from running in test:

$ python manage.py import_figgy_cards mep/accounts/fixtures/pudl-to-figgy-mapping.csv
Found 624 bibliographies with pudl image paths
Could not identify card for c/catel/00000001,c/catel/00000002
Could not identify card for e/edel/00000001,e/edel/00000002
Migration complete.
Found 0 bibliographies and 137 footnotes with pudl paths

The "could not identify" errors are expected - these are cases where there are two objects in Figgy but we consolidated the bibliography record in our database (Catel/Villars; Mr and Mrs Edel).

clmahoney commented 4 years ago
clmahoney commented 4 years ago
rlskoeser commented 4 years ago

@clmahoney great question, I should have probably noted that somewhere - the IIIF image IDs don't actually resolve in Figgy. I mentioned this to the team and asked if they could add something to resolve the image ID to an appropriate URL - I think they're considering it, but don't expect it to happen anytime soon. If you remove the end of the url and just leave the part ending with /manifest/ you will get the JSON representation of the IIIF manifest.

clmahoney commented 4 years ago
clmahoney commented 4 years ago
rlskoeser commented 4 years ago

@clmahoney regarding this note:

  • It looks like only 2 events were "not supported": one is a google book link, one doesn't have any link (to pudl or otherwise): Lescure, Yvonne and Acheson, Sam, Mr.

I meant to have you search the footnotes directly, not the events (although this was a useful thing to check that I didn't think of!).

If you go to the main admin dashboard, and select Footnotes under the Footnotes section (next to the bibliography records), you can access the footnotes directly instead of as attached to the events. When I search on pudl I find 137 records, but they don't have full paths that I can update in my script. These will have to be fixed manually no matter what, so I wanted to make sure you look at them as part of checking this migration.

I don't understand this question enough to answer. Can discuss on Slack so you can share links and explain what you mean?

Your question raises a point that is worth noting: as part of the migration, I'm putting the IIIF image ids in the footnote locations in addition to associating the image. That's redundant, since we're already linking to the image in the database. It occurs to me now, there's no easy way for you or other project team members to find the image identifiers to do that. We could add logic to have the image identifier automatically added based on the associated image when the record is saved, but I didn't implement that yet because we said we weren't going to be doing new footnotes anytime soon. We didn't account for clean up work after this migration (didn't know about it yet).

I think we should do one of two things:

  1. I revise my code to drop the image identifier in the footnote location, and rely only on associated image
  2. Leave the code as is, and whoever does manual clean up on the 137 footnotes will associate image but not enter a location.
rlskoeser commented 4 years ago

@clmahoney you removed the awaiting testing label, but didn't close or add any other labels. When you get a chance (probably after we discuss the above), please let us know where this stands in your estimation - do you have questions that still need to be answered, are there any problems I need to resolve before you can accept?

clmahoney commented 4 years ago

@rlskoeser Sorry! I should have added a question tag. You answered both of them.

re: Footnotes that are still in PUDL: I see them now! I wasn't sorting by location, which would have made it so much simpler for me to find, and which I finally did now. I see the 137 that you do. I will be able to fix them manually.

clmahoney commented 4 years ago

I will close this now!

clmahoney commented 4 years ago

@rlskoeser What date should I have this manually fixed by?