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

[Bug 16294] New: Add items to list via OPAC search occasionally repeats previous selections
by bugzilla-daemon＠bugs.koha-community.org 23 Apr '20

23 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16294 Bug ID: 16294 Summary: Add items to list via OPAC search occasionally repeats previous selections Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org While I haven't figured out an exact method to trigger, I have verified this on two independent 3.22.05 installations. If you have two lists and are adding items form a single search (say searchign for new items and adding to adult and child lists) Select some results, add to adult list Clear and select new results and add to child list Repeat try different options, suddenly the list of items to add will include random selections of previous items. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 21776] New: Set ACQ_NOTIF_ON_RECEIV notice message_transport_type to sms if syspref is enabled and patron has an smsalertnumber but no email
by bugzilla-daemon＠bugs.koha-community.org 23 Apr '20

23 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21776 Bug ID: 21776 Summary: Set ACQ_NOTIF_ON_RECEIV notice message_transport_type to sms if syspref is enabled and patron has an smsalertnumber but no email 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: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org At present the ACQ_NOTIF_ON_RECEIV is hardcoded to always have a message_transport_type of 'email' in C4::Acquisition::NotifyOrderUsers(). If a patron does not have an email address set then they will not receieve these notices. This patch utilizes the new system preference 'MessageTransportTypeFallbackToSMSIfNoPatronEmail' introduced in the patches on bug 21241. If this syspref is enabled then when a borrower has a smsalertnumber but no email address the ACQ_NOTIF_ON_RECEIV notice message_transport_type will be set to 'sms'. If the syspref is not enabled then the notice message_transport_type will not be set to 'sms' under any combination of conditions. i.e. the syspref prevents an automatic fallback to using sms which could be costly for libraries. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 19412] New: Add ability to email item suggestions through system preferences
by bugzilla-daemon＠bugs.koha-community.org 23 Apr '20

23 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19412 Bug ID: 19412 Summary: Add ability to email item suggestions through system preferences Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: alexbuckley(a)catalyst.net.nz Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org A library has requested this feature so it has a real world use case. The summary of what the patches attached to this bug report will do is create 2 new sysprefs: 1) To write in a borrower name and it will auto-complete with the borrower record storing the borrower number which is unlikely to change. When a patron makes a purchase suggestion this is sent to the email address associated with the borrower number (as long as the second (below) syspref is enabled). The reason the borrower number not the email address is going to be stored is that email addresses are more likely to be changed than the borrower number so from a usability point of view it is best to store the least likely to be changed value. 2) To enable or disable the emailing of suggestions to the borrower specified in syspref 1 (above) -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 19791] New: patron Modification log redirects to circulation page ( Koha 17.11)
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '20

22 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19791 Bug ID: 19791 Summary: patron Modification log redirects to circulation page (Koha 17.11) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: ayousef(a)kwareict.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Dear all, - Showing patron Modification log from koha 17.11 doesn't show any system log for the patron, Instead it redirects to (http://domain_name/cgi-bin/koha/circ/circulation.pl?borrowernumber=) - Just try filling the (Librarian:) field with the borrower number instead of the (Object:) field, And leave the (Object:)field empty, You will see what I mean. - Also you can test it here (http://koha.adminkuhn.ch:8080/cgi-bin/koha/tools/viewlog.pl?do_it=1&modules…) It's a demo site for koha 17.11 provided by koha community here (https://koha-community.org/demo/) use (demo/demo) for logging in, Then test it for this user (Herr Demokrit Morgenstern (1)), Also the problem was not in koha 17.05, You can test it using Bywater demo version (koha17.05), You will see that it working fine in koha (17.05). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 23925] New: Value builder plugin to check ISBN validity
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '20

21 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23925 Bug ID: 23925 Summary: Value builder plugin to check ISBN validity Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This patch adds a new value builder plugin ISBN.pl, which should be attached to field 020a. The plugin will perform a simple checksum checking when trying to save the record, and inform the user that the ISBN is illegal if the checksum doesn't match. The ISBN plugin is a test case for additional value builder plugin functionality that lets the plugins check field values and prevent saving if so desired. The example plugin has been updated with information on how to write a pre-save check function. To test: 1) Add the ISBN.pl plugin to the field 020a in MARC subfield structure admin. 2) Go to cataloguing and try to save the record, no complaints about the ISBN (Because the plugin will not complain about empty field) 3) Enter something in the 020a field and try to save, you should receive a complaint about illegal ISBN. 4) Enter a valid ISBN (eg. 978-951-1-27641-8) and try to save, there should be no complaints about the ISBN. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 16312] New: Koha::Logger overload configuration for command line scripts verbosity levels
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '20

21 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16312 Bug ID: 16312 Summary: Koha::Logger overload configuration for command line scripts verbosity levels Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org To be able to set the -v|--verbose flags from the command line and still use Koha::Logger, we must be able to overload/extend default appenders and log levels on a easy case-by-case basis directly from the Perl-code. To deploy verbose mode in a commandline script, add the following code to your cronjob/script: use C4::Context; use Koha::Logger; C4::Context->setCommandlineEnvironment(); Koha::Logger->setConsoleVerbosity( 1 || -3 || 'WARN' || ... ); See attached tests and perldoc for more info. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 16303] New: Koha::Logger appenders for interfaces 'commandline' and 'sip2'
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '20

