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

[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 11146] New: Show a go back link on no permission page
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '14

07 Feb '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11146 Bug ID: 11146 Summary: Show a go back link on no permission page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: fridolyn.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org When a user has not the permission for a page or module, the authentication page is displayed with message : "Error: You do not have permission to access this page.". Most librarians uses the "previous page" button of there browser to come back on the page they where before trying to get to this non-permitted page. I propose to add a link to help comming back. -- You are receiving this mail because: You are watching all bug changes.

1 15

[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 11035] New: Replace shortcut plugin jquery.hotkeys.min.js
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '14

05 Feb '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11035 Bug ID: 11035 Summary: Replace shortcut plugin jquery.hotkeys.min.js Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: philippe.blouin(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org (Not sure I have have the right Component or Severity, feedbacks welcomed). A sponsor asked for some specific keyboard shortcuts. After discussion a month ago with (oleonard, jcamins), it seemed a change of plugin was needed because the current one is not maintained and would limit our ability to upgrade jquery, simply. I was suggested a few independant ones, and implemented my feature with openjs's. This bug is ONLY about changing the plugin. It brings no new functionnality nor does it changes behavior. Enhancement to shortcut could bring a lot of discussion. Refression TESTING: 1) apply the patch, 2) in intranet, validate that the three available shortcuts (Alt-r, alt-u, alt-q) are still functionning perfectly. -- You are receiving this mail because: You are watching all bug changes.

1 21

[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 11054] New: Creating a child record has problems with accented Latin characters
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '14

02 Feb '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11054 Bug ID: 11054 Summary: Creating a child record has problems with accented Latin characters Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: colin.campbell(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When you select New child record from the catalogue detail page. If the data that will be used to create the host field contains latin characters with diacritics from the range covered by latin-1 they are incorrectly encoded in the resulting child record. This is not the case with non-latin characters (Cyrillic, Arabic and Chinese tested) and I suspect with latin diacritic combinations that are not in the latin-1 range -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 11136] New: action_logs should be a MyISAM table, not InnoDB
by bugzilla-daemon＠bugs.koha-community.org 31 Jan '14

31 Jan '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11136 Bug ID: 11136 Summary: action_logs should be a MyISAM table, not InnoDB Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement 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 The table action_logs is written too at a higher rate than practically any other table. Additionally, action_logs has no foreign key constraints. It seems that this would be a somewhat unique situation where using MyISAM would provide quite a performance boost for large sites with many transactions that use the Action Logs. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 11176] New: Purchase suggestions should respect the 'active' switch on budgets
by bugzilla-daemon＠bugs.koha-community.org 31 Jan '14

31 Jan '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11176 Bug ID: 11176 Summary: Purchase suggestions should respect the 'active' switch on budgets Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: david.roberts(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org When creating a new purchase suggestion, all funds display and are available for selection. The behaviour of this drop-down menu should mirror that of those drop-down menus elsewhere in acquisitions, where only funds that are linked to active budgets display to the user. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4