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

[Bug 19777] New: Move template JavaScript to the footer: Serials, part 3
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '18

04 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19777 Bug ID: 19777 Summary: Move template JavaScript to the footer: Serials, part 3 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Blocks: 17858 In order to conform to best practices for performance staff client template javascript should be in the footer instead of the header. This patch will do so for even more of the serials templates. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17858 [Bug 17858] Omnibus: Move staff client JavaScript to the footer -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 15839] New: Move the reviews related code to Koha::Reviews
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '18

04 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15839 Bug ID: 15839 Summary: Move the reviews related code to Koha::Reviews Change sponsored?: --- Product: Koha Version: master 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 Blocks: 15449 The subroutines in C4::Reviews are only doing CRUD operations. This module can be moved easily to Koha::Reviews. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15449 [Bug 15449] Move stuffs to the Koha namespace -- You are receiving this mail because: You are watching all bug changes.

1 64

[Bug 2696] Fine payments should show what was paid for
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '18

04 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2696 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |20841 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20841 [Bug 20841] Barcode and description are needed in payment details -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9921] Make it possible to force 001 = biblionumber
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '18

04 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 paxed <pasi.kallinen(a)joensuu.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pasi.kallinen(a)joensuu.fi --- Comment #58 from paxed <pasi.kallinen(a)joensuu.fi> --- (In reply to emjhet from comment #57) > Like the 2013 thread starter and initial commentator, I believe MARC > designates the 001 field (Control Number) for use to uniquely identify a > bibliographic record. 001 alone does not guarantee uniqueness. 001 and 003 together should be globally unique. If 001 is changed, then 003 should be changed to match the org code of the system. You could have eg. 001 generated in your system (and 003 with your org code), and another (imported) record with 001 from another system and the 003 containing the org code of that other system. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 6758] Capture membership renewal date for reporting purposes
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '18

04 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6758 Amit Gupta <amitddng135(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=20867 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12027] Shibboleth authentication for staff client
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '18

04 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12027 Ray Delahunty <r.delahunty(a)arts.ac.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |r.delahunty(a)arts.ac.uk -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13049] Merge selfreg cron jobs into cleanup_database
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '18

04 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13049 --- Comment #21 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Katrin Fischer from comment #20) > (In reply to Marcel de Rooy from comment #19) > > (In reply to Katrin Fischer from comment #18) > > > It looks like this change introduced a regression. Before the changes it was > > > possible to define the delay for unverified registrations in hours and now > > > it's days. It will also change what actually happens when you switch over? > > > > > > With GDPR being very strict about saving data the initial feature of being > > > able to delete after x hours would be better. > > > > I think you are being even stricter now :) > > Triggered by a request from a library. I will try to submit some patches on bug 20819 this week. It now includes a (pref controlled) checkbox on opac-memberentry to give consent during selfregistration. No consent means no registration. Which makes this request less urgent again, since you will have a consent. (But note that we could already argue that it is not possible to "perform this contract" of self-registration without data. Second ground of GDPR.) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12310] Decimal separators issues in patrons payments/fines
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '18

04 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12310 --- Comment #97 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Victor Grousset/tuxayo from comment #96) > I followed this example: > https://metacpan.org/pod/Number::Format#unformat_number($formatted) OK If you feel the name is good enough, keep it. No big deal. Just do not use formating, single t :) > > So thousands separators come at the expense of handling both dots and commas. > > Still opt for something that is more understandable. > I'm not sure to understand. Is the the current state the patch on this topic > acceptable? Would it be clearer if you would say that you c/should not use characters from the DecimalSeparator pref also as thousands separator? > I split the patch because the test plan was way too long. > http://irc.koha-community.org/koha/2018-03-30#i_2024887 > http://irc.koha-community.org/koha/2018-03-30#i_2024900 > > When this bug and bug 18723[1] will be in master there won't be more > fragmentation than today. > And less actually. > > locally: acquisitions and payments/fines will be internally less fragmented. > as there are currently different behaviors in *successive pages* [2] > globally: the new approach replaces an existing one (I checked that it not > used elsewhere) > see moneyFormat function. > > https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=75127&action=di… > > So, are these changes a step in the right direct worth of begin integrated? > TODO wait answer, blocking question Well, I just hope so. But willing to follow your argument. Feel free to submit the tiny adjustments you intend to, and I will try to finish here. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15505] Mark Hold Items 'On hold' instead of 'Available'
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '18

01 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15505 --- Comment #8 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- (In reply to George Williams (NEKLS) from comment #7) > Working in a large consortium, I definitely want something like this. > > If a patron looks at the OPAC and sees a title with 30 items spread around > at different locations and 20 are already checked out and there are 15 > unfilled requests on the remaining 10 items the existing message can be > confusing if you're not at a branch where a copy is actually available to be > grabbed off of the shelf. > > Maybe the issue could be resolved by allowing for the wording of the wording > of the "Pending hold" message to be customized to suit the needs of the > library. If the message that displays when there is a pending hold on an > item could be tied to an authorised value, then each library could customize > the description of the item's availability in the staff client and the OPAC > to suit the needs of their library. If, for example, I want an item that is > hold_fill_targets to display a message that the item has a hold on it then I > can change the authorised value to read "Pending hold" but if I want it to > display the same availability as any other item on the shelf, I could change > the authorised value to read "Available." > > George I agree with George. This feature is needed, yet, we need to do it in a way that won't jeopardize how some libraries already use it. If it can be setup in a way we can tailor it, that would be great. Christopher -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15184] Ability to duplicate existing order lines to create a new basket
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '18

01 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15184 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |In Discussion --- Comment #3 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- We can imagine 1. You are on the vendor view (/acqui/supplier.pl?booksellerid=X), click on "New > Duplicate a basket", then you select the order lines you want to duplicate. or 2. You are on the basket view (/acqui/basket.pl?basketno=X), click "Add to basket > From existing order lines" Then you get a form/table like the one we have to search order lines (acqui/histsearch.pl), then you select the ones you want to duplicate. In both case we will have another view to change the values you want to modify. We could also: 3. You are viewing an existing basket, you click on a "duplicate" link next to one of the orders. Then you select another basket in a list. That sounds less flexible, but could be implemented later -- You are receiving this mail because: You are watching all bug changes.

1 0