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

[Bug 13779] sessionID declared twice in C4::Auth::checkauth()
by bugzilla-daemon＠bugs.koha-community.org 19 Jul '18

19 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13779 --- Comment #1 from David Cook <dcook(a)prosentient.com.au> --- This is still an issue. I'm tempted to write a patch for it, but I fear that it'll be too scary for people to test since it's in C4::Auth. At the moment, it doesn't really affect anyone (except for me with code which isn't in Koha). We can verify this by running the following in the root git directory: grep -l -R "checkauth" --exclude="*.t" --exclude="*.pm" | xargs -n1 grep "sessionID" For the most part, nothing gets done with sessionID. The one exception seems to be opac/external/overdrive/auth.pl but it doesn't actually require auth so it doesn't go down the bad path in C4::Auth. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11911] Add separate permission for managing suggestions
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '18

18 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11911 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Purchase suggestions can be |Add separate permission for |accessed by all staff |managing suggestions |members / no specific | |permission | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7651] Add separate permission for managing currencies and exchange rates
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '18

18 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7651 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick(a)bywatersolutions.com Status|Passed QA |Pushed to Master --- Comment #20 from Nick Clemens <nick(a)bywatersolutions.com> --- Awesome work all! Pushed to master for 18.11 -- 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 18 Jul '18

18 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #64 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- You can query and output the content of the field without an authorised value. Did you take a look at the sql library on the wiki? Maybe a topic for a different channel, like IRC or mailing list tho :) -- 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 18 Jul '18

18 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #63 from emjhet(a)pa.net --- (In reply to Katrin Fischer from comment #62) > I understand, just trying to prevent you from doing something that might > break stuff (because people have gone there before). I can't tell you why > for Koha 999c was chosen in the beginning, but it's one of the things that > will need quite a bit of thinking if we wanted to change it now. > > I think here are patches around to make a plugin to set 001 individually. I > am using a variation of the stocknumberAV plugin in one of our libraries to > create numbers, but you have to trigger it and it doesn't move the number to > 035 as they only do original cataloguing. A catalouging plugin might be a > route to explore. Katrin -- Thank you so much for responding. I'm a cataloger among non-catalogers and I am just trying to make things as easy as possible for my co-workers while following standard guidelines for minimum level cataloging. Unless I have a plug-in for the 001 and permit it to be filled in with a click of the mouse, I will not be able to convince anyone to spend the time on it. Some of our libraries are completely one-"man" operations. Koha deviates in several significant ways from the ILS that I am accustom to, including not having a good way to run reports requesting specific MARC fields. Am I correct that I can run a report and find out how many records have a specific MARC field, but the only way to find out the content of the field in a report is to have the MARC field mapped to an authorized value? -- You are receiving this mail because: 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 18 Jul '18

18 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8685 --- Comment #23 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Thx for testing and sharing your results! Glad that the situation seems to have improved! -- You are receiving this mail because: 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 18 Jul '18

18 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8685 --- Comment #22 from emjhet(a)pa.net --- (In reply to Katrin Fischer from comment #21) > > I think noone was able to retest this yet. If you have a test system > available to you, you could create a report in order to get a long list of > barcodes and test with that. That could help to verify if the bug still > exists. I am using Koha 17.11.06. I ran a test batch through the inventory module. It had 3747 items in it and it did not time out! It may be because the results are coming back differently. Instead of getting results that list each barcode and the fact that the item's status was updated, only the "problem" items were listed (things that were checked out, missing, etc.) And it actually used the date that I told it to (which it did one time I ran an inventory and another time it did not.) So this may not be a problem any longer. I do not have another library location that I can run a fake inventory on at this time to see if a larger file would run successfully. Please do note that we do not have the fastest internet here, so those with better connections may be able to run larger files. -- 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 18 Jul '18

18 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #62 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- I understand, just trying to prevent you from doing something that might break stuff (because people have gone there before). I can't tell you why for Koha 999c was chosen in the beginning, but it's one of the things that will need quite a bit of thinking if we wanted to change it now. I think here are patches around to make a plugin to set 001 individually. I am using a variation of the stocknumberAV plugin in one of our libraries to create numbers, but you have to trigger it and it doesn't move the number to 035 as they only do original cataloguing. A catalouging plugin might be a route to explore. -- 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 18 Jul '18

18 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #61 from emjhet(a)pa.net --- (In reply to Katrin Fischer from comment #60) > The biblionumber is not a sequentially created number of the application, > but it's the primary key assigned by the database. That's why it will only > be set after saving a record for the first time - before it doesn't exist. > I understand the purpose of the biblionumber. It is what MARC says the field 001 is for. I am trying to understand why Koha chose to use the 999$c for this information instead of the 001, and the implications this decision has on our library. Although it is not good cataloging practice, Koha recommends importing a "close" record if you can not find a matching record in your Z39.50 search. Then simply alter the record as needed. This has happened at the library where I work. However, the 001 field was not changed. Often these records were imported from our state union catalog. Because Koha does not create a unique 001, these records would be for different items but have the same 001, and our holdings would likely be attached to the wrong record. Thus we could receive requests for items that we do not, in fact, own. Thus this matter is not merely academic for us. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10198] Add the ability to import and export authorized values
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '18

18 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10198 George Williams (NEKLS) <george(a)nekls.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |george(a)nekls.org -- You are receiving this mail because: You are watching all bug changes.

1 0