21 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16303 Bug ID: 16303 Summary: Koha::Logger appenders for interfaces 'commandline' and 'sip2' Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 16509] New: Koha::Logger dies when log4perl.conf has FileAppender files with different permissions, also compatibility with logrotate
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '20

21 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16509 Bug ID: 16509 Summary: Koha::Logger dies when log4perl.conf has FileAppender files with different permissions, also compatibility with logrotate Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org We define all the logging configurations for various interfaces in log4perl.conf. Interfaces log to files, and every interface can run as a different user. Every time you execute a Perl program that uses Koha::Logger and Log::Log4perl, Log::Log4perl tries to open all the filehandles in the log4perl.conf. Since different interface logs should be owned by different users, this crashes the system. Can't sysopen /home/koha/koha-dev/var/log/intranet.log (Permission denied) at /usr/local/share/perl/5.18.2/Log/Log4perl/Appender/File.pm line 120. This patch introduces lazy-loading parameters to the FileAppenders, so they open only the files they need. Koha::Logger makes sure they always use the correct log file for the interface (opac, intranet, commandline, sip, restapi, ...). log4perl.appender.CLI.syswrite=true log4perl.appender.*.create_at_logtime=true Also while working on this bug identified as a target of opportunity some useful extra parameters for the appenders. log4perl.appender.*.syswrite=true This should solve concurrency issues under multithreaded Perl-apps such as what Mojolicious should be ran as. log4perl.appender.*.recreate=true This polls the filesystem path to the logfile for changes. Eg. if logrotate of the admin might move the logfile for storage purposes, Log4perl can recreate the missing file, instead of writing to the moved file. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 19288] New: Holds placed on a specific item after a next available hold will show varied results
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '20

21 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Bug ID: 19288 Summary: Holds placed on a specific item after a next available hold will show varied results Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests 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(a)bywatersolutions.com, nick(a)bywatersolutions.com When a hold is placed on an item as "next available" and then a hold is placed on same item, but it is placed on a specific copy, Koha will show the specific copy hold on the status screen of the item incorrectly and sometimes give the hold to that specific copy before next available. On 16.11.07 Steps: 1. Place a "next available" hold on an item with only one copy. 2. Place a "specific item" hold this same record. 3. Looking at the holds- they are in the correct order 4. Look at the status of the item in the holdings table you can see that the hold for the "specific copy" is next- not the next available. 5. Check this item in and see which hold gets filled first. 6. Results vary on the process of who gets the hold when checking in this item . Sometimes the specific item will get filled before the hold that was placed as next available even though the "Next available" hold was placed first. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 44

[Bug 17687] New: Rename column subscriptionhistory.recievedlist to receivedlist
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '20

21 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17687 Bug ID: 17687 Summary: Rename column subscriptionhistory.recievedlist to receivedlist Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 2