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

[Bug 12281] New: RTL display for records using 880 broken in Bootstrap
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '14

28 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12281 Bug ID: 12281 Summary: RTL display for records using 880 broken in Bootstrap Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Created attachment 28319 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=28319&action=edit Correct display of results list in prog theme If you are using 880 fields for cataloging the original script and the script is RTL, the text should be display aligned right instead of left. This is still working in prog, but not in bootstrap on current master. Attaching some screenshots. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 13095] New: An email will be sent shortly
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '14

28 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13095 Bug ID: 13095 Summary: An email will be sent shortly Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 13112] New: Feature Request -- Add name of template file in html comment for each '.tt' file.
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '14

28 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13112 Bug ID: 13112 Summary: Feature Request -- Add name of template file in html comment for each '.tt' file. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org For the purposes of trouble-shooting, it would be helpful to be able to do a a browser search from with 'view page source' to quickly determine the name of the template being used. I would suggest adding the file path, starting with either 'intranet-tmpl' or 'opac-tmpl', e.g. <-- TEMPLATE FILE NAME: opac-tmpl/bootstrap/en/modules/opac-results.tt --> -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 13129] New: HTML and JS escapes missing in unimarc_field_4XX.tt
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '14

28 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13129 Bug ID: 13129 Summary: HTML and JS escapes missing in unimarc_field_4XX.tt Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: fridolyn.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In cataloging plugin unimarc_field_4XX.tt some template vars should be HTML or JS escaped in case they contain characters of the language. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 11068] New: Update MARC21 es-ES default frameworks fields and translation
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '14

28 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11068 Bug ID: 11068 Summary: Update MARC21 es-ES default frameworks fields and translation Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: bgkriegel(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr es-ES MARC21 bibliographic and authorities need to be updated and translated. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 11007] New: Useless column cancelledby in aqorders table
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '14

28 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11007 Bug ID: 11007 Summary: Useless column cancelledby in aqorders table Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Database Assignee: gmcharlt(a)gmail.com Reporter: mathieu.saby(a)univ-rennes2.fr QA Contact: testopia(a)bugs.koha-community.org In Schemaspy, column cancelledby is reported as "not used? always NULL". "grep -r cancelledby *" give this result, so I suppose it is true : blib/INTRANET_CGI_DIR/installer/data/mysql/kohastructure.sql: `cancelledby` varchar(10) default NULL, -- not used? always NULL blib/INTRANET_CGI_DIR/installer/data/Pg/kohastructure.sql:cancelledby varchar(10) default NULL, installer/data/mysql/kohastructure.sql: `cancelledby` varchar(10) default NULL, -- not used? always NULL installer/data/Pg/kohastructure.sql:cancelledby varchar(10) default NULL, t/db_dependent/Acquisition.t: cancelledby I propose the deletion of this column. M. Saby -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 8837] New: Dewey cn_sort inaccurate
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '14

28 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8837 Priority: P5 - low Change sponsored?: --- Bug ID: 8837 CC: m.de.rooy(a)rijksmuseum.nl Assignee: gmcharlt(a)gmail.com Summary: Dewey cn_sort inaccurate Severity: normal Classification: Unclassified OS: All Reporter: joy(a)bywatersolutions.com Hardware: All Status: NEW Version: rel_3_8 Component: Cataloging Product: Koha The items.cn_sort value created by the Dewey.pm does not create accurate sorting (cn_sort) values. Example 1: Three similar callnumbers do not sort the same way . Suggested fix is to replace / with spaces. (note: if any token[$i] consists of only one space when sort routine progresses it should be disregarded/removed) +--------------------------+--------------------------------+ | itemcallnumber | cn_sort | +--------------------------+--------------------------------+ | 971/P23w/v.1-2/pt.8 | 971P23WV_000000000000000_12PT_ | | 971.01/P23w/v.1-2/pt.6-7 | 971_000000000000000_01P23WV_12 | | 971.01/P23w/v.1-2/pt.7 | 971_01P23WV_12PT_7000000000000 | +--------------------------+--------------------------------+ That would improve the cn_sort values: Manually replaced '/' with spaces in items.itemcallnumber to illustrate that process. +--------------------------+--------------------------------+ | itemcallnumber | cn_sort | +--------------------------+--------------------------------+ | 971.01 P23w v.1-2 pt.6-7 | 971_010000000000000_P23W_V_12_ | | 971.01 P23w v.1-2 pt.7 | 971_010000000000000_P23W_V_12_ | | 971 P23w v.1-2 pt.8 | 971_P23W_V_12_PT_8000000000000 | +--------------------------+--------------------------------+ However, the sort routine will adjust the second 'token' it finds that is all digit. In the above case it is in the last callnumber (the 8) which is padded. A better option would be to only adjust the only adjust the second 'token' if it is the second token. Further if there are two token and the second token is not $token[2] then pad the first token with _zeros An ideal result would be: +--------------------------+--------------------------------+ | itemcallnumber | cn_sort | +--------------------------+--------------------------------+ | 971 P23w v.1-2 pt.8 | 971_000000000000000_P23W_V_12_ | | 971.01 P23w v.1-2 pt.6-7 | 971_010000000000000_P23W_V_12_ | | 971.01 P23w v.1-2 pt.7 | 971_010000000000000_P23W_V_12_ | +--------------------------+--------------------------------+ note: 30 character limit does chop the rest of the cn_sort. Without an update to the database, this will be 'collateral damage'. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 13083] New: Hard-coded " by " in opac-tags.pl
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '14

