[Koha-bugs] [Bug 9737] Local Covers sometimes appear then disappear on OPAC Search Results/Lists

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9737

David Cook <dcook at prosentient.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Failed QA                   |In Discussion

--- Comment #11 from David Cook <dcook at prosentient.com.au> ---
(In reply to comment #10)
> (In reply to comment #9)
> > 2) In the bug branch, you should be getting the local cover image and 2 "no
> > cover image available" blocks. That's correct behaviour. 
> > 
> > --
> > 
> > From the sounds of it, you're getting the correct behaviour.
> 
> Hum.. ok :)
> It was what I got but to me it is a regression.
> I don't get why it is the expected behavior, could you explain please?
> 
> By adding some tests, we can decide not to display the second one.
> It could be fix with something like:
> [% IF ( GoogleJackets ) %]
>   [% IF isbn %]
>     ...
>   [% ELSE %]
>     [% UNLESS SyndeticsCoverImages OR OPACAmazonCoverImages OR ... %]
>        No cover image available
>     [% END %]
>   [% END %]
> [% END %]
> And others for OpenLibraryCovers and BakerTaylorEnabled, etc.

Mmm, I think I understand you. I consider it expected behaviour rather than a
regression, because this patch prevents the Amazon JScript from touching
"non-Amazon" elements. By adding the spans to the Amazon elements, I'm making
the Amazon JScript behave similarly to the other JScript for GoogleJackets,
OpenLibraryCovers, etc. I think it creates consistency rather than regression.

When you said that you got 1 "no cover image available" in master, I assume
that also meant that the local cover didn't appear. I think that's a much more
critical issue than having 2 "no cover image available" appear alongside an
existing local cover image.

That said, I agree that it doesn't make sense to show "No cover image
available" if there is a cover image available, but there are currently no
checks in place for that. I think that deserves a bug of its own. 

--

Unfortunately, I don't think the code snippet that you provide would actually
work, because that would just test for the system preference and not the actual
presence of cover images. If you had  GoogleJackets and OPACAmazonCoverImages
turned on, you would never get a "no cover image available" even when you
should.

One idea (purely JScript-based):

1) Add a class to each cover art span (or possibly use the existing thumbnail
class for the img)
2) Then use a JScript function to loop through each a.p1 (which seems to be
unique...although we could always add a cover art class to it as well). 
3) If span.cover_art (or img.thumbnail) exists, remove all span.no-image
elements within that a.p1 element. 
4) If span.cover_art (or img.thumbnail) does not exist AND count(span.no-image)
> 1, remove every span.no-image after the first instance within that a.p1
element. 

I don't think we could do it solely in the templates, because the existence of
cover art is going to vary depending on several other JScript functions which
run independently of each other. 

Maybe if we re-wrote all the cover art functions (and ideally allowed
librarians to rank the providers so that you don't have more than cover image
showing for an item), but yes...I think that's a different bug. 

If I've managed to convince you, please change back to Signed Off (or even
Passed QA :P)

-- 
You are receiving this mail because:
You are watching all bug changes.