June 2020 - Koha-bugs - lists.koha-community.org

[Bug 25344] New: Add support for circulation status 10 ( item in transit )
by bugzilla-daemon＠bugs.koha-community.org 18 Aug '20

18 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25344 Bug ID: 25344 Summary: Add support for circulation status 10 ( item in transit ) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com We should support the SIP2 "circulation status" value 10, "in transit between library locations" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 20154] New: stay in the open tab when going into edit mode
by bugzilla-daemon＠bugs.koha-community.org 17 Aug '20

17 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20154 Bug ID: 20154 Summary: stay in the open tab when going into edit mode Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: patrick.robitaille(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hi, When we consult an authority in the authorities module, it would be nice too stay in the tab that are actually open when we switch to edit mode. Currently when you consult an authority notice and you open a tab (for exemple the tab 2) if you switch to the edit mode we will automaticaly arrive at the record in edit mode but with tab "0" open. Patrick. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 18947] New: Active Directory LDAP authentication broken
by bugzilla-daemon＠bugs.koha-community.org 15 Aug '20

15 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18947 Bug ID: 18947 Summary: Active Directory LDAP authentication broken Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: helpdesk(a)neci.edu QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Commit 68c365ea8ab536a85d92d3769b0bbaa0e1691116 introduced the following line in Auth_with_ldap.pm: $ldap->{anonymous_bind} = 1 unless $ldapname && $ldappassword; There is no comment in the code or the Git commit log as to why. This change silently overrides the settings in koha-conf.xml and causes a previously functional setup with LDAP authentication against Active Directory to fail unless koha-conf.xml defines values for <user> and <pass>. As user and pass are only used if auth_by_bind and anonymous_bind are both false, their values should not come into play in the other cases. Prior to this change, KOHA would bind against AD with the user supplied credentials, as expected. With the change, KOHA attempts an anonymous bind and then tries to search for the supplied user name. As there was no valid bind in place, AD rejects the attempt. Workaround: enter some value for <user> and <pass> in the ldapserver configuration block. These do not have to be real credentials as KOHA will not attempt to use them now that auth_by_bind has priority again. Note: there is an apparent duplicate attempt to do the same further down, by setting $config{anonymous} to ($ldapname and $ldappassword) ? 0 : 1, although that key is not used anywhere in Auth_by_ldap.pm -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 19780] New: Actual price is not updated after it has been amended post receiving an order
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '20

14 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19780 Bug ID: 19780 Summary: Actual price is not updated after it has been amended post receiving an order Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: alexbuckley(a)catalyst.net.nz Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org The steps to replicate this bug are as follows: 1. Create an order and set the actual price to 9.00 2. Receieve the order changing the actual price value to 10.00. This is to represent the librarian accidentally entering in a different actual price value at receival. 3. Modify the actual value by clicking on the order line. The order page will appear and notice the actual price of 10.00 is displayed. Change this actual price value to 9.00 and save. 4.View invoices and notice that the actual price displayed for the order is still 10.00 (set in step 2) when it should be 9.00 -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 21231] New: BlockReturnofLostItems does not prevent lost items being found
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '20

14 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21231 Bug ID: 21231 Summary: BlockReturnofLostItems does not prevent lost items being found Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When the syspref BlockReturnOfLostItems is set to Block, the item is blocked from being returned, but is still considered found -- it's set to lost=0 and a refund is applied to the patron (if circ rules allow). The item can then be checked in a second time and returned as it is no longer lost. To test: - set an item to lost - set BlockReturnOfLostItems to Block - check the lost item in - Koha says item cannot be returned but also item was lost, is now found - check the item in again -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 25871] New: Add "only library" to OpacItemLocation options
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '20

13 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25871 Bug ID: 25871 Summary: Add "only library" to OpacItemLocation options Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org The OpacItemLocation preference currently has three choices: - location: location - ccode: "collection code" - callnum: "call number only" I propose that we clarify the labels for these options and add a new one: - location: "library, location, and call number" - ccode: "library, collection code, and call number" - callnum: "library and call number" - library: "only library" The "only library" option would provide an option which was previously only available in the non-XSLT view via the "don't show" option under the "OPACItemsResultsDisplay" : "Availability: Items available for loan: Athens (2), Nelsonville (1)." If this change is acceptable we can WONTFIX Bug 5229 and create a bug to remove the OpacItemsResultsDisplay preference. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 24610] New: Let user switch between 'Pay' and 'Write off' mode
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '20

