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

[Bug 33623] New: getAll not encoding URL params
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '23

15 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33623 Bug ID: 33623 Summary: getAll not encoding URL params Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: major Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com -- You are receiving this mail because: You are watching all bug changes.

1 22

[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 33672] New: Item group features shows when placing holds if EnableItemGroupHolds is disabled
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '23

15 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33672 Bug ID: 33672 Summary: Item group features shows when placing holds if EnableItemGroupHolds is disabled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 24857 If you don't want to allow item group holds, the option to do so should not show on the place hold forms in OPAC and staff interface when EnableItemGroupHolds is disabled. Currnetly the option always shows. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24857 [Bug 24857] Add ability to group items for records -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[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 33653] New: Search for late orders can show received order lines
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '23

15 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33653 Bug ID: 33653 Summary: Search for late orders can show received order lines Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org In some circumstances the list of late orders will show orders that have already been completed/fully received. As their is no indication in the list that they have been received, they might get accidentally claimed. Late orders should never include order lines that have been received. To test: * Create a basket * Create a normal order (not from a subscription, no standing order) * Leave estimated delivery date empty * Close the basket * Create a new invoice and receive the order line * Go to acq > late orders * Verify the order is not in the list * Set filter for 'To' date into the future, i.e. 01/01/2025 * Verify the order shows up now -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31