28 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13083 Bug ID: 13083 Summary: Hard-coded " by " in opac-tags.pl Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: pasi.kallinen(a)pttk.fi QA Contact: testopia(a)bugs.koha-community.org ($biblio->{author}) and $_->{bib_summary} .= " by " . $biblio->{author}; -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 12788] New: Refine search displays 4xx fields from authority records
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '14

28 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12788 Bug ID: 12788 Summary: Refine search displays 4xx fields from authority records Change sponsored?: --- Product: Koha Version: 3.16 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: eb(a)efdss.org QA Contact: testopia(a)bugs.koha-community.org When looking at the results from a search, the Refine Search column displays the headings from the 1xx and 4xx fields in the authorities. This means that all the variations on a term that are not used in the catalog appear as search options. (For example the half dozen different ways to spell and punctuate Ralph Vaughan Williams). This should not be happening. It is confusing to the patrons and needlessly extends the list of search terms (as all the 4xx terms point back to the correct 1xx) Heather Hernandez commented: "if you click one of the facets from a 400 field, it does return correct results based on the 100 field--e.g., if you do a search on Sea Poetry: http://keys.bywatersolutions.com/cgi-bin/koha/opac-search.pl?q=sea+poetry And you click on the facet "Sinbad," (a 400 in the aut record) it will return the two results by "Dingle, Aylward Edward," (which is the 100 field in that aut record), but the user will have no idea why--there's no evidence that your search has been redirected due to your selecting a "see from" reference." Chris Cormack wrote: "We think we have tracked it down to something to do with fix for large MARC records But are continuing to work on it. It is something to do with the IncludeSeeFromInSearches systempreference If you have had this on, or have it on, it makes the links so that when you search for the 400, you can still find results. To do this its linked, however in 3.12.x and 3.14.x it appears these links were filtered out when building the facets and for some reason this is not occuring. I think its to do with an indicator of z that gets added to 100 (of the biblio) on indexing (you wont see it on the record itself, its added when indexing) The old code got rid of this, so no, this is not required behaviour". -- You are receiving this mail because: You are watching all bug changes.

1 36

[Bug 12031] New: Task Scheduler not sending mail
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '14

28 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12031 Bug ID: 12031 Summary: Task Scheduler not sending mail Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Task Scheduler Assignee: gmcharlt(a)gmail.com Reporter: liz(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org The task scheduler to schedule reports from the UI is not passing the correct command to runreport.pl, so it doesn't send email correctly. To replicate: 1. make sure that your user is not in at.deny, and (if applicable/necessary) is in at.allow Useful, but not required step: make sure email can be sent from your server, also helpful is access to the Koha user's mail box (to see the bounce messages) 2. create a saved sql report to run 3. Go to Tools -> Task Scheduler and schedule a job to be run, and results emailed to you 4. note that you do not get an email, also note that the Koha user has received a bounce message with the report contents and an error message: [Thu Apr 3 14:02:00 2014] runreport.pl: ERROR: No saved report report-recipient(a)the.email.address.you.specified found at /usr/share/koha/intranet/cgi-bin/tools/runreport.pl line 193. -- You are receiving this mail because: You are watching all bug changes.

1 58