http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9737
David Cook <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |In Discussion --- Comment #11 from David Cook <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
