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

[Bug 11911] Add separate permission for managing suggestions
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '20

03 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11911 Phil <gormanp(a)parliament.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=26905 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11175] Show the parent record's component parts in the detailed views
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '20

03 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11175 --- Comment #91 from Joonas Kylmälä <joonas.kylmala(a)helsinki.fi> --- (In reply to Nick Clemens from comment #90) > Koha/SearchEngine/Elasticsearch/Search.pm > 298 =item C<$max_results> > 299 > 300 The max number of results to return. The default is 100 (because > unlimited > 301 is a pretty terrible thing to do.) > > Probably this should be a syspref? For Zebra we don't hardcode a limit, but > maybe we should not return everything and it would be better to have one > syspref to control both> I don't think a global max results syspref would be a good idea. We could probably identify all calls of simple_search_compat() and then those that require more than 100 results, like this feature, should handle this case by making more calls using offset or different max results value. So it seems like we are now back to the question whether implement AJAX as was discussed earlier but it would be useful to have a rest api endpoint for component parts in that case. Or we could also say we are fine with 100 results at this point in time. What are your opinions on this? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11460] Correction to default itemcallnumber system preference in UNIMARC
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '20

03 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11460 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@ptfs-europe | |.com Status|Signed Off |Passed QA --- Comment #6 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- Change makes sense, passing QA -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11460] Correction to default itemcallnumber system preference in UNIMARC
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '20

03 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11460 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #112762|0 |1 is obsolete| | --- Comment #5 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- Created attachment 112896 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=112896&action=e… Bug 11460: Remove MARC21 default mapping from itemcallnumber system preference The mapping in the itemcallnumber system preference is only valid for MARC21 libraries using DDC classification, but not for libraries using UNIMARC or other classification. This patch suggests to remove the default mapping and start new installations with an empty value. To test: - On an emtpy database - Apply patch - Run the web installer, selecting either MARC21 or UNIMARC - Verify that the itemcallnumber system preference is empty - Verify the description now also include examples for UNIMARC Signed-off-by: David Nind <david(a)davidnind.com> Signed-off-by: Martin Renvoize <martin.renvoize(a)ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 25759] New: Invoices hyperlink is broken on edifactmsgs.pl
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '20

03 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25759 Bug ID: 25759 Summary: Invoices hyperlink is broken on edifactmsgs.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The "Invoices" hyperlink on edifactmsgs.pl has always been broken. We can parse out the invoice number from the message and have the link search for that invoice number in Koha. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[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

[Bug 11999] Add two checks in CanBookBeReserved and CanItemBeReserved
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '20

03 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11999 --- Comment #123 from Joonas Kylmälä <joonas.kylmala(a)helsinki.fi> --- I didn't realize the follow-ups here removed those git merge conflict resolution hints. It would still probably be better if the conflicts were solved in the patches they happen. If I review the patch "Test improvements + check maxreserves" it contains merge resolution and test improvements, so two things, git commits should do just one thing. Also "Bug 11999: (QA follow-up)" doesn't say what it does. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11999] Add two checks in CanBookBeReserved and CanItemBeReserved
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '20

03 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11999 Joonas Kylmälä <joonas.kylmala(a)helsinki.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA CC| |joonas.kylmala(a)helsinki.fi --- Comment #122 from Joonas Kylmälä <joonas.kylmala(a)helsinki.fi> --- The attached patch contains git merge conflict resolution hints. Also, if I understand correctly maxreserves is already checked in some other places in some other way, it would be really good idea to have a patch then to convert those calls to just use CanBookBeReserved(). -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7607] Advanced search: Index and search term don't match when leaving fields empty
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '20

03 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7607 --- Comment #20 from David Cook <dcook(a)prosentient.com.au> --- (In reply to David Cook from comment #17) > Actually, we have a customization that does something like this patch, and > it actually causes the problem to be worse. > > If you set the idx element value to '', the idx select elements don't get > sent, but the empty q input elements do. So you wind up with a mismatched > number of parameters. This isn't true *if* you provide an option in the select list with a value of ''. So adding that option element in the list would help, if we want to use the Javascript in the patches. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7607] Advanced search: Index and search term don't match when leaving fields empty
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '20

03 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7607 --- Comment #19 from David Cook <dcook(a)prosentient.com.au> --- (In reply to David Cook from comment #18) > And if people are worried about ugly URLs, then I think they should open a > new bug report to remove unused search boxes in advanced search from the DOM > so they don't get submitted with the HTML form. Alternatively, we could only show 1 search box on the advanced search page, and make people add more search boxes as needed. -- You are receiving this mail because: You are watching all bug changes.

1 0