September 2018 - Koha-bugs - lists.koha-community.org

[Bug 5070] zh-Hans-TW languages is not working at all!
by bugzilla-daemon＠bugs.koha-community.org 15 Sep '18

15 Sep '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5070 Margaret <margaret(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |margaret(a)bywatersolutions.c | |om -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 15 Sep '18

15 Sep '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 Koha Team Lyon 3 <koha(a)univ-lyon3.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #52 from Koha Team Lyon 3 <koha(a)univ-lyon3.fr> --- Sorry, but for me it doesn't work... It set IndependentBranches to "no" UseBranchTransferLimits is set to "enforce library transfer limits based on itemtype" In cgi-bin/koha/admin/branch_transfer_limits.pl In the table of library A and in the tab of itemtypeA : I uncheck "allow transfer" in the line concerning "libraryB". I checkout a book (itemtypeA) from libraryB in LibraryB and then change of library to checkin in libraryA. When I checkin this book in libraryA, I just have the message "This item needs to be transferred to Budaka". If I have well understood, I should have a message that tells me that this book couldn't be checkin in libraryA... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10662] Build OAI-PMH Harvesting Client
by bugzilla-daemon＠bugs.koha-community.org 15 Sep '18

15 Sep '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662 --- Comment #192 from David Cook <dcook(a)prosentient.com.au> --- Ed did mention that "Send" request is a bit confusing and I suggested that "Submit" request might be less confusing. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14385] Extend OpacHiddenItems to allow specifying exempt borrower categories
by bugzilla-daemon＠bugs.koha-community.org 15 Sep '18

