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

[Bug 31912] New: When enforcing 2FA we should alert the user
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '24

15 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31912 Bug ID: 31912 Summary: When enforcing 2FA we should alert the user Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org After bug 30588 the staff can set 2FA as forced - when this set we should notify the user of this setting both on: 1 - Their 2FA setup page in the staff interface/user account 2 - The login screen when sending them to setup 2FA -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 35601] New: Cannot go into Cataloging->Export when 2FA is enabled
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '24

15 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35601 Bug ID: 35601 Summary: Cannot go into Cataloging->Export when 2FA is enabled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: schodkowy.omegi-0r(a)icloud.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com After enabling 2FA authentication for a user, they cannot go into /cgi-bin/koha/tools/export.pl anymore (Cataloging -> Export catalog). It prompts them to log-in again instantly, but putting in the email+password, and then 2FA code, it puts you back again into email+password prompt in an infinite loop, without any error. If I then go back to the main page, if I was at the 2FA stage, I have to enter my 2FA code again to see the staff interface. If I was at the email+password stage, I can then proceed without logging in again. This effectively makes catalog exporting page inaccessible. I find the whole requirement of logging in again to export catalog pretty annoying on that note, which we do fairly regularly. Is there by any chance some way to disable that (which would probably mitigate this bug too)? I couldn't find anything. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 22581] New: Include the Verovio library to show musical incipits
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '24

15 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22581 Bug ID: 22581 Summary: Include the Verovio library to show musical incipits Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: verolencinas(a)yahoo.com.ar QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Marc tag 031 includes the musical incipit (first compases of a melody) as code. Musical catalogs such as MUSCAT (http://muscat-project.org) use this information to display the incipit in musical code and to allow to search for incipits. Since it is possible to export MUSCAT data and import it in Koha, for music libraries it would be very helpful to display the incipit in the OPAC. MUSCAT uses an external libray, Verovio (https://www.verovio.org/) to do this. If the tag 031 is present, Verovio should be used to show the incipit in musical notation. -- You are receiving this mail because: You are watching all bug changes.

1 44

[Bug 8425] Autobarcode generates duplicate barcodes with AcqCreateItems = on order
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '24

15 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8425 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #20 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- get_barcode my $scr = qq~ let elt = \$("#"+id); let homebranch = elt.parents('fieldset.rows:first') .find('input[name="kohafield"][value="items.homebranch"]') .siblings("select") .val(); if(typeof offset == 'undefined'){ var offset = 0; } if ( \$(elt).val() == '' ) { \$(elt).val(homebranch + ($nextnum + offset)); } ~; TOGETHER WITH +function set_barcode(id, force, offset=0) { => Default is zero. Why are we checking the type then later? Seems useless? +if(typeof autobarcodetype == 'undefined') { + var autobarcodetype = "$autoBarcodeType"; + var attempt = -1; +} => This does not look good either? Why are we conditionally declaring vars here? Why are we fixing this only for a specific autobarcode type? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8425] Autobarcode generates duplicate barcodes with AcqCreateItems = on order
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '24

15 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8425 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy(a)rijksmuseum.nl --- Comment #19 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Biblibre Sandboxes from comment #18) > In 3.8.0, a software error comes up which prevent any item creation, I > believe, but master (3.9.x) doesn't throw any warnings or errors. > > Yes.. This tries and solve a bug from 3.8.0 /o/ Am I really reading this in 2024 ?? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 31354] New: Clarify options for 'Change messaging preferences to default for this category?' popup
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '24

15 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31354 Bug ID: 31354 Summary: Clarify options for 'Change messaging preferences to default for this category?' popup Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The options for the 'Change messaging preferences to default for this category?' popup that appears when editing a patron's category are Cancel and OK, but I think No instead of Cancel and Yes instead of OK would be clearer. A library could reasonably think that Cancel refers to cancelling the change in category, and No would make it clearer that refers to the preferences only. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 37573] New: Bad escaping in OPACSearchForTitleIn breaks JS in <script> tags
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '24

15 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37573 Bug ID: 37573 Summary: Bad escaping in OPACSearchForTitleIn breaks JS in <script> tags Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: schodkowy.omegi-0r(a)icloud.com QA Contact: testopia(a)bugs.koha-community.org Suppose as the value of OPACSearchForTitleIn preference, you provide something like: ``` [...] <a href="https://openlibrary.org/search?author=({AUTHOR})&title=({TITLE})" target="_blank">Open Library (openlibrary.org)</a> <script> function test() { console.log("test!"); } test(); </script> ``` you will actually end up with: ``` <script> function test() test(); </script> ``` It seems that whatever parses the template arguments within {...} does so without consideration about possible other use of these brackets. What should actually happen, is that what's inside of brackets should only be replaced if it's a valid param such as {AUTHOR} etc, otherwise the argument should probably be ignored (or at the very least keep current behavior only if it passes some regex like \{[A-Z_]+\}... It actually looks like the removal was explicit: https://github.com/Koha-Community/Koha/blob/8ff9e665e4d275ac601ee5165ab4233… Meaning that to keep this behavior, it'd be best to adjust the regex to be more conservative. Either that, or just junk that line altogether... -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 36442] New: Fix typo in edifact list
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '24

15 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36442 Bug ID: 36442 Summary: Fix typo in edifact list Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: glasklas(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org This patch fixes a typo in koha-tmpl/intranet-tmpl/prog/en/modules/acqui/edifactmsgs.tt for the basketno get parameter resulting in a broken link. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 36981] New: Check for subscription length value
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '24

15 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36981 Bug ID: 36981 Summary: Check for subscription length value Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: pierre.genty(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org When editing serial subscription, it is possible to set amount such as 999999999 in "Subscription length" field. If no end date is set this could cause an infinite loop. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 35905] New: Missing permission check for "record batch delete" from reports
by bugzilla-daemon＠bugs.koha-community.org 14 Nov '24

14 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35905 Bug ID: 35905 Summary: Missing permission check for "record batch delete" from reports Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org If the user has reports permission, but is missing the "batch record delete" permission, it will still show up as link on top of the reports table. To test: * Create a report like: select biblionumber from biblio limit 10 * Run the report * Verify you have the batch delete option on top of the table * Re-run with a user that is not a super librarian or has the permission * Verify the link still shows, but leads to a 'permission denied' when clicked -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28