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

[Bug 11373] Add a "cash register" feature to the fine payment form
by bugzilla-daemon＠bugs.koha-community.org 31 May '18

31 May '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11373 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Patch doesn't apply -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11081] Port Koha::Contrib::Tamil indexer into Koha code base
by bugzilla-daemon＠bugs.koha-community.org 31 May '18

31 May '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11081 Mirko Tietgen <mirko(a)abunchofthings.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|Failed QA |RESOLVED CC| |mirko(a)abunchofthings.net -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12012] Updating Zebra config files for debian packages
by bugzilla-daemon＠bugs.koha-community.org 31 May '18

31 May '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12012 Mirko Tietgen <mirko(a)abunchofthings.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mirko(a)abunchofthings.net --- Comment #2 from Mirko Tietgen <mirko(a)abunchofthings.net> --- Any reason why this has never been fixed? It seems to be still valid today. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 20061] New: koha-common is not pulling libsearch-elasticsearch-perl
by bugzilla-daemon＠bugs.koha-community.org 31 May '18

31 May '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20061 Bug ID: 20061 Summary: koha-common is not pulling libsearch-elasticsearch-perl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: mirko(a)abunchofthings.net Bug 19542 introduced the harder dependency but failed to add it to PerlDependencies.pm -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 14385] Extend OpacHiddenItems to allow specifying exempt borrower categories
by bugzilla-daemon＠bugs.koha-community.org 31 May '18

31 May '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14385 M. Tompsett <mtompset(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff --- Comment #164 from M. Tompsett <mtompset(a)hotmail.com> --- This is too huge, my mental energy keeps being too low, and I need this in sooner rather than later. Follow the test plan in comment #112. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15273] Fines Payment receipt should include all account lines selected for this pay
by bugzilla-daemon＠bugs.koha-community.org 31 May '18

31 May '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15273 --- Comment #11 from Claudio <costalc(a)gmail.com> --- Now that the account_offsets table is ready, is there a chance to go on with this ticket? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 14934] Add the barcode number in the description of all account lines both in the "Account" tab as in "Pay fines" tab.
by bugzilla-daemon＠bugs.koha-community.org 31 May '18

31 May '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14934 Claudio <costalc(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |BLOCKED -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 8685] Inventory tool fails in timeout with large CB files
by bugzilla-daemon＠bugs.koha-community.org 31 May '18

31 May '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8685 emjhet(a)pa.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emjhet(a)pa.net --- Comment #15 from emjhet(a)pa.net --- This is a huge issue for our libraries. Currently the only way to limit inventory is by library and shelving location. At some of our libraries, we can not limit by call number because some collections do not have call numbers. By not providing any other ways to limit an inventory, we have no choice but to process collections of over 1000 items. I have had to delay our inventories because of this, and the scanning that I did do was a wasted few days because the data could not be processed. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12477] We need better ways to manage MARC Frameworks
by bugzilla-daemon＠bugs.koha-community.org 30 May '18

30 May '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12477 emjhet(a)pa.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emjhet(a)pa.net --- Comment #17 from emjhet(a)pa.net --- Re: David Cook: "I'm thinking that there should be some mechanism for updating an existing framework." Koha requires that the "Default" Framework must remain, unedited and available, in Koha. This is the area to do all MARC21 updates, hopefully with each update of Koha. As David Cook noted, a library may set up a unique Framework that does not have all of the MARC fields and subfields when such a library is specifically attempting to keep things simplified and efficient. I am the only cataloger among seven people who add bibliographic records to our system. I ran reports to see which MARC fields were used, checked the ones that were used only a handful of times (to see if they were used correctly), and changed all of our records back to the Koha Default Framework. I deleted all the other frameworks (as none of their fixed fields were coded correctly) and painstakingly created a "new" default framework, deleting fields and subfields that are obsolete or not relevant to the work that we do. The most important thing to me, regarding MARC updates, is that I do not have to start from scratch using the Koha Default Framework. As long as the information is added to the Koha Default Framework, I can manually look it up and manually add it (correctly) to any of my unique Frameworks. -- 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 30 May '18

30 May '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 emjhet(a)pa.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emjhet(a)pa.net --- Comment #57 from emjhet(a)pa.net --- 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. IME the ILS does this automatically with both created and imported records. (Imported records with data in the 001 field would have that data automatically transferred into a newly created 035 field.) These unique, sequential Control Numbers were automatically generated system-wide despite multiple locations and input from multiple users. Koha appears to be able to create a unique, auto-generated, sequential identifier for each bibliographic record despite input from multiple users through the Koha field 'biblio.biblionumber;' however, it is mapped to the MARC field 999 subfield 'c.' It would be preferable to have this unique identifier in the MARC 001 field. Does the sequence number engine need to be fixed when the biblio.biblionumber auto-generates a unique sequential identifier already? Is it a matter of setting up the two fields alike (created upon the record being saved, and being visible after saving and during editing) so that a unique identifier could safely be generated in that field? With all the sequential auto-generated fields used currently by Koha (999$c, 999$d, 952$p), surely there is a way to auto populate the 001 field. If Koha requires that the 999$c field contain a unique identifier, I would find it preferable if the same identifier be used in the 001 rather than multiple unique identifiers. -- You are receiving this mail because: You are watching all bug changes.

1 0