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

[Bug 15184] Ability to duplicate existing order lines to a given basket
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '18

30 Aug '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15184 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #43 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- I quite like the mechanics of this! Some questions: 1) Why another checkbox on the last step? (new from copy > search > select orders > copy order form > more checkboxes) 2) How do you handle items? Does it depend on what was set for the original order or is the setting for the current basket taken into account as well? 3) comment#42 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15184] Ability to duplicate existing order lines to a given basket
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '18

30 Aug '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15184 --- Comment #42 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to Jonathan Druart from comment #39) > Created attachment 78283 [details] [review] > Bug 15184: Add users ? > > We certainly do not want this patch. What about users that are notified > on receiving? > > Sponsored-by: BULAC - http://www.bulac.fr/ > > Signed-off-by: Josef Moravec <josef.moravec(a)gmail.com> Could we make copying the users a checkbox or similar on the copy order form with default off? That way we might get us the best and most flexible behaviour. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13618] Prevent XSS in the Staff Client and the OPAC
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '18

30 Aug '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13618 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |21293 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21293 [Bug 21293] Display of housebound delivery information broken by Bug 13618 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14723] Additional delivery notes to messages
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '18

30 Aug '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14723 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #62138|0 |1 is obsolete| | --- Comment #27 from Nick Clemens <nick(a)bywatersolutions.com> --- Created attachment 78313 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=78313&action=ed… Bug 14723: Additional delivery notes to messages This patch adds additional delivery notes to messages in message queue as there can be multiple reasons for a delivery to fail. Currently in message_queue we are given only two delivery statuses for messages, "sent" and "failed". When the status becomes failed, we have no idea why it fails. This feature can be useful with SMS gateway providers. Many SMS gateways inform the application the reason of SMS delivery failure. With this feature, this information can now be stored. As well as for emails, instead of simply logging failures, we can now store the reason of failure directly into the message row of message_queue. Test plan: 1. Enable EnhancedMessagingPreferences syspref 2. Find a borrower with notices at members/notices.pl 3. Observe that there is no column for Delivery notes 4. Apply patch and run the given database update 5. Repeat step 1. 6. Observe that there is now a column for Delivery notes -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14723] Additional delivery notes to messages
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '18

30 Aug '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14723 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13618] Prevent XSS in the Staff Client and the OPAC
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '18

30 Aug '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13618 --- Comment #247 from Nick Clemens <nick(a)bywatersolutions.com> --- (In reply to Jonathan Druart from comment #245) > Created attachment 78274 [details] [review] > Bug 13618: (follow-up) Add html filters to all the variables Followup pushed to master -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 21194] New: East analytics show wrong title when linking to host
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '18

30 Aug '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21194 Bug ID: 21194 Summary: East analytics show wrong title when linking to host Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To recreate: 1 - Enable easy analytics 2 - Find a record, say "Pikachu: A life in letters" 3 - Click 'Edit->Link to host item' 4 - Enter a barcode from a different record say "Ash: why was he compelled to catch them all?" 5 - Note the message after linking is 'The item has successfully been linked to Pikachu: a life in letters' -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

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

30 Aug '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15565 Alex Buckley <alexbuckley(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- 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 30 Aug '18

30 Aug '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15565 --- Comment #91 from Alex Buckley <alexbuckley(a)catalyst.net.nz> --- Created attachment 78305 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=78305&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 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11297] Add support for custom PQF attributes for Z39.50 server searches
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '18

30 Aug '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11297 --- Comment #83 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- [Koha] Course reserves widget -- You are receiving this mail because: You are watching all bug changes.

1 0