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

[Bug 17414] New: Add GIR codes added to Edifact since 1.2
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '17

21 Feb '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17414 Bug ID: 17414 Summary: Add GIR codes added to Edifact since 1.2 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: colin.campbell(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org 4 new GIR codes have been added to Edifact since version 1.2 see http://www.editeur.org/files/EDIfact%20eancom%20pdfs/EDIfact%20library%20su… The following codes have been added to DE 7405: LHC Library Holding Code: may hold a combination of information i ncluding location , sequence, item type etc. as a single data string (contents defined by the library). LRP Library Rotation Plan: a code number assigned by a library to identify a rotation plan to which an item belongs. LSC Statistical category: a c ode used by a library to identify a statistical category (e.g. „605‟ or „Children‟s Picture Books‟) for management reporting purposes. RIC Reader Interest Category: code to identify stock at a lower level than LST (Stock Category) eg. Western, Science Fiction. These need to be added to list of recognized codes for future developments ( e.g. to include Stock Rotation intp in LRP ) to be able to utilize these -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 17566] New: Change initial focus in item editor depending on last action
by bugzilla-daemon＠bugs.koha-community.org 20 Feb '17

20 Feb '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17566 Bug ID: 17566 Summary: Change initial focus in item editor depending on last action Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If you have saved an existing item or added a new one, it would be nice to have the focus in the search box. In other cases, at the start of adding or editing an item, it would be good to have focus in the item fields already. This patch sets the focus in the second case on the first item input field, since focus on the first select (combo box) does not show up. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 17493] New: Improve OAI Server tests
by bugzilla-daemon＠bugs.koha-community.org 20 Feb '17

20 Feb '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17493 Bug ID: 17493 Summary: Improve OAI Server tests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: frederic(a)tamil.fr QA Contact: gmcharlt(a)gmail.com Required to help validate bug 15108. -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 16018] New: merges not modifying biblios properly
by bugzilla-daemon＠bugs.koha-community.org 20 Feb '17

20 Feb '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16018 Bug ID: 16018 Summary: merges not modifying biblios properly Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: remi.mayrand-provencher(a)inLibro.com Reporter: remi.mayrand-provencher(a)inLibro.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl As the summary says, merges are not modifying biblios properly. Test plan to reproduce the bug: 1)Go to authority, search for anything 2)Click merge on two authorities of the same type that are used at least one time 3)Validate which subfields are corresponding to each authorities in the biblios that uses them 4)Do the whole merge process 5)Validate that the biblios are updated properly (which they are not according to my tests. -- You are receiving this mail because: You are watching all bug changes.

1 50

[Bug 17461] New: Make plugins-home.pl complain about plugins that can not be loaded
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '17

19 Feb '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17461 Bug ID: 17461 Summary: Make plugins-home.pl complain about plugins that can not be loaded Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org I tried to install an older version of the KitchenSink plugin, but it did not show up in the list of plugins. And there was nothing interesting in the logs either. So how do I figure out what the problem is? See attached patch for my solution. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 17793] New: Make sysprefs search show on Administration home page
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '17

19 Feb '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17793 Bug ID: 17793 Summary: Make sysprefs search show on Administration home page Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleishaamohia(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com At the moment, admin/admin-home.pl shows the cataloguing search with check out, check in, renew and catalogue search options. It seems more appropriate to show the prefs-admin search here instead. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 17627] New: Move C4::Koha::GetItemTypesByCategory to Koha::ItemTypes
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '17

19 Feb '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17627 Bug ID: 17627 Summary: Move C4::Koha::GetItemTypesByCategory to Koha::ItemTypes Change sponsored?: --- Product: Koha Version: unspecified 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 -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 17655] New: Insertion of intranetuserjs should be moved to the end of <body>
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '17

19 Feb '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17655 Bug ID: 17655 Summary: Insertion of intranetuserjs should be moved to the end of <body> Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com At present, intranetuserjs is expanded somewhere before the </body> tag. This means that everything in intranetuserjs *must* be wrapped in $(document).ready( function(){ ... }); It's considered good jquery coding practice to move all jquery directly before the </body> tag so that this isn't necessary. I believe that this is the case for the OPAC already. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 15816] New: Timeout login redirects to home page
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '17

19 Feb '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15816 Bug ID: 15816 Summary: Timeout login redirects to home page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P3 Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: library(a)stas.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com On the staff client, when the session times out, or the user is asked to login again, the login always redirects to the home page. Formerly (as of 3.18.6 from which we upgraded to 3.22.1), it would redirect back to the page requested. --------- Example of former behavior: Login has timed out. User clicks link for a new biblio record from z39.50 (Cataloging). Pop-up search window opens, but asks for a login. Once logged in the z39.50 search form is shown. Example of present behavior: Login has timed out. User clicks link for a new biblio record from z39.50 (Cataloging). Pop-up search window opens, but asks for a login. Once logged in the staff home page is shown in the pop-up window. Behavior is the same for other pages as well. It seems the requested page (which appears in the address bar) is not passed to the login form (which is in mainpage.pl) and instead mainpage.pl is shown. Not a deal breaker, but annoying to have to login from scratch (or in another window) to a continue working on a record you were working on yesterday, or continue a session. I suspect Bug 15005. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 16632] New: When placing hold in OPAC patron has to search, log in and then search again
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '17

19 Feb '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16632 Bug ID: 16632 Summary: When placing hold in OPAC patron has to search, log in and then search again Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: amy(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org >From one of our partners: When a patron chooses to place a hold from the from the OPAC details screen for an item, the system does not display the bib record of the item but takes you to your account login, then your account. Then patron must search for the title again, and ask to place a hold again before it is confirmed. I have confirmed this behavior. I think the requested behavior is for the OPAC to retain the search after the patron logs in so that the search doesn't have to be repeated again to get to the item they want to place the hold on. -- You are receiving this mail because: You are watching all bug changes.

1 3