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

[Bug 33445] New: Regression - Replacing authority via Z39.50 will not search for anything but the value from the existing authority
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '23

15 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33445 Bug ID: 33445 Summary: Regression - Replacing authority via Z39.50 will not search for anything but the value from the existing authority Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P3 Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl, martin.renvoize(a)ptfs-europe.com, thibaud.guillot(a)biblibre.com Depends on: 29173 There are two steps to cataloguing/z3950_auth_search.pl - load it without op=do_search and it inserts the value from any params that match a form field name into the form and displays the form, or load it with op=do_search, and it searches for the values from params that match form field names and displays the results. Bug 29173 implemented prefilling the form for the case where you are coming from an authority detail view rather than an authority editor by looking up the existing authority record, and inserting values from it into the variables holding the input params. It does that in both the first step (overwriting changes you've made in the editor) and also in the do_search step, overwriting what you put in the search form with the data from the existing stored authority record. Steps to reproduce: 1. Find and edit any existing corporate name, personal name, subject or uniform title authority which will have results from the Z39.50 server you're going to search. For a usable ktd data and Library of Congress Names server example, use Smith, Bessie, 1894-1937. 2. In the editor, note what's in the main entry field's subfield a (Smith, Bessie) 3. Replace subfield a's contents with something different, like your own name 4. Click "Replace record via Z39.50/SRU search" 5. Note that rather than what you put in, the form field is filled with what the record originally had 6. Replace it with your name again, this time in the search form, select the server to search, and click Search 7. Note that the results are for what was originally in the record, not what you put in the form There are two cases where that makes replace via Z39.50 unusable: when you need something different than the original, like after a change in heading or when your existing record passed through an encoding error and you need to turn Gâomez, Hâector Carlos into Gómez, Héctor Carlos, and cases where just the subfield a is not enough to distinguish, like searching for Smith, John when you want Smith, John, Jr., -1853 who appears on page 39 of the results. Oh, and any name for UNIMARC, since subfield a is only the surname. A very good start to fixing this would be to revert bug 29173 from 22.11, 22.05, and 21.11, since this feature is now broken back to oldoldstable. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29173 [Bug 29173] Button "replace authority record via Z39/50/SRU" doesn't pre-fill -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 45

[Bug 25379] New: HTML tags visible in Returns.pl
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '23

15 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25379 Bug ID: 25379 Summary: HTML tags visible in Returns.pl Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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 Created attachment 104375 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=104375&action=e… on returns.pl page With the introduction of this bug: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23409. ( Show circulation note and OPAC note with line feeds ), the ability to add HTML was included. However, when a patron note with HTML is seen during circulation (check-in)- the HTML tags are visible. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 32917] New: Change patron.firstname and patron.surname in password change sample notice
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '23

15 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32917 Bug ID: 32917 Summary: Change patron.firstname and patron.surname in password change sample notice Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Unless I am mistaken, I think the password change sample notice/notice should contain [% borrower.firstname %] and [% borrower.surname %] rather than [% patron.firstname %] and [% patron.surname %] from installer/data/mysql/en/mandatory/sample_notices.yml - module: members code: PASSWORD_CHANGE branchcode: "" name: "Notification of password change" is_html: 1 title: "Library account password change notification for [% patron.firstname %] [% patron.surname %]" message_transport_type: email lang: default content: - "Dear [% patron.firstname %] [% patron.surname %]," - "" - "We want to notify you that your password has been changed. If you did not change it yourself (or requested that change), please contact library staff." - "" - "Your library." -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 33253] New: 2FA - Form not excluded from autofill
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '23

15 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33253 Bug ID: 33253 Summary: 2FA - Form not excluded from autofill Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: tech.sam(a)salinapublic.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I've been testing the 2FA module in our install, working great so far, but I noticed the authentication form field is not marked to be excluded from auto completion. Because of this, after several weeks of use, every time I click on the field, I see a list of all prior authentication codes used. This might be possible to be used in an attack to reverse-engineer the secret key using past codes and when they were entered. Even if that isn't the case, it means browsers are saving loads of unnecessary data that is one-time use. Information on how to disable auto completion in form fields can be found here: https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Tu… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 22375] New: Due dates should be formatted consistantly
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '23

15 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22375 Bug ID: 22375 Summary: Due dates should be formatted consistantly Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Now we have some due dates formatted as datetime, and some shows time part only when it is hourly loan (as_due_date = 1 param of KohaDates filter is used) This should be same for all due dates across whole system, as_due_date should be used everywhere -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 33622] New: Notice content does not show on default tab if TranslateNotices enabled
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '23

15 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33622 Bug ID: 33622 Summary: Notice content does not show on default tab if TranslateNotices enabled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org This was first noticed in 22.11 but can confirm it happens in main too. To reproduce: 1. Restart services 2. Go to Koha Administration -> Global system preferences and enable the TranslateNotices system preference 3. Go to Tools -> Notices & slips 4. Go to edit any notice i.e. ACCOUNTS_SUMMARY 5. Expand the Email section of the Default tab. Confirm there is no content in the notice --> BUG 6. Click on the next language tab, then expand the Email section. It is probably empty if you've only just enabled TranslateNotices and have not set up specific notices for your installed languages so this is fine. 7. Go back to the Default tab and expand the Email section. Confirm the content now shows for the notice It should show upon first expand of Email section. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 33569] New: Order by relevance many not be visible
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '23

15 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33569 Bug ID: 33569 Summary: Order by relevance many not be visible Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org When ordering catalog search by relevance from advanced search, this is not visible in sort order combobox in staff interface. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 33613] New: Claim return doesn't charge when "Ask if a lost fee should be charged" is selected and marked to charge
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '23

15 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33613 Bug ID: 33613 Summary: Claim return doesn't charge when "Ask if a lost fee should be charged" is selected and marked to charge Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1. Have an item with a replacement cost checked out to a patron 2. Set the ClaimReturnedChargeFee sys pref to "Ask if a lost fee should be charged" 3. Make a claim and check the box for charging. 4. Claim happens but no charge occurs. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 33412] New: Problem importing records (bug 15869 follow-up) wrong use of assignment
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '23

15 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33412 Bug ID: 33412 Summary: Problem importing records (bug 15869 follow-up) wrong use of assignment Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org $overlay_framework = undef if $overlay_framework = '_USE_ORIG'; should clearly be: $overlay_framework = undef if $overlay_framework eq '_USE_ORIG'; -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 33611] New: Holds being placed in the future if DefaultHoldExpirationdate is set
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '23

15 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33611 Bug ID: 33611 Summary: Holds being placed in the future if DefaultHoldExpirationdate is set Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 30718 altered C4::Reserves::AddReserve to use either the date passed in, or a dt_from_string object When storing the hold, we call Koha::Hold::_set_default_expirationdate This assumed reservedate was always a string, and used it to create a dt object, and add days for the expiration. Now that reservedate is already a dt object, this means we add the days to the object, so the reservedate is set into the future, as well as the expiration To recreate 1 - Set DefaultHoldExpiration to Set 2 - Set DefaultHoldExpirationPeriod to 365 3 - Set DefaultHoldExpirationunitOfTimeToDays 4 - Place a hold 5 - Note reserve date is 1 year in the future, same as expiration -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22