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

[Bug 22543] Patron might be logged in again using browser back button
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '20

11 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22543 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |26191 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26191 [Bug 26191] Relocate track_login call in Auth.pm (see 22543) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 22543] Patron might be logged in again using browser back button
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '20

11 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22543 --- Comment #34 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Marcel de Rooy from comment #30) > (In reply to Jonathan Druart from comment #29) > > 2. This code has been put before track_login_daily, is that expected? > > No. The track call should be done before. See bug 26191 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 5428] Back to results after deleting a record
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '20

11 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5428 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Passed QA --- Comment #14 from Nick Clemens <nick(a)bywatersolutions.com> --- (In reply to Jonathan Druart from comment #13) > Nick, your patch does not work for me, can you double check? > > searchid is not passed the batchMod.pl it works for me the links don't have searchid, however, there is js that adds it when you use the links in the Edit dropdown -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 6819] Don't offer cancel order links for received order lines on basket summary
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '20

11 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6819 Ray Delahunty <r.delahunty(a)arts.ac.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |r.delahunty(a)arts.ac.uk --- Comment #8 from Ray Delahunty <r.delahunty(a)arts.ac.uk> --- Once the received item is cancelled, the invoice is forever wrong. And it doesn’t just affect EDI invoices, rather all invoices, so a fix to this would be welcome. We are also wanting to review the opposite- whether it is possible for a cancelled item to be received, but we have to wait. (We are not ordering just now, and are having to set up a new vendor offering EDI, following the demise of our main book supplier.) Like… what does an incoming EDI invoice do when the order it is trying to receive has been cancelled? Does it force the receive? It shouldn’t be possible in a manual situation since once cancelled, there is no option for the user to select that order to receive- it would have disappeared from the receive shipment display. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 15522] New interface for revamped circulation rules
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '20

11 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15522 --- Comment #144 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- I can confirm the branch does work as expected (when you remember to run the yarn commands 'yarn install && yarn build') We've had this branch checked out for a few days with PTFS-E staff testing, and even had a feedback session with ByWater staff. Written feedback here to follow. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15522] New interface for revamped circulation rules
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '20

11 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15522 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Signed Off -- You are receiving this mail because: You are watching all bug changes.

1 0

[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

[Bug 26187] New: Allow deletion of guarantor and guarantee in one action
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '20

10 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26187 Bug ID: 26187 Summary: Allow deletion of guarantor and guarantee in one action Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When batch deleting patrons, one is prevented from deleting any patron who is the guarantor to another patron. However, this leads to a frustrating workflow when attempting to delete both the guarantee and the guarantor in one batch. To recreate: - Create an adult patron - Create a child patron with your adult as their guarantor - Put both patrons in a list - Attempt to batch delete the list - Only the child is deleted - Attempt to delete the list again - The guarantor is deleted It'd be nice if a guarantor would delete successfully if the batch is also removing all of their guarantees. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 24742] New: Can't save news item in strict mode without value in number field
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '20

10 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24742 Bug ID: 24742 Summary: Can't save news item in strict mode without value in number field Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org If strict mode is enabled, you can't save a news item without putting a number in the "Appears in position" field. The operation fails silently and this error appears in the log: DBD::mysql::st execute failed: Incorrect integer value: '' for column 'number' at row 1 [for Statement "UPDATE opac_news SET number = ?,expirationdate = ?,lang = ?,timestamp = ?,title = ?,branchcode = ?,content = ? WHERE idnew = ?;" with ParamValues: 0="", ... ] at /kohadevbox/koha/C4/NewsChannels.pm line 106. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3