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

[Bug 32657] New: neworderempty.pl should use RDA tag 264 not tag 260
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '23

01 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32657 Bug ID: 32657 Summary: neworderempty.pl should use RDA tag 264 not tag 260 Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: dch(a)interleaf.ie QA Contact: testopia(a)bugs.koha-community.org When SysPref 'UseACQFrameworkForBiblioRecords' is set to Don't use the framework 'ACQ' for bibliographic records fields, then publication details you enter to neworderempty.pl are inserted into tag 260 on the bibliographic record, but they should be inserted to tag 264 instead. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 34156] New: C4::Acquisition::FillWithDefaultValues handles leader incorrectly
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '23

01 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34156 Bug ID: 34156 Summary: C4::Acquisition::FillWithDefaultValues handles leader incorrectly Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When adding to a basket from a new empty record, we call FillWithDefaultValues on the record from the form. In MARC::Record the leader is obtained via $record->leader But FillWithDefaultValues uses the tags form 'GetMarcStructure' where leader is 000 So when you add the record, we don't find a 000 and so add a field We end up with a record with the original leader, and a controlfield=000 with the default value. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 33144] New: Authority lookup in advanced editor overencodes HTML
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '23

01 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33144 Bug ID: 33144 Summary: Authority lookup in advanced editor overencodes HTML Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart+koha(a)gmail.com, m.de.rooy(a)rijksmuseum.nl Depends on: 26102 Bug 26102 prevented XSS via malicious authority records (which would have been fun to exploit), but it did it by creating an HTML entity-encoded string and then handing it to a function which expected to get text, not HTML. As a result, if you look up the authority record for Simon & Schuster Audio (Firm) from the advanced editor, you wind up putting Simon & Schuster Audio (Firm) in your bib record. Steps to reproduce: 1. Set EnableAdvancedCatalogingEditor to Enable 2. Edit any Topical Term authority record, and at the end of 150 subfield a add (without the newlines, just offsetting it for easy copying) & Stuff </script><script>alert('boo ❤')</script> 3. Cataloging - Advanced Editor 4. Hit return in the editor to get a new line, type 650 and press tab three times, then Ctrl+Shift+L 5. Search for the authority you edited, click Choose Expected result: The editor should show 650 _ 4 ‡aAbduction & Stuff </script><script>alert('boo ❤')</script>‡vDrama. since that's the text of the authority you selected Actual result: The editor shows 650 _ 4 ‡aAbduction & Stuff </script> <script>alert('boo ❤');</script>‡vDrama. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26102 [Bug 26102] Javascript injection in intranet search -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 29750] New: Reserves.pm should check patron category hold policies when finding a reserve for an item
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '23

30 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29750 Bug ID: 29750 Summary: Reserves.pm should check patron category hold policies when finding a reserve for an item Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 23172 introduced a check for patron categories hold policies when the holds queue maps items to pending reserves. This patchset will introduce a check for patron categories hold policies when finding a reserve for an item. This is useful when the holds queue has not been generated. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 32783] New: Add more mapping when creating eholding from biblio
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '23

30 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32783 Bug ID: 32783 Summary: Add more mapping when creating eholding from biblio Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal 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, pedro.amorim(a)ptfs-europe.com Depends on: 32030 There is a lot of FIXMEs here, we could do better and provide more mappings. my $publication_title = $biblio->title; my $print_identifier = $record->subfield( '020', 'a' ) || $record->subfield( '020', 'z' ) || $record->subfield( '022', 'a' ) || $record->subfield( '022', 'y' ); my $online_identifier = $print_identifier; my ( $date_first_issue_online, $date_last_issue_online ) = $fix_coverage->( $record->subfield( '866', 'a' ) ); my ( $num_first_vol_online, $num_last_vol_online ) = $fix_coverage->( $record->subfield( '863', 'a' ) ); my ( $num_first_issue_online, $num_last_issue_online ) = ( '', '' ); # FIXME ? my $title_url = $record->subfield( '856', 'u' ); my $first_author = $biblio->author; my $embargo_info = ''; # FIXME ? my $coverage_depth = $title_url ? 'fulltext' : 'print'; my $notes = $record->subfield( '852', 'z' ); my $publisher_name = $record->subfield( '260', 'b' ); my $publication_type = ''; # FIXME ? my $date_monograph_published_print = ''; # FIXME ? my $date_monograph_published_online = ''; # FIXME ? my $monograph_volume = ''; # FIXME ? my $monograph_edition = ''; # FIXME ? my $first_editor = ''; # FIXME ? my $parent_publication_title_id = ''; # FIXME ? my $preceeding_publication_title_id = ''; # FIXME ? my $access_type = ''; # FIXME ? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32030 [Bug 32030] Electronic resource management (ERM) -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 33685] New: We should display both backend and local status for ILL loan requests
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '23

30 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33685 Bug ID: 33685 Summary: We should display both backend and local status for ILL loan requests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com At least in the staff client, it would be clearer to display the combination of backend status and local status_alias in the status column for ill requests. At the moment, it's unclear to the end user (and the developer) what the actual state of the request is.. These really are distinct states and should be clearly displayed as such. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 27236] New: Package PO translation files separately to koha-common
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '23

29 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27236 Bug ID: 27236 Summary: Package PO translation files separately to koha-common Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com I propose that we package PO translation files separately as "koha-i18n". This is a common practice in Debian: https://packages.debian.org/search?searchon=names&keywords=i18n As Bernardo pointed out in Bug 24211, ~350MB of Koha's installed size is just PO files. That's roughly 75% of Koha's installed size. Combined with Bernardo's early ideas from Bug 24211, we could actually package the PO files as compressed files (down from ~350MB to ~50MB). Libraries that need translations could make sure their vendors install koha-i18n (this is another use-case for koha-core vs koha-full), and then they can just decompress the languages required. Technically, this might even make it easier to provide updated translations when the only change in Koha is the translation (and no code/template changes). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 31029] New: ILL request ID in ILL history table should link to the ILL request if permissions allow for it
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '23

29 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31029 Bug ID: 31029 Summary: ILL request ID in ILL history table should link to the ILL request if permissions allow for it Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Keywords: Academy Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de When a patron has placed ILL requests, they are shown in the patron account in a new tab "ILL request history". >From this table, there is no way to get to the ILL request in the ILL module. We should link the request ID if the user has permissions to access the module. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 32479] New: Replace sort: ~ by sort: 0 in mappings.yaml file
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '23

29 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32479 Bug ID: 32479 Summary: Replace sort: ~ by sort: 0 in mappings.yaml file Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com Bug 27316 removed the ability to have "Undef" as a sorting option. It is now either yes (1) or no (0). The default mappings.yaml file still contains a lot of sort: ~, which I assume is "Undef". I propose to change the ~ to 0 so that the mappings file is clean. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 32699] New: Patron browse 'forgets' how many entries to show
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '23

29 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32699 Bug ID: 32699 Summary: Patron browse 'forgets' how many entries to show Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: dch(a)interleaf.ie QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If you change the number of entries to show in member.pl, then select one entry to view, when you return to the list it reverts to just showing the default 20 entries. It should show the number of entries you had previously selected -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1