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

[Bug 14390] Fine not updated from 'FU' to 'F' on renewal
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '16

22 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14390 Josef Moravec <josef.moravec(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |josef.moravec(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14797] Cancelling orders with no alert to existing holds
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '16

22 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14797 --- Comment #4 from Sandre Cunha <cunha(a)monterey.org> --- (In reply to Ray Delahunty from comment #3) > This remains a problem in 3.20 (we move to 16.05 soon). As a workaround we > have set up a report to be run whenever an order is cancelled, to look for > reservations. We have added this to the homepage, and our cataloging / > acquisitions staff can easily access it. > > SELECT o.ordernumber, b.title, b.author, p.surname, p.firstname, > r.reservedate, > r.cancellationdate, r.branchcode > FROM reserves r > LEFT JOIN borrowers p USING (borrowernumber) > LEFT JOIN biblio b USING (biblionumber) > LEFT JOIN aqorders o USING (biblionumber) > LEFT JOIN aqbasket n using (basketno) > WHERE o.ordernumber=<<Order number>> > > Better than nothing I suppose. > > Ray Delahunty > University of the Arts London And then how are the patrons notified? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 14868] REST API: Swagger2-driven permission checking
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '16

22 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14868 Tomás Cohen Arazi <tomascohen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomascohen(a)gmail.com --- Comment #31 from Tomás Cohen Arazi <tomascohen(a)gmail.com> --- All I have to say, is that this patches are really awesome :-D Please rebase them on top of bug 17050, and port the fix so RestrictSessionByIP isn't broken by this patchset. Awesome job! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14535] Late orders doensn't show orders with price = 0
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '16

22 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14535 --- Comment #3 from Sandre Cunha <cunha(a)monterey.org> --- This is not an issue for us, as the only items we have with a price of zero are pre-orders which will be published in the next fiscal year. We want them to show in the OPAC to avoid patrons suggesting them, but use a zero price to keep them from affecting the current budget. Just wanted the community to be aware of this aspect when working on this bug. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 13895] Add API routes for checkouts retrieval and renewal
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '16

22 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13895 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer(a)bsz-bw.de --- Comment #34 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- >Let user access their own checkouts and if OpacRenewalAllowed system preference >is on, also let user to renew their checkouts. I am concerned about this kind of behaviour. Would it mean that any user (without any permission) can do this using the REST API as long as they can get access to a valid session cookie/log into the OPAC? This checks for OpacRenewalAllowed, but what about opacuserlogin? Could we make this behaviour optional? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8030] Change pickup location of a hold from patron record
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '16

22 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8030 --- Comment #20 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- I am adding this to the agenda of the next dev meeting - I think if we make the API mandatory, we need to take other steps too (amending installation instructions for exapmle) and we should be aware of it. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 17156] New: Record matching on tag 001 does not work
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '16

22 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17156 Bug ID: 17156 Summary: Record matching on tag 001 does not work Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: joachim.ganseman(a)ehb.be QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Reproduction of the problem: - Stage and import a MARC21 record that contains data in Field 001. Update the zebra-index if necessary. - Define a record matching rule (in Administration -> Record Matching Rules) on Field 001: Search index = Control-number ; Tag = 001 ; leave Subfield, Offset and Length empty. - Now import the exact same record again, using this matching rule. Expected result: match found Actual result: no match found My gut feeling is that because 001 is a Control Field without any subfields, something goes wrong. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 13980] Can't call method "fields" on an undefined value at /usr/share /koha/intranet/cgi-bin/cataloguing/additem.pl
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '16

22 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13980 --- Comment #14 from Marc Véron <veron(a)veron.ch> --- (In reply to Marc Véron from comment #11) > Created attachment 54597 [details] > Steps to get "Internal server error" > > To reproduce: > > - Add (not edit) a new item > - Right click e.g. on "Search" in the top menu bar > - Status line shows .../cgi-bin/koha/cataloguing/additem.pl# > - In context menu, choose "Open link in new tab" > Result: New tab opens with "Internal server error" Fixed by Bug 17157 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8030] Change pickup location of a hold from patron record
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '16

22 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8030 --- Comment #19 from Nick Clemens <nick(a)bywatersolutions.com> --- (In reply to Katrin Fischer from comment #18) > Hm, I haven't installed the RESTful API or activated it. I didn't suspect it > to be a mandatory thing at this point in time, am I mistaken? > Owen had the same error message testing this. As of bug 17030 the REST API should be activated by default for new installs/upgrades and this feature is based on that assumption. If you add Mirko's nightly builds to your apt sources and upgrade then all should be running: https://apt.abunchofthings.net/koha-nightly/ you can test by accessing the staff url of your site at http://localhost:8081/api/v1/holds Updating hostname/port as necessary If all is working you will get a JSON blob of the holds in your system -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8030] Change pickup location of a hold from patron record
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '16

22 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8030 --- Comment #18 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hm, I haven't installed the RESTful API or activated it. I didn't suspect it to be a mandatory thing at this point in time, am I mistaken? Owen had the same error message testing this. -- You are receiving this mail because: You are watching all bug changes.

1 0