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

[Bug 15933] New: Regarding publishercode
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '21

11 Jan '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15933 Bug ID: 15933 Summary: Regarding publishercode Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: tejoskumar(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hi, As in the serials module there is an option to search for an existing vendor and add the vendor code while creating a new one, I could not find an option to search for a publishercode. If this is available the data entry part of the publishercode will be very uniform throughout the cataloging entries. I could not find this option any where hence posting it here. Regards Suresh Kumar -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 17801] New: 'Top Most-circulated items' gives wrong results when filtering by checkout date
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '21

08 Jan '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17801 Bug ID: 17801 Summary: 'Top Most-circulated items' gives wrong results when filtering by checkout date Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org We had a library reporting that records show up on this report that haven't been checked out within the selected date range of checkout dates. After looking at the script I think this is because it checks the timestamp column instead of the issuedate of old_issues. In old_issues the timestamp is the date of return, so that's not right and explains the results the library reported. Side note: the report does also not seem to count current checkouts as it avoids the issues table? -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 18795] New: REST API: DELETE (anonymize) checkout history
by bugzilla-daemon＠bugs.koha-community.org 07 Jan '21

07 Jan '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18795 Bug ID: 18795 Summary: REST API: DELETE (anonymize) checkout history Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org Anonymize patron's checkout history via REST API DELETE /checkouts/history?borrowernumber=123 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

[Bug 18752] New: Automatic item modifications by age should allow 'blank' values
by bugzilla-daemon＠bugs.koha-community.org 05 Jan '21

05 Jan '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18752 Bug ID: 18752 Summary: Automatic item modifications by age should allow 'blank' values Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Per comment 14 on bug 16437 the right side of the editor should not require a vlue - with YAML we could supply a blank here and we should be bale to again -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 17819] New: Performance 16.11 - Omnibus
by bugzilla-daemon＠bugs.koha-community.org 05 Jan '21

05 Jan '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17819 Bug ID: 17819 Summary: Performance 16.11 - Omnibus Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org https://wiki.koha-community.org/wiki/Benchmark_for_16.11 -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 19618] New: Automatic/standing holds
by bugzilla-daemon＠bugs.koha-community.org 04 Jan '21

04 Jan '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19618 Bug ID: 19618 Summary: Automatic/standing holds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jesse(a)bywatersolutions.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org 1) Add a pulldown and button labeled "Add randomized holds" to the holds page for each bib -- You are receiving this mail because: You are watching all bug changes.

1 67

[Bug 20885] New: Transferring an item on hold results in bypassing restrictions, actually doing the transfer and can be piled up if repeated
by bugzilla-daemon＠bugs.koha-community.org 26 Dec '20

26 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20885 Bug ID: 20885 Summary: Transferring an item on hold results in bypassing restrictions, actually doing the transfer and can be piled up if repeated Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor.grousset(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The first name was «Transferring an item on hold results in chaos» Disclaimer: I'm not sure if what I did makes sense from a functional point of view. == Test plan == 1. Add transfer restrictions staff:/cgi-bin/koha/admin/branch_transfer_limits.pl For all item types => clear all 2. Place a hold on a record 3. go to the transfer page staff:/cgi-bin/koha/circ/branchtransfers.pl 4. Try to transfer the item 5. You should see the message «Transfer is not allowed for [...]» OR retry with another site to fall into your restrictions 6. But you also see the "Transferred items" table showing the transfer This is a bug. The transfer shouldn't have been scheduled. 7. On the same page: redo a transfer 8. You should see "Item is already at destination library." This is a bug. This is even worst. The transfer shouldn't have been actually done! 9. But wait there is more, the transfer has been add to the table. This is a bug. It's still scheduled anyway. A transfer to the same branch! 10. Redo it again and it will pile up! 11. Raise your hands and ask loudly: Why! Tried on master the 24 of April and on version 16.11.15 To ensure that bug 19530 hadn't an influence on this. Might be related to bug 20344 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 21287] New: Report Zebra search errors to web server logs and staff client
by bugzilla-daemon＠bugs.koha-community.org 21 Dec '20

21 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21287 Bug ID: 21287 Summary: Report Zebra search errors to web server logs and staff client Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au At the moment, there's no way of knowing that a Zebra query failed unless you go into the Zebra server logs and have a certain level of verbosity for those logs. I'm proposing that we catch Zebra search errors and report them to the web server logs and surface them on the staff client. We can probably keep the OPAC the way it is as we probably don't want OPAC users seeing errors, but it could be good for staff to see, so that they can tell administrators and administrators can tell developers, and then we can fix all the things! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 20150] New: Acquisitions wizard always uses listprice
by bugzilla-daemon＠bugs.koha-community.org 21 Dec '20

21 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20150 Bug ID: 20150 Summary: Acquisitions wizard always uses listprice Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When using the acquisitions wizard, you can choose between different options: - Amount: - Ordered amount: - Spent amount: The calculations are always done with listprice. Especially for the amount spent this makes the wizard not match up with the amounts on the acquisition homepage as the actual amount spent can be quite different from the list price used when ordering. I think it probably should be calculated like this: - Amount: list price of ordered items + actual price of received items - Ordered amount: list price - Spent amount: actual price -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 18789] New: Send a Koha::Patron object to the templates
by bugzilla-daemon＠bugs.koha-community.org 21 Dec '20

21 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18789 Bug ID: 18789 Summary: Send a Koha::Patron object to the templates Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 18403 The simplify and make uniform the code, the controller scripts should send a Koha::Patron object to the templates and not all attributes of a patron. That will make the code much more easier to maintain and will be less error-prone. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18403 [Bug 18403] Hide patron information if not part of the logged in user library group -- You are receiving this mail because: You are watching all bug changes.

1 112