15 Sep '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14385 Joy Nelson <joy(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #78657|0 |1 is obsolete| | --- Comment #172 from Joy Nelson <joy(a)bywatersolutions.com> --- Created attachment 78828 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=78828&action=ed… Bug 14385: Squash of a lot of patches rebased - Added missing GetHiddenItems parameter change case Without this prove t had a failure. - Always use mocks, not set_preference - Tweaks so t/db_dependent/00-strict.t passes There was a typo botcat vs borcat and borrowernumber was never defined. Grabbing from userenv, like other code does. - Tweak t/db_dependent/Items.t to fully test changes This will test all the if structures fully in GetHiddenItemnumbers. prove t/db_dependent/Items.t - Tweak borrower category code $borrower->{categorycode} on a Koha::Patron is not the same as $borrower->categorycode. Fixed error. - Search was returning URLS for wrong interface There was one search context place wrong. Changed it to $is_opac as the logic for setting $is_opac was modified correctly. - Corrected issues with category code. When a user isn't logged in, $borrower is undef and causes error when determining category code. Added conditional check. - Properly trigger all changes in C4/Search.pm - Fix QA Test tool failures C4/Search.pm had some tabs. - Add some commenting to make sense of logic - Refactor EmbedItemsInMarcBiblio parameters to hashref - Trigger GetMarcBiblio's EmbedItemsInMarcBiblio call. prove t/db_dependent/Items.t - Add missing test to trigger Koha/BiblioUtils/Iterator change - Add borrower category overrides These files generally add borcat parameter to GetMarcBiblio. Others might include correction of filtering of items (opac-basket), or a comment as to why no changes were done (opac-search). In the case of opac-search, correcting the first FIXME will likely correct the OpacHiddenItems issues on tags. As such, that is beyond this bugs scope. Some code had loop optimizations and fixes made, like a 'next unless $record' when the biblio shouldn't even be in the list. - Modify opac-ISBDdetail and opac-MARCdetail Both files had similar logic. They were rearranged and optimized, so that both files would have practically identical initial blocks of code. Optimizations were possible, because GetMarcBiblio returns a filtered record, so that there is no double call (once in the opac-### file and once in GetMarcBiblio) to GetHiddenItemnumbers. - Fix hiding in opac-tags opac/opac-tags.pl was not properly hiding. There is currently one known bug associated with tags left. If you have two biblios tagged by different people with the same tag, the opac-search will show the one you tagged that is supposed to be hidden, because tag searches work differently than regular searches. This is beyond the scope of this bug. See the FIXME's in opac/opac-search.pl - Trigger the C4::ILSDI::Services changes prove t/db_dependent/ILSDI_Services.t - Added missing 'my' - Test C4/Labels/Label.pm changes - Improve C4::Record::marcrecord2csv test cases - Corrected opac-details searchResult call - Fix breaking issues constraint in ITerator test - Fix ILSDI_Services test when clubs with branch exist - Rebased again! The test plan is in comment #112 last I checked. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14385] Extend OpacHiddenItems to allow specifying exempt borrower categories
by bugzilla-daemon＠bugs.koha-community.org 15 Sep '18

15 Sep '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14385 Joy Nelson <joy(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #78656|0 |1 is obsolete| | --- Comment #171 from Joy Nelson <joy(a)bywatersolutions.com> --- Created attachment 78827 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=78827&action=ed… Bug 14385: Followup: changes to sysprefs.sql and atomicupdate Run updatedatabase.pl when testing Sponsored-by: Catalyst IT Signed-off-by: Mark Tompsett <mtompset(a)hotmail.com> Signed-off-by: Aleisha Amohia <aleishaamohia(a)hotmail.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14385] Extend OpacHiddenItems to allow specifying exempt borrower categories
by bugzilla-daemon＠bugs.koha-community.org 15 Sep '18

15 Sep '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14385 Joy Nelson <joy(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #78655|0 |1 is obsolete| | --- Comment #170 from Joy Nelson <joy(a)bywatersolutions.com> --- Created attachment 78826 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=78826&action=ed… Bug 14385 Followup: C4::Borrowers not found GetMember is in C4::Members, not C4::Borrowers Signed-off-by: Claire Gravely <c.gravely(a)arts.ac.uk> Signed-off-by: Mark Tompsett <mtompset(a)hotmail.com> Signed-off-by: Aleisha Amohia <aleishaamohia(a)hotmail.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14385] Extend OpacHiddenItems to allow specifying exempt borrower categories
by bugzilla-daemon＠bugs.koha-community.org 15 Sep '18

15 Sep '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14385 Joy Nelson <joy(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #78654|0 |1 is obsolete| | --- Comment #169 from Joy Nelson <joy(a)bywatersolutions.com> --- Created attachment 78825 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=78825&action=ed… Bug 14385: Extend OpacHiddenItems to allow specifying exempt borrower categories Edit: Fixing merge conflicts in - t/db_dependent/Items.t - t/db_dependent/Search.t - C4/Search.pm Changes the API for calling GetHiddenItems and all the places in the code that call it. This is to allow borrower categories to be passed in. Adds an OpacHiddenItemsExceptions syspref to allow certain borrower categories to be able to see items, even if they are marked hidden by OpacHiddenItems To test: 1) Make two borrowers, one in a category that should see everything (ie Adult), and another in a category that should only see certain things (ie Adult - exceptions) 2) Add the borrower that can see everything (the Adult) to OpacHiddenItemsExceptions 3) To the OpacHiddenItems syspref, add an item type (ensure that you have some records that fall under this type in your library). 4) Log in as the borrower that should only see certain things (Adult - exception) 5) Do a search, filtered to show records which are the item type that you specified in the OpacHiddenItems syspref. No records should show for this borrower as this item type is hidden to them. 6) Log in as the borrower that should see everything (Adult) 7) Do the same search. There should be results from this search, as this borrower category has been specified as an exception to the hidden items Signed-off-by: Claire Gravely <c.gravely(a)arts.ac.uk> Signed-off-by: Mark Tompsett <mtompset(a)hotmail.com> Signed-off-by: Aleisha Amohia <aleishaamohia(a)hotmail.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14385] Extend OpacHiddenItems to allow specifying exempt borrower categories
by bugzilla-daemon＠bugs.koha-community.org 15 Sep '18

15 Sep '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14385 Joy Nelson <joy(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15565] Place multiple holds at once for the same record
by bugzilla-daemon＠bugs.koha-community.org 15 Sep '18

15 Sep '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15565 Lisette Scheer <lisetteslatah(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #78720|0 |1 is obsolete| | --- Comment #123 from Lisette Scheer <lisetteslatah(a)gmail.com> --- Created attachment 78823 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=78823&action=ed… Bug 15565: Allow up to (and including) maxreserves number of OPAC item levelholds This commit implements changes to opac-reserve.tt and opac-reserve.pl. 1. The change to opac-reserve.tt JS fixes the total_requested() function which returns an output which is always 2 digits higher than the actual number of selected item checkboxes. i.e. if the 'maxreserves' syspref (limit for the overall number of reserves allowed by a user) is 4 and a user has no previous holds and ticks 3 item checkboxes and submits the form. The 'Maximum number of reserve exceded.' popup message is displayed, however as they have selected 3 items for reservation this is less than the maxreserves value of 4. The popup is displayed because total_requested() JS function is returning 5 (i.e. 2 on top of the actual number of requested holds). This commit usbtracts 2 from the number of holds calculated by total_requested() so that the accurate number of requested holds is being used to determine whether or not to display the excess holds popup. 2. When the 'Holds per record (count)' (circulation rule) and 'maxreserves' syspref are the same value (e.g. 4) you can tick 4 item checkboxes in opac-reserve.pl and submit the form. The form will submit successfully and to the user everything looks to have worked however the holds will not be successfully created. This is because after the form is submitted to opac-reserve.pl a check is done: If 'number of submitted hold requests' + 'number of previous existing holds' greater than or equal to maxreserves syspref then set the variable '$canreserve' to 0. If the $canreserve variable is 0 the form will submit, no warning/error message is displayed to the user but the holds are not created. Users should be able to place 4 holds if the maxreserves syspref is 4 (just not more than 4 holds). This commit changes this check to: If 'number of submitted hold requests' + 'number of previous existing holds' greater than maxreserves syspref then set the variable '$canreserve' to 0.. i.e. notice we only check for greater than (not equal to). Which solves the bug of the form submitting and no holds being created when the maxreserves syspref and 'Holds per record (count)' (circulation rule) are the same. Test plan (in two parts to test fix #1 and #2 (above)): Test plan for fix #1: 1. Apply all patches on this bug report (15565) and follow and confirm the feature works as described in the test plan in the first commit 2. Set the 'maxreserves' syspref to 3 (and 'Holds per record (count)' (circulation rule) to 5) 3. Ensure your logged in patron account has no existing reserves 4. In the OPAC go to a biblio page with 3 or more items 5. In the reservation page (opac-reserve.pl) for that biblio select 2 item checkboes to place 2 item level holds and notice the 'Maximum number of reserve exceded.' popup message is displayed. As the maxreserves syspref value is 3 you should be able to place 2 holds without exceeding that value 6. Apply this patch 7. Repeat step 5 and notice the form submits without the exceeding popup message and the holds are successfully placed. Test plan for fix #2: 1. Apply all patches attached to this bug report (bug 15565) and perform the test plan in the first commit and verify it works. 2. Set your 'Holds per record (count)' (circulation rule) and 'maxreserves' syspref to the same value 3 3. Go to a biblio in the OPAC with 3 or more items 4. In the opac-reserve.pl reservation interface for that biblio tick 3 item checkboxes to place 3 item level holds and submit the form. 5. Notice the form submits and no warning/error message is displayed 6. In the opac user summary page that is displayed after the reserve form is submitted notice the holds are not displayed this is because they have not been placed 7. Apply this patch 8. Repeat step 4 and 5 and notice the holds have been successfully placed and are displayed in your opac user summary page. Sponsored-By: Brimbank Library Signed-off-by: Lisette Scheer <lisetteslatah(a)gmail.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15565] Place multiple holds at once for the same record
by bugzilla-daemon＠bugs.koha-community.org 15 Sep '18

15 Sep '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15565 Lisette Scheer <lisetteslatah(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #78719|0 |1 is obsolete| | --- Comment #122 from Lisette Scheer <lisetteslatah(a)gmail.com> --- Created attachment 78822 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=78822&action=ed… Bug 15565: Changed the retrieval of selected hold pickup branch in opac-reserve.pl Previously the selected branch dropdown value was not being successfully retrieved in opac-reserve.pl, this resulted in opac holds being placed with no pickup branch being set. Consequently as no branch was associated with the hold an Ajax error was thrown when viewing the holds-table in the patron page in the staff client. This commit successfully retrieves the selected branch value and so fixing the Ajax error. Test plan: 1. Apply all patches on bug report 15565 except this commit 2. Place a hold(s) from opac-reserve.pl. 3. Go to your opac patron summary page (opac-user.pl) and notice although the holds are successfully displayed they have no 'Pickup location' value 4. Go to the patron page in the staff client and click on the 'Hold(s)' tab and notice a popup explaining the datatable Ajax error is loaded 5. Apply this patch 6. Repeat step 3 noticing this time in the opac-user.pl a 'Pickup location' is displayed for the hold you just created. 6. Repeat step 4 and notice the hold datatable is successfully loaded and populated without an Ajax error popup being loaded. Sponsored-By: Brimbank Library -- You are receiving this mail because: You are watching all bug changes.

1 0