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

[Bug 31665] New: 952$d ( Date acquired ) no longer prefills with todays date when focused
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '23

10 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31665 Bug ID: 31665 Summary: 952$d ( Date acquired ) no longer prefills with todays date when focused Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Before the introduction of Flatpickr, when adding a new item if you clicked on the date acquired field, and it was empty, it would be prefilled with today's date. It would be useful if we could get that functionality back. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 32674] New: When placing a hold in OPAC page explodes into error 500
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '23

10 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32674 Bug ID: 32674 Summary: When placing a hold in OPAC page explodes into error 500 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major 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 CC: jonathan.druart+koha(a)gmail.com When trying to place a hold on a record in the OPAC, we get an error 500 in 22.11.01. The error in the logs is: DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Column 'biblionumber' in where clause is ambiguous at /usr/share/koha/lib/Koha/Objects.pm line 394 With Joubu's help we tested following change that fixes the issue: opac/opac-reserve.pl, L.338 - biblionumber => $biblioNumber, + "me.biblionumber" => $biblionumber, There is no test plan as we haven't figured out yet, why this happens for some records and not for others. Items and records look normal, no hidden items on the record and no 773 etc. :) -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 32383] New: Indefinite debarments should not be recorded with an expiration date of '9999-12-31'
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '23

10 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32383 Bug ID: 32383 Summary: Indefinite debarments should not be recorded with an expiration date of '9999-12-31' 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: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 11846 This all might be a regression, looking at Bug 11846 from 2014. To recreate: - have a patron - create a manual restriction for your patron, entering a reason but not a date - confirm that the patron account shows your restriction with an expiration date of "indefinite" - in reports, SELECT * FROM borrower_debarments WHERE borrowernumber= [your patron] - confirm borrower_debarments.expiration is null - in reports, SELECT * FROM borrowers WHERE borrowernumber= [your patron] - confirm borrowers.debarred='9999-12-31' This will cause a lot of issues in 7,977 years. Here in the year 2022, it's generally incorrect and confusing to be using a far-future date to denote "indefinite," and is made more confusing by the fact that borrowers and borrower_debarments don't handle it the same way. This also means one cannot create indefinite debarments via patron import. If one's CSV contains a debarredcomment value without a debarred value, no restriction is created. If one's CSV contains a debarred value of '9999-12-31,' that is treated literally and the restriction is given an expiration date of '9999-12-31.' Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11846 [Bug 11846] Correct database update for debarments with 9999-12-31 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 32576] New: ILL needs the page-section treatment
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '23

10 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32576 Bug ID: 32576 Summary: ILL needs the page-section treatment Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Blocks: 31757 The ILL module is using panels when it should now use page-section cards instead. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31757 [Bug 31757] Add 'page-section' where it's missing -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 32293] New: Terminology: Some budgets are not defined in item records
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '23

10 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32293 Bug ID: 32293 Summary: Terminology: Some budgets are not defined in item records Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: Academy Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The error message should use 'funds' not 'budgets': koha-tmpl/intranet-tmpl/prog/js/addorderiso2709.js: alert( __("Some budgets are not defined in item records") ) I think that this one appears when you try to add orders from a staged file, but leave the fund empty. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 32503] New: waitingreserves: UK format dates not sorting correctly
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '23

10 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32503 Bug ID: 32503 Summary: waitingreserves: UK format dates not sorting correctly 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Dates in the waiting reserves page are not sorting correctly when UK dates are used. When you view the waiting reserves page with a large number of resereves, and you sort them by 'Waiting since' or 'Date hold placed', if the system uses UK date format (DD/MM/YYYY) the sorting doesn't working correctly - for example, you might see: 02/02/2017 03/03/2017 08/02/2017 10/01/2017 16/12/2016 instead of the correct order, which would be: 16/12/2016 10/01/2017 02/02/2017 08/02/2017 03/03/2017 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 20228] New: Circulation alerts don't take AutoEmailPrimaryAddress system preference into account
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '23

10 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20228 Bug ID: 20228 Summary: Circulation alerts don't take AutoEmailPrimaryAddress system preference into account Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: sophie.meynieux(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In C4::Message->enqueue(), to_address is email or if not defined emailpro or if not defined B_email, irrespective of the value of AutoEmailPrimaryAddress system preference -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 32404] New: Two-factor authentication for staff client doesn't work for all staff accounts
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '23

09 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32404 Bug ID: 32404 Summary: Two-factor authentication for staff client doesn't work for all staff accounts 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: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org With the new feature, Two-factor authentication for staff client - TOTP, staff permissions seem to be needed to activate this: my ( $template, $loggedinuser, $cookie ) = get_template_and_user( { template_name => 'members/two_factor_auth.tt', query => $cgi, type => 'intranet', flagsrequired => { editcatalogue => '*' }, } ); which means that only staff with top-level catalogue permissions can activate their two-factor authentication. However, I believe this should be allowed by all staff accounts which would change this feature to allow staff to have just the "Staff access, allows viewing of catalogue in staff interface (catalogue) " permission. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 30953] New: Add sharing a list to staff client
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '23

09 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30953 Bug ID: 30953 Summary: Add sharing a list to staff client Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Bug 9032 added this OPAC feature. And I was quite sure that there was an intranet report too for it. But cant find it. So here it is.. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 32527] New: can`t use <<user>> variable in SLIPS
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '23

08 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32527 Bug ID: 32527 Summary: can`t use <<user>> variable in SLIPS Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: paliotti(a)mdp.edu.ar QA Contact: testopia(a)bugs.koha-community.org Hi: Making customized ISSUESLIP and ISSUEQSLIP, the library circulation staff ask me if it´s possible add the staff user to the slips. Thinking that <<user>> variable works fine in cataloguing frameworks, by example, I added it but did'nt work. Neither [% user %], [% loggedinusername %], [% loggedin_user_name %] and others. If <<today>> works, why <<user>> don't ? it's not a global var? Thks in advance Pablo -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3