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

[Bug 11994] Fix OpenSearch discovery in the OPAC
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '20

13 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11994 Aleisha Amohia <aleisha(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to master |Pushed to stable CC| |aleisha(a)catalyst.net.nz -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9715] Various combinations of prefs QueryAutoTruncate, QueryFuzzy and QueryWeightFields conflict
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '20

13 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9715 --- Comment #9 from Pablo AB <pablo.bianchi(a)gmail.com> --- I just formatted Martin Renvoize's comment 5. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 25804] New: Remove HTML from title tag of bibliographic detail page
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '20

12 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25804 Bug ID: 25804 Summary: Remove HTML from title tag of bibliographic detail page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Staff Client Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, testopia(a)bugs.koha-community.org Depends on: 12093 Bug 12093 accidentally added some <span> tags to the <title> tag of the bibliographic detail page. They should be removed. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12093 [Bug 12093] Add CSS classes to item statuses in detail view -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 12093] Add CSS classes to item statuses in detail view
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '20

12 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12093 --- Comment #21 from Aleisha Amohia <aleisha(a)catalyst.net.nz> --- enhancement, not backported to 19.11.x. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 25975] New: Receiving a manual transfer triggers another transfer (non-floating collection)
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '20

12 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25975 Bug ID: 25975 Summary: Receiving a manual transfer triggers another transfer (non-floating collection) 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I'm putting this out there, I'm not sure if the use case is something that would work in all libraries or if I'm completely beside the point... If the circulation rules are set to 'item returns home' and you do a manual transfer (for whatever reason, like that library needed that book for a display or something), when the other library receives the transfer, it is automatically put back in transit to go back to its home library. Which is kind of logical, but not? Why would you do a manual transfer if it's just to be sent back? I can see several use cases for this, outside of a floating collection situation: 1) special display A library wants to make a special display and asks the other libraries to send some material over. This system does not have a floating collection policy, but they still exchange materials depending on needs (e.g. holds). If the other libraries send 'manual' transfers, the library making the special display receives them by checking them in (this currently triggers a transfer back to the home library), puts them on display. If a user checks them out and then returns them, the transfer to home branch will be triggered. If no users check them out after the end of the display, the library can send them back by checking them in. 2) temporary high demand A school board loans out textbooks at the beginning of each year. Some schools have more students than others so they ask other libraries to send their surplus of textbooks over to satisfy the demand. Again, no floating policy for general circulation. The smaller libraries send their surplus textbooks via 'manual' transfers, the larger library receives the transfers by checking them in (this currently triggers a transfer back to home branch). They check them out to students who haven't had their textbooks yet. When the students bring back the textbooks, the check in triggers a transfer back to the home library. If the library received more than needed, they can send back the texts to their home library by checking them in. 3) course reserves Similar to the two previous cases. A university has a course and needs some material from other libraries for course reserves. 4) biblio-mobile Again no floating policy, but during the summer, the library system has a biblio-bus going to local parks. All libraries temporarily contribute to the biblio-bus collection, but they want their materials back after. In all these cases, the collections don't normally float, the materials are only needed temporarily, and there is not one specific user who requested the materials through a hold. Are manual transfers not the way to go in these cases? I think there are two potential solutions to this : 1) receiving a transfer is either not done through checkin or the checkin to receive a transfer does not trigger another transfer (if there is an unreceived 'manual' branch transfer, and the item is checked in at the destination library, do not send back home) 2) add a 'cancel transfer' button to the transfer dialog (when the destination library receives the transfer through a checkin, a transfer back home is triggered, but the receiving library could cancel the transfer in order to keep the item). Right now, you can only click 'OK' or 'Print slip'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 9715] Various combinations of prefs QueryAutoTruncate, QueryFuzzy and QueryWeightFields conflict
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '20

12 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9715 --- Comment #8 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hi Pablo, thx for the systematic testing! (In reply to Pablo AB from comment #7) > ## Setting Combination > > QueryAutoTruncate - Automatically > QueryFuzzy - Try/Don't try > QueryStemming - Try/Don't try > > [Search Terms : Number of Results : Notes] > frogs toads : 8 : > frogs and toads : 7 : The missing record here contains 'toadstools' - > truncation not working correctly? I think this is due to it not containing frogs. The and is (as far as I know) interpreted as boolean operator. > frogs or toads : 29 : 'And' and 'or' treated as search operators. > Adv. Search: frogs and toads : 8 : Apostrophe search not working What do you mean by Apostrophe search? > QueryAutoTruncate - only if * added > QueryFuzzy - don't try > QueryStemming - don't try > > frogs toads : 7 : > frogs and toads : 5 : And is treated as a search word > frogs or toads : 0 : > Adv. Search: frogs and toads : 7 : Apostrophe search not working > > QueryAutoTruncate - only if *added > QueryFuzzy - don't try > QueryStemming - Try > > frogs toads : 0 : No results for any search > frogs and toads : 0 : > frogs or toads : 0 : > Adv. Search: frogs and toads : 0 : It's hard to tell without seeing the records what's going on there and if it's correct or not. > QueryAutoTruncate - only if *added > QueryFuzzy - Try > QueryStemming - don't try/Try > > frogs toads : 0 : No results for any search > frogs and toads : 0 : > frogs or toads : 0 : > Adv. Search: frogs and toads : 0 : > > Queryfuzzy can't be used with ICU in use? I think that is possible, we have had to play around with settings when we started using ICU in the first library. ,ext (exact field content) search is also not working with ICU as far as I know. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 25923] New: pr-BR translations breaks Tools (Ferramentas) menu and submenus
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '20

