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

[Bug 19443] New: Error while attempting to duplicate a patron
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '18

19 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19443 Bug ID: 19443 Summary: Error while attempting to duplicate a patron Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: alex.arnaud(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com HTML in the patron creating/editing form is not correct. If you create a patron and Koha detect a duplicate one, the new page loaded contains a new form at the top with a button inside: "Not a duplicate. Save as new record" This form is not closed (</form>) and in some situations this could be problematic. Try this test plan: - Edit the syspref IntranetUserJS and type the following code: "$(document).ready(function() { $("#memberentry_library_management").insertBefore("#memberentry_identity"); });" This code move the "Library management" part (cardnumber, Library, Category etc...) on the top of the page. - create a patron so that Koha will warn you about a duplicate one, - click on "Not a duplicate. Save as new record", - you should get error(s) about empty field(s). Note that now, the library management part's fields are empty or reset to default -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 9701] Configure default indicators
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '18

19 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9701 --- Comment #23 from Josef Moravec <josef.moravec(a)gmail.com> --- Created attachment 71931 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=71931&action=ed… Bug 9701: (follow-up) Adjust tests Test plan: prove t/db_dependent/Biblio.t should be green -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9701] Configure default indicators
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '18

19 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9701 --- Comment #22 from Josef Moravec <josef.moravec(a)gmail.com> --- Created attachment 71930 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=71930&action=ed… Bug 9701: (QA follow-up) Fix indentation and some strings - Fixes tabs pointed out by the QA script. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9701] Configure default indicators
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '18

19 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9701 Josef Moravec <josef.moravec(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #53403|0 |1 is obsolete| | Attachment #53404|0 |1 is obsolete| | --- Comment #21 from Josef Moravec <josef.moravec(a)gmail.com> --- Created attachment 71929 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=71929&action=ed… Bug 9701: Configure default indicator This patch adds the possibility to define default indicators in the MARC frameworks. It adds 2 columns in the marc_tag_structure table in the database in order to accomplish this. All files that reference this table have also been updated to reflect these added fields. Test: Add or edit a MARC framework. In the Field list should be 2 extra columns. It should be possible to add default indicators (1 character) in these fields. Nothing else should have changed in the meantime. The default indicator values are not yet visible in the cataloguing module. The default values are also loaded in the cataloguing form. Test: Define default values in some MARC framework. Go to cataloguing and create a new record using this framework. Verify that the defined defaults are visible when set. Verify the default is empty (as before) if no default was set. Verify that if the default is changed, the record is saved with the manually changed value. Verify that upon changing such a new record, the manually set indicator value is used and not the default one from the framework. Don't forget to run database and database schema update Signed-off-by: Eugene Jose Espinoza <eugenegf(a)yahoo.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9701] Configure default indicators
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '18

19 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9701 Josef Moravec <josef.moravec(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 19905] New: Don't append wildcard to query terms
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '18

19 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19905 Bug ID: 19905 Summary: Don't append wildcard to query terms Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: glasklas(a)gmail.com Discovered this issue while testing the search links in biblio-details. The links are hard-coded in the template with queries not using quotes for field values, which makes QueryBuilder::_truncate_terms append '*' to the search term. Since wild card searches skips the analyzer-phase, most of our links does not work (since a lot of field values has word boundaries and/or punctuation marks, for example the query "Provider:Taschen," will be converted to "Provider:Taschen,*" and since the indexed value for Provider is "Taschen" this search will produce no results. In my opinion (if I'm not misunderstanding the purpose of this code) appending '*' to words should be removed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 20100] Should a non-superlibrarian be able to add superlibrarian privileges?
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '18

19 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20100 --- Comment #12 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Rebased for move of javascript to footer. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 20100] Should a non-superlibrarian be able to add superlibrarian privileges?
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '18

19 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20100 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #71093|0 |1 is obsolete| | --- Comment #11 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Created attachment 71918 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=71918&action=ed… Bug 20100: Disallow access to superlibrarian privileges at client side This last patch activates the check at client side. If the pref ProtectSuperlibPrivs is enabled, non-superlibs should not be able to change superlibrarian privileges via the interface. Test plan: [1] Enable the pref. [2] Login as superlib and add/remove superlib privs to a staff user. [3] Login as another user (no superlib, but having borrowers, permissions and staff_access). Verify that you cannot add or remove superlib privs. Signed-off-by: Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 3777] Field Sizes Inconsistent
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '18

19 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3777 --- Comment #13 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to Jon Knight from comment #12) > I'm just trawling through old REOPENed cases and I see that the current > (17.05) borrower schema still has the inconsistencies in the addresses. As > this was reopened because it was proving to be an issue for some addresses > longer than 100 characters, is it worth just attacking just those fields to > make them all match the address versions? > > In other words make these field changes in the borrowers table schema: > > B_address mediumtext NOT NULL, > B_address2 text, > B_city mediumtext NOT NULL, > > and > > altcontactaddress1 mediumtext NOT NULL, > altcontactaddress2 text, > altcontactaddress3 mediumtext NOT NULL, I once tried to start a clean-up, but ended very confused. In your eample I think there is probably no reason that ...address2 should not be mediumtext not null too? One thing I encountered back then was that some types can't be using not null (iirc). -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 6918] Can't place holds on 'on order' items with AllowOnShelfHolds off
by bugzilla-daemon＠bugs.koha-community.org 19 Feb '18

19 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6918 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|can't place holds on 'on |Can't place holds on 'on |order' items with |order' items with |AllowOnShelfHolds off |AllowOnShelfHolds off -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0