13 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24610 Bug ID: 24610 Summary: Let user switch between 'Pay' and 'Write off' mode Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org In patron's accounting section, under 'Make a payment' tab, you have the choice between 'Pay' and 'Write off'. It takes you to another form, but once there you cannot change mode. You have to click on Cancel, re-select the lines you had selected (if you made a selection) and click on the right button. This bug will add a way to switch between 'Pay' and 'Write off' mode -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 22987] New: Add biblioimages.timestamp
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '20

13 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22987 Bug ID: 22987 Summary: Add biblioimages.timestamp Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: Academy Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- It might be interesting to be able to see when an image was last updated. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 24474] New: Lost items that are checked out are always returned
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '20

10 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24474 Bug ID: 24474 Summary: Lost items that are checked out are always returned Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com This was a bug introduced by Bug 22982. "Hey all, this patch is causing problems for some of our libraries because it's been assumed that lost items with no attached charge should automatically be returned. This is not always the desired behaviour - we have one case where the library wants to keep lost items on a patron's record, and another case where a checked out lost item will be renewed, but the amount outstanding is zero, so the item gets returned. These are edge cases, but the assumptions in this patch do not consider them, and are causing problems. Is there a workaround? Or perhaps a better way of doing this patch that can allow for the cases of 'renewing a lost item' or 'wanting to keep a lost item on the checkouts record'? A solution that avoids doing circulation actions in the accounts modules as this patch does would be ideal." -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 99

[Bug 23423] New: Online resource links which are OPAC retrieve file references are not correctly formatted in the OPAC detail view
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '20

10 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23423 Bug ID: 23423 Summary: Online resource links which are OPAC retrieve file references are not correctly formatted in the OPAC detail view Change sponsored?: --- Product: Koha Version: 19.05 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: steve(a)softwaremage.co.nz QA Contact: testopia(a)bugs.koha-community.org Created attachment 91946 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=91946&action=ed… Example markup Symptom: Online resources: <a property="url" href="http:///cgi-bin/koha/opac-retrieve-file.pl?id=f445180b2247beac068a3bdef750856b" target="_blank">PDF Views of Acca, Haifa, Mt. Carmel and Other Places</a> | <a property="url" href="http:///cgi-bin/koha/opac-retrieve-file.pl?id=343848fcfdc5123bedf606f5b98110d6" target="_blank">PDF Views of Acca, Haifa, Mt. Carmel and Other Places (Annotated Version)</a> href is malformed: http:///cgi-bin/koha Cause ?? Looks like problem in XSLT (fragment from MARC21slim2OPACDetail.xsl) <xsl:if test="not(contains(marc:subfield[@code='u'],'://'))"> <xsl:choose> <xsl:when test="@ind1=7"> <xsl:value-of select="marc:subfield[@code='2']"/><xsl:text>://</xsl:text> </xsl:when> <xsl:when test="@ind1=1"> <xsl:text>ftp://</xsl:text> </xsl:when> <xsl:otherwise> <xsl:text>http://</xsl:text> </xsl:otherwise> </xsl:choose> Note these same resource links are correct in the opac search view. Online access: <a target="_blank" href="/cgi-bin/koha/opac-retrieve-file.pl?id=f445180b2247beac068a3bdef750856b">PDF Views of Acca, Haifa, Mt. Carmel and Other Places</a> | <a target="_blank" href="/cgi-bin/koha/opac-retrieve-file.pl?id=343848fcfdc5123bedf606f5b98110d6">PDF Views of Acca, Haifa, Mt. Carmel and Other Places (Annotated Version)</a> If one explicitly adds the full path to the 856u URI these are correctly referenced in the resulting markup. Relative paths are not. -- You are receiving this mail because: You are watching all bug changes.

1 14