12 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25923 Bug ID: 25923 Summary: pr-BR translations breaks Tools (Ferramentas) menu and submenus Change sponsored?: --- Product: Project Infrastructure Version: unspecified Hardware: All OS: Linux Status: NEW Severity: major Priority: P5 - low Component: Bugzilla Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: steven.schmieder(a)gmail.com Created attachment 106508 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=106508&action=e… Examples of erroneous lines in pt-BR code When updating translations to Koha version 20.05.01 using pt-BR (Brazilian Portuguese) coding errors are introduced into several files making the Tools (Ferramentas) and submenus inoperable. An "internal server error" message is displayed. The coding errors are found in at least two file that I can identify: /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/pt-BR/modules/tools/tools-home.tt /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/pt-BR/includes/tools-menu.inc For example (there is more than one error in each file), in the file "tools-home.tt" at line 16, the original file has: [% IF (CAN_user_tools_manage_patron_lists || || CAN_user_clubs CAN_user_tools_moderate_comments || || CAN_user_tools_import_patrons CAN_user_tools_edit_notices || || CAN_user_tools_edit_notice_status_triggers CAN_user_tools_label_creator || || CAN_user_tools_delete_anonymize_patrons CAN_user_tools_edit_patrons || || CAN_user_tools_batch_extend_due_dates CAN_user_tools_moderate_tags || (CAN_user_tools_batch_upload_patron_images && Koha.Preference ('patronimages') ) ) %] <h3>Usuários e circulação</h3> The line should be: [% IF (CAN_user_tools_manage_patron_lists || CAN_user_clubs || CAN_user_tools_moderate_comments || CAN_user_tools_import_patrons || CAN_user_tools_edit_notices || CAN_user_tools_edit_notice_status_triggers || CAN_user_tools_label_creator || CAN_user_tools_delete_anonymize_patrons || CAN_user_tools_edit_patrons || CAN_user_tools_batch_extend_due_dates || CAN_user_tools_moderate_tags || (CAN_user_tools_batch_upload_patron_images && Koha.Preference ('patronimages') ) ) %] <h3>Usuários e circulação</h3> In the file "tools-menu.inc" at line 8, the original file has: [% IF (CAN_user_tools_manage_patron_lists || || CAN_user_clubs CAN_user_tools_moderate_comments || || CAN_user_tools_import_patrons CAN_user_tools_edit_notices || || CAN_user_tools_edit_notice_status_triggers CAN_user_tools_label_creator || || CAN_user_tools_delete_anonymize_patrons CAN_user_tools_edit_patrons || || (CAN_user_tools_moderate_tags CAN_user_tools_batch_upload_patron_images && Koha.Preference ('patronimages') ) ) % ] <h5>Usuários e circulação</h5> The line should be: [% IF (CAN_user_tools_manage_patron_lists || CAN_user_clubs || CAN_user_tools_moderate_comments || CAN_user_tools_import_patrons || CAN_user_tools_edit_notices || CAN_user_tools_edit_notice_status_triggers || CAN_user_tools_label_creator || CAN_user_tools_delete_anonymize_patrons || CAN_user_tools_edit_patrons || CAN_user_tools_moderate_tags || ( CAN_user_tools_batch_upload_patron_images && Koha.Preference('patronimages') ) ) %] <h5>Usuários e circulação</h5> There are other errors in both files. Theses are just two examples. Running "koha-translate --update pt-BR" reproduces the erroneous files. Manually editing both files solves the problem. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 6815] Capture member photo via webcam
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '20

12 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6815 Christopher Brannon <cbrannon(a)cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |25980 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25980 [Bug 25980] Capture cover image via webcam -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 6815] Capture member photo via webcam
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '20

12 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6815 Christopher Brannon <cbrannon(a)cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off --- Comment #73 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- Couldn't sign of in devbox, so I signed off on sandbox. Doesn't work in sandbox, but worked in devbox. I am signing off as it works as described, but I would like to encourage that the button be placed in the exiting modal for browsing and uploading. Otherwise, it works! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 6815] Capture member photo via webcam
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '20

12 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6815 Christopher Brannon <cbrannon(a)cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0