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

[Bug 8676] Show vendor name in source of acquisition
by bugzilla-daemon＠bugs.koha-community.org 19 Jul '18

19 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8676 --- Comment #8 from Owen Leonard <oleonard(a)myacpl.org> --- (In reply to Keshav Gupta from comment #7) > This seems to be some Template data related issue. Is anyone find Solution > for the same??? This bug report confirms that the problem exists, and the lack of a patch on this bug report indicates that there isn't a solution yet. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11983] code to select patrons to purge needs to be centralized
by bugzilla-daemon＠bugs.koha-community.org 19 Jul '18

19 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11983 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy(a)rijksmuseum.nl --- Comment #11 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Hmm. At first glance option 1 shows less code lines and more flexibility with parameters. It might be easier to switch one parameter than selecting another method each time ? But no strong opinion here, and not studied it in detail.. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11983] code to select patrons to purge needs to be centralized
by bugzilla-daemon＠bugs.koha-community.org 19 Jul '18

19 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11983 --- Comment #10 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- Thanks for the review, Jonathan :) I far prefer option 2 too now I've written it. I think splitting out the final combinations for script + tool interfaces into their own subclasses also makes sense. Regarding your remarks: - Interesting regarding the join.. perhaps my brain is failing me but I couldn't see how I could do it without the having (whilst maintaining chainability). Happy to be guided here.. I might ask ribasushi for his thoughts there :) - Coming up with method names was almost the hardest bit of this and I'm more than happy to be advised here.. What I would like to see is a fairly standardised recommendation for method names of this type as a guideline. We came up with 'filter_by_' to denote that you are filtering the resultset down. Following that by the 'how' and 'what' makes sense. It's describing the 'how' and 'what' which is causing fun here.. - `last_issued` could be more clearly written as `when_last_issued` perhaps? - oh, did I get the standardisation wrong.. I thought we'd gone from 'checkout' to 'issue', my bad.. that should also be corrected in the above one too. - I'm fine with has_pending_checkouts, I can't think of anything better or more descriptive. I think it is used in cleanborrowers (only it's hidden inside other filters) - 'has' vs 'have'.. hmm, we're in Koha::Patrons so 'have' is right.. thanks - I actually made this one flexible at someone's request.. though I can't remember who.. perhaps it would be better as distinct methods.. more than happy to get some discussion going here. I shall try to raise all this at the next dev meeting.. see if we can bring some more people into the conversation. -- You are receiving this mail because: You are watching all bug changes.

1 0

[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 #2 from David Cook <dcook(a)prosentient.com.au> --- Created attachment 77099 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=77099&action=ed… Bug 13779 - sessionID declared twice in C4::Auth::checkauth() The bug is that $sessionID is declared twice in C4::Auth::checkauth(). At the moment, this doesn't actually create a problem, because no one seems to be using the $sessionID which is returned by checkauth(), except in the case of opac/external/overdrive/auth.pl which skips the second declartion as it doesn't require auth. This patch removes the redefining of the $sessionID variable. In terms of testing, try logging in with a username and password and see if it works. The only risk this patch would pose is breaking auth I would think, since nothing is actually using the return value from checkauth() for $sessionID. -- You are receiving this mail because: You are watching all bug changes.

1 0

[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 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0

[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