Bug 26921 - Create cover image even when there is no record identificator
Summary: Create cover image even when there is no record identificator
Status: RESOLVED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Jonathan Druart
QA Contact: Josef Moravec
URL:
Keywords:
Depends on: 22445
Blocks:
  Show dependency treegraph
 
Reported: 2020-11-04 08:04 UTC by Hugo Agud
Modified: 2021-06-14 21:34 UTC (History)
7 users (show)

See Also:
Change sponsored?: Sponsored
Patch complexity: ---
Text to go in the release notes:
Version(s) released in:
21.05.00,20.11.01


Attachments
Bug 26921: Don't generate an invalid custom cover image if the url cannot be generated (20.75 KB, patch)
2020-11-05 15:08 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 26921: Don't generate an invalid custom cover image if the url cannot be generated (20.82 KB, patch)
2020-11-05 18:22 UTC, Tomás Cohen Arazi
Details | Diff | Splinter Review
Bug 26921: Don't generate an invalid custom cover image if the url cannot be generated (20.95 KB, patch)
2020-12-16 16:34 UTC, Josef Moravec
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Hugo Agud 2020-11-04 08:04:38 UTC
We have identified an issue with bug 22445, when we define the url we add the value to identify the id and create the link

The link is created even there is no identification


Example: 
https://xxxxx.xxxx.cat/cobertes.php?isbn={isbn}&institucio=xxxx

If the record has not isbn, the patch create the thumnail with empty value, the patch should avoid create the thumbnail if the {}values are empty

be aware that we could have more than one identifier {isbn}{issn}, it should check both values
Comment 1 Katrin Fischer 2020-11-04 08:16:17 UTC
Please use the depends on field in such cases to link the bugs together, thishelps to identify which versions we have to fix and to alert anyone involved in hte previous bug.
Comment 2 Jonathan Druart 2020-11-05 15:08:52 UTC
Created attachment 113124 [details] [review]
Bug 26921: Don't generate an invalid custom cover image if the url cannot be generated

In case a custom cover image url is used to generate the cover image of
bibliographic records, we should not build one if the record does not
have the necessary data.

For instance if you have
CustomCoverImagesURL set to https://covers.openlibrary.org/b/isbn/{isbn}-M.jpb
and a biblio does not have the isbn defined, we should not generate and
empty image (empty or invalid src)

Test plan:
0.
Set CustomCoverImagesURL to https://covers.openlibrary.org/b/isbn/{isbn}-M.jpb
Enable CustomCoverImages and OPACCustomCoverImages
To highlight the issue you should disable LocalCoverImages and OPACLocalCoverImages.
1. Make sure you have some of your bibliographic records with a valid
isbn
2. Make sure you have at least 1 bibliographic record without an isbn
set
3. Visit the search result and detail views (OPAC and staff interfaces)
=> Without this patch you should see a "Cover image" link, and an empty
block/div on the detail page
=> With this patch applied you should only see images when the url can
be generated

Note that the problem will persist if the isbn is not valid (ie. no
image is generated)

Sponsored-by: Orex Digital
Comment 3 Tomás Cohen Arazi 2020-11-05 18:22:48 UTC
Created attachment 113128 [details] [review]
Bug 26921: Don't generate an invalid custom cover image if the url cannot be generated

In case a custom cover image url is used to generate the cover image of
bibliographic records, we should not build one if the record does not
have the necessary data.

For instance if you have
CustomCoverImagesURL set to https://covers.openlibrary.org/b/isbn/{isbn}-M.jpb
and a biblio does not have the isbn defined, we should not generate and
empty image (empty or invalid src)

Test plan:
0.
Set CustomCoverImagesURL to https://covers.openlibrary.org/b/isbn/{isbn}-M.jpb
Enable CustomCoverImages and OPACCustomCoverImages
To highlight the issue you should disable LocalCoverImages and OPACLocalCoverImages.
1. Make sure you have some of your bibliographic records with a valid
isbn
2. Make sure you have at least 1 bibliographic record without an isbn
set
3. Visit the search result and detail views (OPAC and staff interfaces)
=> Without this patch you should see a "Cover image" link, and an empty
block/div on the detail page
=> With this patch applied you should only see images when the url can
be generated

Note that the problem will persist if the isbn is not valid (ie. no
image is generated)

Sponsored-by: Orex Digital
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Comment 4 Josef Moravec 2020-12-16 16:34:39 UTC
Created attachment 114452 [details] [review]
Bug 26921: Don't generate an invalid custom cover image if the url cannot be generated

In case a custom cover image url is used to generate the cover image of
bibliographic records, we should not build one if the record does not
have the necessary data.

For instance if you have
CustomCoverImagesURL set to https://covers.openlibrary.org/b/isbn/{isbn}-M.jpb
and a biblio does not have the isbn defined, we should not generate and
empty image (empty or invalid src)

Test plan:
0.
Set CustomCoverImagesURL to https://covers.openlibrary.org/b/isbn/{isbn}-M.jpb
Enable CustomCoverImages and OPACCustomCoverImages
To highlight the issue you should disable LocalCoverImages and OPACLocalCoverImages.
1. Make sure you have some of your bibliographic records with a valid
isbn
2. Make sure you have at least 1 bibliographic record without an isbn
set
3. Visit the search result and detail views (OPAC and staff interfaces)
=> Without this patch you should see a "Cover image" link, and an empty
block/div on the detail page
=> With this patch applied you should only see images when the url can
be generated

Note that the problem will persist if the isbn is not valid (ie. no
image is generated)

Sponsored-by: Orex Digital
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Comment 5 Jonathan Druart 2020-12-21 09:20:12 UTC
Pushed to master for 21.05, thanks to everybody involved!
Comment 6 Fridolin Somers 2020-12-28 13:46:36 UTC
Pushed to 20.11.x for 20.11.01
Comment 7 Andrew Fuerste-Henry 2020-12-28 15:19:30 UTC
Doesn't apply cleanly to 20.05, please rebase if needed