March 2020 - Koha-bugs - lists.koha-community.org

[Bug 18193] New: Elasticsearch - adding new records from Z39.50 results in ' internal server error'
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '20

10 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18193 Bug ID: 18193 Summary: Elasticsearch - adding new records from Z39.50 results in 'internal server error' 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1 - Go to cataloging 2 - Select 'New from Z39/50' 3 - Search, find a record, import 4 - Save the record 5 - Error! Checking the logs you should see a dump of the record in xml - Koha chokes trying to access it as a MARC::Record In C4/Search.pm: 2492 If we are using elasticsearch, it'll already be a MARC::Record and this 2493 function needs a new name. 2494 2495 =cut 2496 2497 sub new_record_from_zebra { 2498 2499 my $server = shift; 2500 my $raw_data = shift; 2501 # Set the default indexing modes 2502 my $search_engine = C4::Context->preference("SearchEngine"); 2503 if ($search_engine eq 'Elasticsearch') { 2504 return $raw_data; 2505 } However, that doesn't seem to be the case, we are still getting marc XML, adding "&& 0" to the if and nullifying that section (or removing it) seems to solve the issue -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 18822] New: Advanced editor - Rancor - searching broken
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '20

10 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18822 Bug ID: 18822 Summary: Advanced editor - Rancor - searching broken Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It seems we expect MARC::Record objects, but get MarcXML for local searches - since we can double process the easiest method seem to be attempting conversion and using the updated record if successful -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 16728] New: Display Issued with entry (MARC21 777) to staff and OPAC normal view
by bugzilla-daemon＠bugs.koha-community.org 09 Nov '20

09 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16728 Bug ID: 16728 Summary: Display Issued with entry (MARC21 777) to staff and OPAC normal view Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: gmcharlt(a)gmail.com Reporter: eb(a)efdss.org QA Contact: testopia(a)bugs.koha-community.org The 777 field is not one of the fields currently displayed in staff or OPAC normal view. It is visible in the MARC view, but this does not enable the link (via subfield w) to the related record. The subfields are identical to 773 (which does display in the normal view). The main difference being the automatic text generated by the indicators. http://www.loc.gov/marc/bibliographic/concise/bd777.html This is a very important field for music libraries. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 23852] New: Merge biblio-title.inc and biblio-default-view.inc
by bugzilla-daemon＠bugs.koha-community.org 09 Nov '20

09 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23852 Bug ID: 23852 Summary: Merge biblio-title.inc and biblio-default-view.inc Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org The functionality in biblio-default-view.inc should be moved into biblio-title.inc. A "link" parameter will be set when the include file should show a linked title. -- You are receiving this mail because: You are watching all bug changes.

1 32

[Bug 24456] New: previousIssuesDefaultSortOrder and todaysIssuesDefaultSortOrder
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '20

06 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24456 Bug ID: 24456 Summary: previousIssuesDefaultSortOrder and todaysIssuesDefaultSortOrder Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com previousIssuesDefaultSortOrder and todaysIssuesDefaultSortOrder are backwards. If you choose 'earliest to latest' it sorts 'latest to earliest' and vise versa. Also the wording of todaysIssuesDefaultSortOrder is wrong. It says "Sort today's checkouts on the circulation page from {X} due date." With today's checkouts it does not sort by date due but by timestamp. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 24020] New: System Preference todaysIssuesDefaultSortOrder is not sorting properly
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '20

06 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24020 Bug ID: 24020 Summary: System Preference todaysIssuesDefaultSortOrder is not sorting properly Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The system preference todaysIssuesDefaultSortOrder allows the library to choose how their patron's checkouts are sorted on the circulation.pl page. Currently (18.11.10), this is not sorting by due date with either Earliest to Latest or Latest to Earliest chosen. 1. Find 3 items types that circulate for different lengths of time. 2. Checkout out these 3 items to a patron. 3. See that the items are not sorted by due date at all. I found this bug, and there is disagreement with the wording of the system preference, but the manual states " Asks: Sort today’s checkouts on the circulation page from ___ due date", that this should be sorting on Due Date, not checkout date/time. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14005 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 24789] New: Remove 'ITS' macro format
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '20

06 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24789 Bug ID: 24789 Summary: Remove 'ITS' macro format Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl During development there was support added for a secondary macro format, however, I do not believe it was fully supported or documented. It was based on another ILS macro format I believe As the rancor format was documented and explained I think we should remove the other format. According to original developer this was intended to be done before submission. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 20888] New: Allow use of boolean operator 'not' in item search
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '20

04 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20888 Bug ID: 20888 Summary: Allow use of boolean operator 'not' in item search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Sometimes it's helpful to be able to exclude items from an item search, for example 'all callnumbers starting with 9'. The item search form currently offers 'or' and 'and', but 'not' is not an option. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 51

[Bug 23237] New: Plugin allow [% INCLUDE %] from template
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '20

04 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23237 Bug ID: 23237 Summary: Plugin allow [% INCLUDE %] from template Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: frederic(a)tamil.fr QA Contact: testopia(a)bugs.koha-community.org >From a plugin template it is useful to be able to include other templates with [% INCLUDE %] directives. But TT module is used by Koha with absolute paths. Relative paths are forbidden for security reasons. A new param [% PLUGIN_DIR %] allow plugin templates to know where to find plugin home directory. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

[Bug 20023] New: Password recovery should be case insensitive
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '20

03 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20023 Bug ID: 20023 Summary: Password recovery should be case insensitive Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: philippe.blouin(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org When entering an email (or arguably, a userid) to recover the password, a user should not have to know or remember the casing of the given email. Quick exercise for a quick solution led to no results. $search_results = [ Koha::Patrons->search( { -or => { email => $email, emailpro => $email, B_email => $email } } ) ]; Using search_like is not available, and using email => { 'like', $email} does not lead to the intended result. Here's hoping a similarly simple fix exists. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 43