[Bug 10584] New: Hide OPAC bibilo details if all items are hidden or there are no items.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 Bug ID: 10584 Summary: Hide OPAC bibilo details if all items are hidden or there are no items. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard@myacpl.org Reporter: mtompset@hotmail.com Using the OpacHiddenItems systempreference, items can be hidden. However, it looks strange to have a biblio entry in the OPAC if all the items are hidden or there are no items. In this case, hide the biblio too. Test ==== 1) Find a biblio with multiple item records across multiple branches. 2) View it in OPAC. 3) In the staff client hide one of the branches using OpacHiddenItems. 4) Refresh the OPAC details. There should be less, because of the hidden branch. 5) In the staff client hide all of the branches (e.g. homebranch: [BR01,BR02]) 6) Refresh the OPAC details. A biblio entry with no items will be displayed. 7) In the staff client enter a dummy biblio record, with no items. 8) View the OPAC details for that biblio. A biblio entry with no items will be displayed. NOTE: There is a tiny scope creep, in that a silent warning hazard for the biblionumber was also corrected. (forgive me) 9) Go to .../cgi-bin/koha/opac-detail.pl?biblionumber= with no number entered. There should be a 404 output page. 10) Check the opac error log file. There should be a warning related to the int(undef) 11) Apply the patch. 12) Go to .../cgi-bin/koha/opac-detail.pl?biblionumber= with no number entered. There should be a 404 output page. 13) There should be no new warning. 14) Go to the dummy biblio that you entered (.../cgi-bin/koha/opac-detail.pl?biblionumber=#####). There should be a 404 output page. 15) Go back to the initial biblionumber (.../cgi-bin/koha/opac-detail.pl?biblionumber=#####). There should be a 404 output page. Displaying 404.pl is not the best or correct solution (see bug 2318's comment discussion), but it is sufficient, until that gets corrected. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|oleonard@myacpl.org |mtompset@hotmail.com Summary|Hide OPAC bibilo details if |Hide OPAC bibilo details if |all items are hidden or |all items are hidden. |there are no items. | -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 --- Comment #1 from M. Tompsett <mtompset@hotmail.com> --- As per a discussion with jcamins, hiding biblios with no items is a bad thing (tm). Only going to touch hidden items case. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 --- Comment #2 from M. Tompsett <mtompset@hotmail.com> --- Created attachment 19614 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19614&action=edit If there is at least one item and every item is hidden, hide the biblio entry. REVISED Test ============ 1) Find a biblio with multiple item records across multiple branches. 2) View it in OPAC. 3) In the staff client hide one of the branches using OpacHiddenItems. 4) Refresh the OPAC details. There should be less, because of the hidden branch. 5) In the staff client hide all of the branches (e.g. homebranch: [BR01,BR02]) 6) Refresh the OPAC details. A biblio entry with no items will be displayed. 7) In the staff client enter a dummy biblio record, with no items. 8) View the OPAC details for that biblio. A biblio entry with no items will be displayed. NOTE: There is a tiny scope creep, in that a silent warning hazard for the biblionumber was also corrected. (forgive me) 9) Go to .../cgi-bin/koha/opac-detail.pl?biblionumber= with no number entered. There should be a 404 output page. 10) Check the opac error log file. There should be a warning related to the int(undef) 11) Apply the patch. 12) Go to .../cgi-bin/koha/opac-detail.pl?biblionumber= with no number entered. There should be a 404 output page. 13) There should be no new warning. 14) Go to the dummy biblio that you entered (.../cgi-bin/koha/opac-detail.pl?biblionumber=#####). There should be an empty items section. 15) Go back to the initial biblionumber (.../cgi-bin/koha/opac-detail.pl?biblionumber=#####). There should be a 404 output page. Displaying 404.pl is not the best or correct solution (see bug 2318's comment discussion), but it is sufficient, until that gets corrected. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 Srdjan Jankovic <srdjan@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |srdjan@catalyst.net.nz --- Comment #3 from Srdjan Jankovic <srdjan@catalyst.net.nz> --- 1. +my $sth = $dbh->prepare("SELECT * FROM items WHERE biblionumber=?;"); +$sth->execute($biblionumber); + +my @itemsmatchingbiblionumber; +my $matchingitem = $sth->fetchrow_hashref; +while ($matchingitem) { + push @itemsmatchingbiblionumber,$matchingitem; + $matchingitem = $sth->fetchrow_hashref; +} is perhaps better written as my $itemsmatchingbiblionumber = $dbh->selectall_arrayref($sql, { Slice => {}}, $biblionumber) 2. Database queries should all be placed in modules (probably C4/Items.pm for this one, maybe theres even something similar already there) so they can be tested 3. There should be a check if ($biblionumber) { get the items etc } so we do not make database calls in vain -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #19614|0 |1 is obsolete| | --- Comment #4 from M. Tompsett <mtompset@hotmail.com> --- Created attachment 19712 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19712&action=edit If there is at least one item and every item is hidden, hide the biblio entry. Applied Srdjan Jankovic's suggestions, and came up with a cleaner patch. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |ASSIGNED --- Comment #5 from M. Tompsett <mtompset@hotmail.com> --- Oops! Biblioitemnumber != Biblionumber. Back to square one. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #19712|0 |1 is obsolete| | --- Comment #6 from M. Tompsett <mtompset@hotmail.com> --- Created attachment 19720 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19720&action=edit If there is at least one item and every item is hidden, hide the biblio entry. There's a sufficient functional call: GetItemsInfo. Nicely revised patch. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 Srdjan Jankovic <srdjan@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 Srdjan Jankovic <srdjan@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #19720|0 |1 is obsolete| | --- Comment #7 from Srdjan Jankovic <srdjan@catalyst.net.nz> --- Created attachment 19737 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19737&action=edit [SIGNED-OFF] Bug 10584 - Hide OPAC biblio details if all items are hidden If there are items for a given biblio number, and they are all hidden, then biblio needs to be hidden. If the biblio needs to be hidden, this is done by setting the biblionumber to 0, which triggers the same output as if the biblionumber does not exist. Signed-off-by: Srdjan <srdjan@catalyst.net.nz> -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 --- Comment #8 from Srdjan Jankovic <srdjan@catalyst.net.nz> --- Not quite sure how useful this is, if all items are hidden there will be no entry on the search results anyway. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 --- Comment #9 from M. Tompsett <mtompset@hotmail.com> --- In reply to your inquiry about the usefulness, this prevents data mining on private collections of items. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 --- Comment #10 from Srdjan Jankovic <srdjan@catalyst.net.nz> --- So much evil in this world... -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 Nicole C. Engard <nengard@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nengard@gmail.com -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #19737|0 |1 is obsolete| | --- Comment #11 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 20824 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=20824&action=edit Bug 10584 - Hide OPAC biblio details if all items are hidden If there are items for a given biblio number, and they are all hidden, then biblio needs to be hidden. If the biblio needs to be hidden, this is done by setting the biblionumber to 0, which triggers the same output as if the biblionumber does not exist. Signed-off-by: Srdjan <srdjan@catalyst.net.nz> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Passes koha-qa.pl, works as advertised. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 Galen Charlton <gmcharlt@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |In Discussion CC| |gmcharlt@gmail.com --- Comment #12 from Galen Charlton <gmcharlt@gmail.com> --- I have concerns about the implementation of this -- in particular, for a bib that is /not/ going to end up hidden, the acts of retrieving all of the items and checking which ones are hidden occur /twice/. In my opinion, this is likely to impose too high of a performance penalty for typical OPACs, which don't have high numbers of hidden items. I suggest revising the patch so that rather than adding a call to GetHiddenItems(), the bailing-out occurs after the original call to GetHiddenItems(). Additional refactoring might be called for (but as the topic of a separate bug) to minimize the processing gets wasted whether or not the bib ends up hidden. Also, I'm not a fan of the notion of using 0 as a "magic" biblionumber -- to bail out, just issue the redirect. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 --- Comment #13 from M. Tompsett <mtompset@hotmail.com> --- (In reply to Galen Charlton from comment #12)
I have concerns about the implementation of this -- in particular, for a bib that is /not/ going to end up hidden, the acts of retrieving all of the items and checking which ones are hidden occur /twice/.
After looking for GetHiddenItems and GetItemsInfo, I see what you mean by twice.
In my opinion, this is likely to impose too high of a performance penalty for typical OPACs, which don't have high numbers of hidden items.
This is the opac-details.pl page, I have a hard time imagining tens of thousands of items. Daily Newspapers perhaps? 2N is still order N, but I do agree there is room for optimization.
Also, I'm not a fan of the notion of using 0 as a "magic" biblionumber -- to bail out, just issue the redirect.
I'm not a fan of multiple exits, but you have a valid point. Though, the magic bullet is already used in the case that no biblionumber is passed.
I suggest revising the patch so that rather than adding a call to GetHiddenItems(), the bailing-out occurs after the original call to GetHiddenItems().
The code is such that I can move and reuse the @hiddenitems in my patched code, and dump @items2hide. This reduces that to a single call. My concern is more about the GetItemsInfo double call, now that you pointed it out. I'm wondering about the "change back when I've fixed request.pl" comment from 2002. Can I effectively dump @itemsmatchingbiblionumber, and move @all_items into the patched area for use there too, deleting the comment? Or should I stick with a safer pushing the contents of @itemsmatchingbiblionumber to the @all_items, instead of the second call, so as to retain a hint of what the comment might be talking about?
Additional refactoring might be called for (but as the topic of a separate bug) to minimize the processing gets wasted whether or not the bib ends up hidden.
I think a single line of code, "return () if (! $yaml =~ /\S/ );" or "return () unless $hidingrules;", in the GetHiddenItems code may be a tiny optimization of note, but agree that is best suited for another bug report. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #20824|0 |1 is obsolete| | --- Comment #14 from M. Tompsett <mtompset@hotmail.com> --- Created attachment 20892 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=20892&action=edit Bug 10584 - Hide OPAC biblio details if all items are hidden If there are items for a given biblio number, and they are all hidden, then biblio needs to be hidden. If the biblio needs to be hidden, it immediately redirects to a 404.pl page, just as if the biblionumber does not exist. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Needs Signoff --- Comment #15 from M. Tompsett <mtompset@hotmail.com> --- I believe I addressed Galen's issues. Though, perhaps the "keep the comment entact" philosophy may be flawed. I'll rework if that is a problem. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 --- Comment #16 from Srdjan Jankovic <srdjan@catalyst.net.nz> --- I don't mean to be a pain, but array copy seems unnecessary. Why not just @all_items = GetItemsInfo( $biblionumber ); if (scalar @hiddenitems == scalar @all_items ) -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #20892|0 |1 is obsolete| | --- Comment #17 from M. Tompsett <mtompset@hotmail.com> --- Created attachment 20893 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=20893&action=edit Bug 10584 - Hide OPAC biblio details if all items are hidden If there are items for a given biblio number, and they are all hidden, then biblio needs to be hidden. If the biblio needs to be hidden, it immediately redirects to a 404.pl page, just as if the biblionumber does not exist. Arrays used to represent all the items were relocated and used, added if they didn't exist. Arrays representing the hidden items were relocated and used if they existed, added if they didn't exist. Upon debugging the opac-MARCdetail.pl modification, it was discovered the reason getHiddenItems was failing was because 'use YAML qw/Load/;' was not mentioned in C4::Items, and other libraries were triggering the loading of YAML to compensate for opac-detail.pl and opac-ISBDdetail.pl files. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=10872 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=10876 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #20893|0 |1 is obsolete| | --- Comment #18 from M. Tompsett <mtompset@hotmail.com> --- Created attachment 21068 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=21068&action=edit Bug 10584 - Hide OPAC biblio details if all items are hidden If there are items for a given biblio number, and they are all hidden, then biblio needs to be hidden. If the biblio needs to be hidden, it immediately redirects to a 404.pl page, just as if the biblionumber does not exist. Arrays used to represent all the items were relocated and used, added if they didn't exist. Arrays representing the hidden items were relocated and used if they existed, added if they didn't exist. Upon debugging the opac-MARCdetail.pl modification, it was discovered the reason getHiddenItems was failing was because 'use YAML qw/Load/;' was not mentioned in C4::Items, and other libraries were triggering the loading of YAML to compensate for opac-detail.pl and opac-ISBDdetail.pl files. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 --- Comment #19 from M. Tompsett <mtompset@hotmail.com> --- I set the depends on, because bug 10872 just fixes that one line in C4::Items which is clear enough to eyeball. See GetHiddenItems() call to YAML::Load and ask yourself, where is it required or used? opac-detail.pl and opac-ISBDdetail.pl both load something which uses or requires YAML, but opac-MARCdetail.pl has a smaller use list, which does not. This fixes the entire block displaying. Bug 10876 is a partial display issue for opac-MARCdetail.pl Test Before Apply ================= Somehow part of an earlier version of this made it into master. This means that opac-details.pl will generate a 404.pl page following the "Test After Apply" steps, but the other two URLs will not. 1) Log into staff client and blank OPACHiddenItems 2) Open a browser to the OPAC. 3) Find something that has multiple items (e.g. same book in two branches) 4) Click on the link (e.g. demo.library.kohasystem.ca/cgi-bin/koha/opac-detail.pl?biblionumber=33158) 5) Click on "Marc view", and the same number of items should be displayed. 6) Click on "ISBD view", and an entry should come up. 7) In the staff client hide all the items (e.g. homebranch: [DAV,MNL]) 8) Click on the "Normal View", and you should get a 404.pl page. -- this is due to the push that was already done. 9) Paste in the opac-MARCdetail.pl url (e.g. demo.library.kohasystem.ca/cgi-bin/koha/opac-MARCdetail.pl?biblionumber=33158) Items should display as before. :( 10) Paste in the opac-ISBDdetail.pl url (e.g. demo.library.kohasystem.ca/cgi-bin/koha/opac-ISBDdetail.pl?biblionumber=33158) Page should be as before. 11) Click the logo, and redo the initial search 12) Nothing related to the biblionumber used should come up. Test After Apply ================ 1) Log into staff client and blank OPACHiddenItems 2) Open a browser to the OPAC. 3) Find something that has multiple items (e.g. same book in two branches) 4) Click on the link (e.g. demo.library.kohasystem.ca/cgi-bin/koha/opac-detail.pl?biblionumber=33158) 5) Click on "Marc view", and the same number of items should be displayed. 6) Click on "ISBD view", and an entry should come up. 7) In the staff client hide all the items (e.g. homebranch: [DAV,MNL]) 8) Click on the "Normal View", and you should get a 404.pl page. 9) Paste in the opac-MARCdetail.pl url (e.g. demo.library.kohasystem.ca/cgi-bin/koha/opac-MARCdetail.pl?biblionumber=33158) A 404.pl page should be given. IF NOT, YOU FORGOT TO TEST AND APPLY BUG 10872. 10) Paste in the opac-ISBDdetail.pl url (e.g. demo.library.kohasystem.ca/cgi-bin/koha/opac-ISBDdetail.pl?biblionumber=33158) A 404.pl page should be given. 11) Click the logo, and redo the initial search 12) Nothing related to the biblionumber used should come up. This bug fixes the full hidden case. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 Mason James <mtj@kohaaloha.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 Mason James <mtj@kohaaloha.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #21068|0 |1 is obsolete| | --- Comment #20 from Mason James <mtj@kohaaloha.com> --- Created attachment 21073 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=21073&action=edit Bug 10584 - Hide OPAC biblio details if all items are hidden If there are items for a given biblio number, and they are all hidden, then biblio needs to be hidden. If the biblio needs to be hidden, it immediately redirects to a 404.pl page, just as if the biblionumber does not exist. Arrays used to represent all the items were relocated and used, added if they didn't exist. Arrays representing the hidden items were relocated and used if they existed, added if they didn't exist. Upon debugging the opac-MARCdetail.pl modification, it was discovered the reason getHiddenItems was failing was because 'use YAML qw/Load/;' was not mentioned in C4::Items, and other libraries were triggering the loading of YAML to compensate for opac-detail.pl and opac-ISBDdetail.pl files. Signed-off-by: Mason James <mtj@kohaaloha.com> -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 Mason James <mtj@kohaaloha.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mtj@kohaaloha.com --- Comment #21 from Mason James <mtj@kohaaloha.com> --- patch works as advertised, and looks good :) -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #21073|0 |1 is obsolete| | --- Comment #22 from Jonathan Druart <jonathan.druart@biblibre.com> --- Created attachment 21076 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=21076&action=edit Bug 10584 - Hide OPAC biblio details if all items are hidden If there are items for a given biblio number, and they are all hidden, then biblio needs to be hidden. If the biblio needs to be hidden, it immediately redirects to a 404.pl page, just as if the biblionumber does not exist. Arrays used to represent all the items were relocated and used, added if they didn't exist. Arrays representing the hidden items were relocated and used if they existed, added if they didn't exist. Upon debugging the opac-MARCdetail.pl modification, it was discovered the reason getHiddenItems was failing was because 'use YAML qw/Load/;' was not mentioned in C4::Items, and other libraries were triggering the loading of YAML to compensate for opac-detail.pl and opac-ISBDdetail.pl files. Signed-off-by: Mason James <mtj@kohaaloha.com> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA CC| |jonathan.druart@biblibre.co | |m Depends on| |10872 QA Contact| |jonathan.druart@biblibre.co | |m --- Comment #23 from Jonathan Druart <jonathan.druart@biblibre.com> --- Not sure a redirect to 404 is the better thing to do but it is the existing behavior. Marked as Passed QA. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 --- Comment #24 from M. Tompsett <mtompset@hotmail.com> --- I believe Jonathan is referring to the optimization of if there is no biblionumber then redirect to 404.pl that has been added. No biblionumber means it will fail to get a record, which means it will redirect to 404.pl anyways. The immediate redirect to 404.pl is an optimization, because it makes no sense to run a bunch of function calls just to end up going to 404.pl anyways. If it should give a meaningful error, the optimization makes it possible to do it sooner rather than later -- in another bug. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |10876 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomascohen@gmail.com -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also|http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=10876 | -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 Galen Charlton <gmcharlt@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|minor |enhancement --- Comment #25 from Galen Charlton <gmcharlt@gmail.com> --- Marking this as an enhancement -- it falls on the bug/enhancement boundary, but on balance, this change in behavior leans a bit more towards the latter IMO. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 Galen Charlton <gmcharlt@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to Master --- Comment #26 from Galen Charlton <gmcharlt@gmail.com> --- Pushed to master. Thanks, Mark! -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=10876 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 Sophie MEYNIEUX <sophie.meynieux@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sophie.meynieux@biblibre.co | |m --- Comment #27 from Sophie MEYNIEUX <sophie.meynieux@biblibre.com> --- What is a bit strange is that when you make a search without results you've got a "No results found!" answer. But if the search finds only one biblio matching, but all items are hidden, then a 404 error page is displaid. OPAC users don't understand the difference and for them 404 error page means the system fails, not that there are no results to their search. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 --- Comment #28 from M. Tompsett <mtompset@hotmail.com> --- Oooo... sounds like a test case missed. Because the hidden item wouldn't be listed in a search, so there would be no way to go to the details page. And looking for the page of a hidden item is like looking for a biblio that is non-existant (404.pl). However, Koha when there is only one result automatically goes to the detail page. I'll look into this. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=11432 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=11489 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also|http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=11432 | -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org