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

[Bug 11990] New: Holds ratio report sorts wrong
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '14

29 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11990 Bug ID: 11990 Summary: Holds ratio report sorts wrong Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: robin(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 26538 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26538&action=edit Screenshot showing the wrong sorting The "holds" column in the holds ratio report sorts lexicographically rather than numerically. It probably should also sort in reverse by default, so the things with more holds show at the top. See screenshot. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 10862] New: Add an search history for the staff interface
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '14

29 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10862 Bug ID: 10862 Summary: Add an search history for the staff interface Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Like OPAC, the search history will be available for the staff interface. -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 10677] New: C4::Search::GetSearchHistory is broken and unused
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '14

29 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10677 Bug ID: 10677 Summary: C4::Search::GetSearchHistory is broken and unused 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: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org C4::Search::GetSearchHistory does not work, as it contains a SQL syntax error: SELECT FROM search_history WHERE... Its broken state is not visible to users, however, because that routine is not used -- opac-search-history.pl is doing a direct SQL query, which is not ideal. GetSearchHistory should be fixed, then put in use. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 10807] New: OPAC: There is no authority search history
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '14

29 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10807 Bug ID: 10807 Summary: OPAC: There is no authority search history Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 79

[Bug 9687] New: Subject Searching not working for records with parentheses
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '14

28 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9687 Bug ID: 9687 Summary: Subject Searching not working for records with parentheses Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: elliott(a)bywatersolutions.com When clicking on a subject with parentheses in the item detail page using XSLT style sheets you will get no results. However, after removing the parentheses from the search string you get the correct results. This does not occur when the XSLT style sheets are not in use (AKA normal mode). -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 11593] New: subtag_registry.sql files contain the same information for each language
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '14

28 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11593 Bug ID: 11593 Summary: subtag_registry.sql files contain the same information for each language Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)pttk.fi QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr For each language in the installation, there's a mandatory subtag_registry.sql -file, that contains the language names. Each of those files contain the same language information. This is unnecessary duplication, and makes adding new install languages harder, because the same information needs to be added to each of those files. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[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 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