February 2017 - Koha-bugs - lists.koha-community.org

[Bug 14764] Add OPAC News branch selector
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '17

02 Feb '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14764 Liz Rea <liz(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 17494] New: Koha generating duplicate self registration tokens
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '17

02 Feb '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17494 Bug ID: 17494 Summary: Koha generating duplicate self registration tokens Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We have reports of patrons receiving the same verification token. I believe this is because we are passing md5_hex a hashref and not a string. I believe what is getting summed is no the patron data, but the memory address that points to the patron hash! We need to stringify the patron hash before passing it to md5_hex. -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 12722] bulkmarcimport.pl: Should we move the old 001 to 035 ?
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '17

02 Feb '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12722 --- Comment #8 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to David Gustafsson from comment #7) > Ok! Sorry, I was being very unclear, I was referring to biblios as well. I'm > quite new to Koha and marc, so I might be completely wrong, but I don't > understand why the handling of 001 and 035a should be handled differently > between the two. When importing a bibliographic record into Koha I would > expect 001 to be replaced with the Koha local id, and the previous 001 moved > to 035a. Yeah, we were talking authorities. On several reports there was indeed discussion about the biblionumber in 001. Until now no results yet. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12722] bulkmarcimport.pl: Should we move the old 001 to 035 ?
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '17

02 Feb '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12722 --- Comment #7 from David Gustafsson <glasklas(a)gmail.com> --- Ok! Sorry, I was being very unclear, I was referring to biblios as well. I'm quite new to Koha and marc, so I might be completely wrong, but I don't understand why the handling of 001 and 035a should be handled differently between the two. When importing a bibliographic record into Koha I would expect 001 to be replaced with the Koha local id, and the previous 001 moved to 035a. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15545] Optionally make hold notes required when placing a hold ( via Koha::Plugin)
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '17

02 Feb '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15545 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |18037 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18037 [Bug 18037] Hold notes template cleanup (from 15545) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15545] Optionally make hold notes required when placing a hold ( via Koha::Plugin)
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '17

02 Feb '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15545 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |BLOCKED --- Comment #41 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Blocked (temporarily) in favor of bug 18037. Actually splitting the patch set. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13757] Make patron attributes editable in the opac if set to ' editable in OPAC'
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '17

02 Feb '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13757 --- Comment #76 from Tomás Cohen Arazi <tomascohen(a)gmail.com> --- Created attachment 59813 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=59813&action=ed… Bug 13757: (QA followup) Fix non-editable attrs on failed save When a field is not editable but displayable in the OPAC, and you submit an incomplete/wrong update, those attributes are displayed as empty. This patch fixes that. Signed-off-by: Tomas Cohen Arazi <tomascohen(a)theke.io> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14957] Write protecting MARC fields based on source of import
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '17

02 Feb '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14957 --- Comment #35 from David Gustafsson <glasklas(a)gmail.com> --- The previously posted version of this patch at least for me did not apply cleanly. Rebased against current HEAD of master, and also slightly altered the behavior of "GetMarcPermissionsAction". The previous behaviour struck me as odd since a module with a higher specificity will always override modules with lower, even for the case when a filter argument for a module with lower specificity has an exact match. So for example, if we have a rule with filter 'source' => 'bulkmarcimport', and another for 'borrower' => '*', the later rule will always have precedence, even when source is matching 'bulkmarcimport'. I seems more flexible to have the option to override on a more specific filter match. Generally I think this patch is great, and almost exactly what we need, but the whole filter-system I think is in need of some revamping. It would be nice if the modules where more like separate namespaces, so that one set of rules (belonging to a certain module) was applied at once. Right now rules from several modules might be mixed in, and field-specificity has precedence in rules selection. The code could be simplified and optimized if rules where grouped by module instead (and also easier to admin from a user perspective I would believe, since rules precedence would be more obvious. But have made no such changes in the current patch, as wanted to bring this up for discussion before make any large breaking changes. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14957] Write protecting MARC fields based on source of import
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '17

02 Feb '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14957 David Gustafsson <glasklas(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #59811|0 |1 is obsolete| | --- Comment #34 from David Gustafsson <glasklas(a)gmail.com> --- Created attachment 59812 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=59812&action=ed… Rule based permission for MARC fields Oops, forgot to remove some temporary comments. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14957] Write protecting MARC fields based on source of import
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '17

02 Feb '17

1 0