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

[Bug 9611] New: Changing the password hashing algorithm from MD5 to more secure Bcrypt
by bugzilla-daemon＠bugs.koha-community.org 06 Jun '14

06 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9611 Bug ID: 9611 Summary: Changing the password hashing algorithm from MD5 to more secure Bcrypt Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: srikanth(a)catalyst.net.nz CC: dpavlin(a)rot13.org In the current version of Koha, the passwords are stored as md5 hashes. MD5 hashing has its limitations, changing the hashing method to Bcrypt will improve in more secure password storage. -- You are receiving this mail because: You are watching all bug changes.

1 110

[Bug 8956] New: Split serials enumeration data into separate fields
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '14

05 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8956 Priority: P5 - low Change sponsored?: --- Bug ID: 8956 CC: colin.campbell(a)ptfs-europe.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Split serials enumeration data into separate fields Severity: enhancement Classification: Unclassified OS: All Reporter: kyle(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Serials Product: Koha Work to be done 1) Add an option 'published_end_date' to the serials table. It will only be used to represent the last issue date in a bound volume. 2) Data clean up: Extract the published dates from the existing enumeration field. Populate serials.publisheddate and serials.published_end_date with this data. 3) Strip the publishing dates from their enumeration fields (probably by simply deleting matched parentheses and everything in between them). 4) In order to break the “Numbered” field into three columns, add X, Y and Z columns to serials, as well as X, Y and Z descriptions columns to the subscription table. 5) Port existing data into these columns. Once all the enumeration fields are of the correct format, e.g., Vol. X No. Y, we can use everything preceding {X} as X_Description, and everything preceding {Y} until } as Y_Description. Another way to look at this is if we split on {?}, we will have all the label fields in order of use. Once we have the label fields, we can parse those out of the enumeration string, and we will have the set of values they represent. 6) Add a calendar widget for published on and expected on (serials-edit.pl). This will require librarians to enter new dates in the accepted format. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 67

[Bug 9851] New: way to get full records for purchase suggestions
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '14

05 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9851 Bug ID: 9851 Summary: way to get full records for purchase suggestions 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: nengard(a)gmail.com It would be nice if there were a way to get full records for purchase suggestions - a replace via Z39.50 option maybe. Right now most libraries order from a batch given to them from a vendor or from a Z target to get full records, but if they do this then their orders aren't linked to the suggestions. The only way to keep the suggestion linked is to order from it and in essence a brief record. I don't have a good suggestion here, but thought I should share the idea in case someone else has a solution. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 6070] New: On a new order defined from suggestion some fields were missing.
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '14

05 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6070 Bug #: 6070 Summary: On a new order defined from suggestion some fields were missing. Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: paul.poulain(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org (MT #4937) The missing fields : publicationyear, place, collectiontitle. More the layout has been modified. -- 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 54

[Bug 9677] New: Replace YUI button on notices and slips page with Bootstrap
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '14

03 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9677 Bug ID: 9677 Summary: Replace YUI button on notices and slips page with Bootstrap Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All URL: /cgi-bin/koha/tools/letter.pl OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org The notices and slips page uses YUI to generate the "New notice" button. It should use Bootstrap instead. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 9231] New: Batch revert staged MARC records fails if one or more records in a batch have been deleted.
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '14

03 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9231 Bug ID: 9231 Summary: Batch revert staged MARC records fails if one or more records in a batch have been deleted. Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com CC: m.de.rooy(a)rijksmuseum.nl -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 7934] New: Separate po file for help pages
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '14

03 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7934 Priority: P5 - low Change sponsored?: --- Bug ID: 7934 Assignee: frederic(a)tamil.fr Summary: Separate po file for help pages QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: katrin.fischer(a)bsz-bw.de Hardware: All Status: NEW Version: master Component: I18N/L10N Product: Koha I propose to split the help files out of the po file for the staff interface. It would allow to prioritise while working on translations and reduce the size of our biggest po file. A possible workflow for translators then could be: 1) Translate the OPAC, because patrons come first :) 2) Translate the staff interface, so staff can start using Koha and all buttons and links have their correct translated names 3) Translate help files while being able to look at the translated interfaces for the right names of elements -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 8277] New: item form not always showing when ordering
by bugzilla-daemon＠bugs.koha-community.org 31 May '14

31 May '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8277 Priority: P5 - low Change sponsored?: --- Bug ID: 8277 Assignee: koha-bugs(a)lists.koha-community.org Summary: item form not always showing when ordering Severity: critical Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Acquisitions Product: Koha When ordering in acquisitions the item form isn't always showing (see: http://screencast.com/t/USJxXyTO9) I have tested on 3 3.8.1 systems and see this on two of them .. I can't figure out what's going on, or why it works on one and not the others, but wanted to get the report out here. Nicole -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 5789] New: Fines don't work when items have null homebranch
by bugzilla-daemon＠bugs.koha-community.org 28 May '14

28 May '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5789 Bug #: 5789 Summary: Fines don't work when items have null homebranch Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: jcamins(a)cpbibliography.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com It seems that the fines cron job cannot handle databases that include items where homebranch, and possibly holdingbranch, are NULL. -- 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 10012] New: Remove all traces of NoZebraIndexes
by bugzilla-daemon＠bugs.koha-community.org 27 May '14

27 May '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10012 Bug ID: 10012 Summary: Remove all traces of NoZebraIndexes Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de CC: gmcharlt(a)gmail.com Created attachment 17314 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=17314&action=edit screenshot I found references to NoZebra in 3 places on current master: 1) In our updated 3.6 - 3.12 I still have the NoZebraIndexes show up in the local use preferences tab. Not sure if we can delete this system preference safely on updating existing installations, but it might be nice to do it with some other clean up. 2) The Italian installer files are still referencing NoZebraIndexes: / installer / data / mysql / it-IT / necessari / system_preferences.sql UPDATE systempreferences SET value = '\'title\' => \'200a,200c,200d,200e,225a,225d,225e,225f,225h,225i,225v,500*,501*,503*,510*,512*,513*,514*,515*,516*,517*,518*,519*,520*,530*,531*,532*,540*,541*,545*,604t,610t,605a\',\r\n\'author\' => \'200f,600a,601a,604a,700a,700b,700c,700d,700a,701b,701c,701d,702a,702b,702c,702d,710a,710b,710c,710d,711a,711b,711c,711d,712a,712b,712c,712d\',\r\n\'isbn\' => \'010a\',\r\n\'issn\' => \'011a\',\r\n\'biblionumber => \'0909\',\r\n\'itemtype\' => \'200b\',\r\n\'language\' => \'101a\',\r\n\'publisher\' => \'210c\',\r\n\'date\' => \'210d\',\r\n\'note\' => \r\n\'300a,301a,302a,303a,304a,305a,306az,307a,308a,309a,310a,311a,312a,313a,314a,315a,316a,317a,318a,319a,320a,321a,322a,323a,324a,325a,326a,327a,328a,330a,332a,333a,336a,337a,345a\',\r\n\'Koha-Auth-Number\' => \'6009,6019,6029,6039,6049,6059,6069,6109,7009,7019,7029,7109,7119,7129\',\r\n \'subject\' => \'600*,601*,606*,610*\',\r\n \'dewey\' => \'676a\',\r\n \'homebranch\' => \'995a,995b\',\r\n \'lcn\' => \'995k\'' WHERE variable = 'NoZebraIndexes'; 3) I can also see references to the nozebra indexes in the marc subfield table. For example 245$a. Be careful: After saving the field again, the information disappears (see screenshot). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16