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

[Bug 5707] New: Editing existing authority record 'delete this subfield' clears all fields
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '12

19 Jan '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5707 Summary: Editing existing authority record 'delete this subfield' clears all fields Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: MARC Authority data support AssignedTo: gmcharlt(a)gmail.com ReportedBy: eb(a)efdss.org QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Estimated Hours: 0.0 When editing an existing authority record I clicked on the icon to the right of the subfield (mouseover says 'delete this subfield'). Not only did it delete the contents of that subfield but everything else in the authority record. -- 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 1

[Bug 5878] New: overdue printing fixes and improvements
by bugzilla-daemon＠bugs.koha-community.org 18 Jan '12

18 Jan '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5878 Bug #: 5878 Summary: overdue printing fixes and improvements Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Blocks: 5575 * misc/cronjob/printoverdues deals with utf-9 correctly * misc/cronjob/overdue_notices - display the due_date - deals with a branchcode parameter limit - deals with the various emails a patron has to select the 1st valid one (function in C4/Members) -- 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 24

[Bug 6868] New: Need a script to fix bad accountno data in accountlines
by bugzilla-daemon＠bugs.koha-community.org 18 Jan '12

18 Jan '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6868 Bug #: 6868 Summary: Need a script to fix bad accountno data in accountlines Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Patrons AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: wizzyrea(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com A pretty serious, and heretofore unidentified bug was causing the accountlines.accountno to increment based on the max accountno in the entire accountlines table. This would cause the SMALL_INT to reach max far more quickly than it should have. The bug that caused the problem was fixed with the patch that was submitted and pushed for bug 3498, but that wouldn't repair the problem in the data - each borrowernumber should have 32767 lines available to it, but in all databases that have been privy to this bug, that wouldn't be correct - numbers would have been skipped based on the max accountno at the time of the writeoff. What is needed is a script to clean up the accountno for each borrower, to increment it correctly and free all remaining available lines for each borrower. -- 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 14

[Bug 5411] New: Existing renewal rules are not translated into new rule structure on upgrade
by bugzilla-daemon＠bugs.koha-community.org 17 Jan '12

17 Jan '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5411 Summary: Existing renewal rules are not translated into new rule structure on upgrade Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Installation and upgrade (web-based installer) AssignedTo: henridamien(a)koha-fr.org ReportedBy: wizzyrea(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 I just updated a 3.00 db to a 3.03.00.003, and discovered that the renewal rules were not translated correctly into the new rule structure. Renewal rules (Itemtypes) pre-upgrade: http://screencast.com/t/kBEy1R79t8 Issuing rules pre-upgrade: http://screencast.com/t/Gw6Y0l9hvl6 Issuing rules post-upgrade: http://screencast.com/t/8AplaPge Item Types post-upgrade: http://screencast.com/t/P0x3jB27w It seems to me that the upgrade script should have created rules such as: default:<itemtype> <everything the same as default> <number of renewals for that itype> The only case where it wouldn't need to bother to create rules would be if all of the item types pre-upgrade had the same renewal limit This bug was likely introduced with DB revision 3.01.00.065 (thanks gmcharlt) -- 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 6439] New: In cataloguing all subfields are displayed, even with hidden=0
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '12

16 Jan '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6439 Bug #: 6439 Summary: In cataloguing all subfields are displayed, even with hidden=0 Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: magnus(a)enger.priv.no QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Created attachment 4326 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=4326 Screenshot of expanded subfields When adding a new MARC record, all subfields are expanded/visible by default, even though they have hidden = 0. See attached screenshot and selection from marc_subfield_structure below. mysql> select tagfield, tagsubfield, liblibrarian, hidden from marc_subfield_structure where tagfield = 800; +----------+-------------+------------------------------------------+--------+ | tagfield | tagsubfield | liblibrarian | hidden | +----------+-------------+------------------------------------------+--------+ | 800 | 8 | Andre karakteristika forbundet med navn. | 0 | | 800 | a | Navn. | 0 | | 800 | b | Nummer. | 0 | | 800 | c | Andre tilføyelser. | 0 | | 800 | d | Årstall forbundet med navn. | 0 | | 800 | j | Nasjonalitet. | 0 | | 800 | l | Språk | 0 | | 800 | q | Mer fullstendig navneform. | 0 | | 800 | t | Tittel for serien. | 0 | | 800 | u | Sorteringsdelfelt for delfelt $t. | 0 | | 800 | v | Bind, nummer etc. | 0 | | 800 | w | Sorteringsdelfelt for delfelt $a. | 0 | | 800 | x | ISSN. | 0 | +----------+-------------+------------------------------------------+--------+ This started happening around the introduction of T:T and/or version 3.4. Others have reported the same behaviour, so it should not be a NORMARC thing. I have seen it both on current master and 3.4.1. -- 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 10

[Bug 5297] New: emailLibrarianWhenHoldIsPlaced does nothing
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '12

16 Jan '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5297 Summary: emailLibrarianWhenHoldIsPlaced does nothing Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: critical Priority: P5 Component: Hold requests AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 There is a preference for the librarian to receive an email when a hold is placed, but this doesn't seem to work and others have said they don't even see any code to implement this... I'd rather it work, but if it can't work, then it shouldn't be a preference. -- 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 9

[Bug 5344] New: Invoice management improvements
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '12

13 Jan '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5344 Summary: Invoice management improvements Change sponsored?: Sponsored Product: Koha Version: rel_3_4 Platform: All URL: http://wiki.koha-community.org/wiki/Invoice_management _RFC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: paul.poulain(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 In Koha 3.2, the amount of the items in the parcel is deduced from the budget. We will add 3 fields and a form to let the librarian add additional fees to the parcel, a description of the added fees and a budget. Those fees will be deduced from a selected budget. May overlap with http://wiki.koha-community.org/wiki/Capturing_information_on_handling,_post…. -- 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 4

[Bug 6482] New: koha-create makes assumptions about the mysql username
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '12

12 Jan '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6482 Bug #: 6482 Summary: koha-create makes assumptions about the mysql username Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Packaging AssignedTo: robin(a)catalyst.net.nz ReportedBy: robin(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org If you do koha-create --request-db, need to change the user or db name, and then later do koha-create --populate-db, it doesn't work as it makes up the name from the command line, rather than referencing the config files. -- 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 9

[Bug 6227] New: deprecate NoZebra for 3.4.0
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '12

12 Jan '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6227 Bug #: 6227 Summary: deprecate NoZebra for 3.4.0 Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: gmcharlt(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org This is a last minute thing, but I propose that we deprecate NoZebra for 3.4.0. Specifically, * Remove the installer query asking to set Zebra or NoZebra * Update the description of the system preference to express that it's not recommended. -- 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 5

[Bug 6084] New: Missing translation markers in javascript alert messages
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '12

12 Jan '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6084 Bug #: 6084 Summary: Missing translation markers in javascript alert messages Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: I18N/L10N AssignedTo: frederic(a)tamil.fr ReportedBy: katrin.fischer(a)bsz-bw.de QAContact: koha-bugs(a)lists.koha-community.org It seems the translation tool is not picking up alert messages for translations when they are not properly formatted: Bad: alert("Your text will stay English forever!"); Good: alert(_("Your text will be translatable!")); A quick look at the code reveals a lot of translation problems in this area. -- 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 10