September 2013 - Koha-bugs - lists.koha-community.org

[Bug 9579] New: Incorrect display of UNICODE symbols in 'Refine Search Results'
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '14

07 Feb '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9579 Bug ID: 9579 Summary: Incorrect display of UNICODE symbols in 'Refine Search Results' Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: tigran(a)flib.sci.am Created attachment 15202 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=15202&action=edit 3 iamges with incorrect UNICODE Attaching 3 images - 2 for Cyrillic records and one or Armenian. You will notice that instead of the letter some other code is displayed and when pressing on the names from left pan (Refine your search), the search is returning null results (see arm1.png). Another interesting detail. When pressing om left pan name, the display on search window of Armenian name is displayed correctly (see arm1.png) but on the top (URL window) some of letters are displayed incorrectly. When we are just typing Armenian or Cyrillic scripts in the search window everything is working fine. So the problem is how is encoding/indexing going with the 'Refine your search' pan. Tigran -- You are receiving this mail because: You are watching all bug changes.

1 41

[Bug 10970] New: Update MARC21 frameworks to Update Nr. 17 - DB update
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '14

07 Feb '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10970 Bug ID: 10970 Summary: Update MARC21 frameworks to Update Nr. 17 - DB update Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: bgkriegel(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Update MARC21 frameworks to Update Nro. 17 for current installs -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 9948] New: acq data going on first item even if not received
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '14

07 Feb '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9948 Bug ID: 9948 Summary: acq data going on first item even if not received Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com This is hard to explain so I did a video: http://screencast.com/t/COozHEj58ny If you choose to receive 1 item out of multiple and that item is not the first one Koha puts the acq data on the item you didn't receive, not the one you received. Tested in 3.10.4 and master. The bug is in both. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 10453] New: updating child to adult loses password
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '14

07 Feb '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10453 Bug ID: 10453 Summary: updating child to adult loses password Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Tested in 3.10.x and master. When you update a child to an adult it loses the password (or changes it) - the patron can no longer log in to the OPAC after using the 'update child to adult' in the staff client. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 8018] New: New subfields have a default max length of zero
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '14

07 Feb '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8018 Priority: P3 Change sponsored?: --- Bug ID: 8018 Assignee: gmcharlt(a)gmail.com Summary: New subfields have a default max length of zero Severity: major Classification: Unclassified OS: All Reporter: jcamins(a)cpbibliography.com Hardware: All Status: NEW Version: master Component: Cataloging Depends on: 7263 Product: Koha If you add a new subfield to a framework, the maximum length of the field defaults to 0, and the "Max length" box is hidden under "Display more constraints." The result is that if someone simply adds a new subfield, they will be unable to type in it, with no indication of what the problem is. -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 6435] New: False "no items" in search results [intranet]
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '14

07 Feb '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6435 Bug #: 6435 Summary: False "no items" in search results [intranet] Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: eb(a)efdss.org QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com This applies only to things catalogued since upgrading to 3.4 The search results for these new records show no items in the hit list. But if you click on the title to bring up the normal view, the items are there, and are fully functional. The OPAC seems unaffected. The records created before we moved to 3.4 are also unaffected. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 72

[Bug 5958] New: Availability Limit with icu
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '14

04 Feb '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5958 Bug #: 5958 Summary: Availability Limit with icu Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: critical Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: ayousef(a)kwareict.com QAContact: koha-bugs(a)lists.koha-community.org Hi all As an extension of availability limit we noticed that the option of limit into currently available items is working only if we don't use icu but when using the icu this option is useless Plz, have you any idea about getting rid of this and what is the relationship between icu & Availability limit. thanks alot Abdou Yousuf. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 3

[Bug 10811] New: Add a 999$c record matching rule to the MARC21 defaults
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '14

02 Feb '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10811 Bug ID: 10811 Summary: Add a 999$c record matching rule to the MARC21 defaults Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: gmcharlt(a)gmail.com Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Currently, the only default matching rules for MARC21 are ISBN and ISSN. However, I'm sure that many people would profit from having a 999$c "Koha biblionumber" record matching rule as well. 1) If you export your bib records to do some global/batch changes with another program (like MarcEdit), you can use this rule to replace the existing bib records with your modified records. 2) With my upcoming OAI-PMH harvesting feature, if you add a OAI-PMH repository with this rule in the configuration, you'll be able to automagically match updated records with the original records that you imported via OAI-PMH (the magic is that I check the incoming unique identifier against records in Koha, and if there is already a bib record in Koha matching that identifier, I write the biblionumber for that record back into the incoming record so that they match. It sounds convoluted but it works well). 3) People might have other ideas about this as well. -- You are receiving this mail because: You are watching all bug changes.

1 28

[Bug 10346] New: "Add multiple copies" should be labelled "Add multiple items"
by bugzilla-daemon＠bugs.koha-community.org 31 Jan '14

31 Jan '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10346 Bug ID: 10346 Summary: "Add multiple copies" should be labelled "Add multiple items" Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de For consistency in the English and translated templates the button "Add multiple copies" in cataloguing should read "Add multiple items". -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 10208] New: The ability to order multiple copies of the same title
by bugzilla-daemon＠bugs.koha-community.org 27 Jan '14

27 Jan '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10208 Bug ID: 10208 Summary: The ability to order multiple copies of the same title Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: amit.gupta(a)osslabs.biz The ability to order multiple copies of the same title, from the same fund class on the same order number, by inserting a number in the quantity box and not having to use the plus sign. It is very tedious when ordering 12 copies of a reading group title to have to click on the plus sign twelve times to order 12 copies. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3