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

[Bug 32494] New: Potentially expensive API calls made for conditional template rendering
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '24

26 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32494 Bug ID: 32494 Summary: Potentially expensive API calls made for conditional template rendering Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: matt.blenkinsop(a)ptfs-europe.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 Bug 32474 introduces ajax based scrolling in v-selects to reduce expensive API calls. Within ERM there are components where an API call is made and then sections of template are conditionally rendered depending on whether the call returns any data. For example, LicensesList.vue requests a list of all licenses and then renders a div containing a table if "licences.length" is true. The table then makes the same API call again to fetch the data to populate the table. The initial API call is therefore not relevant to the table data and if there is a large number of licenses, this will be an expensive call to make simply to render the table before making the same call again. I would suggest that the initial API call needs to be paginated to return a small amount of data to pass the licenses.length conditional check. The change proposed in bug 32474 in fetch.js allows fetchLicenses to be called with a parameter to paginate to just one page like this: "fetchLicenses(1)". We will then only be fetching one page of 20 values to pass the check. N.B. in bug 32474 components with a v-select have already been paginated e.g. AgreementLicenses.vue - this bug is to patch the components that have not been modified already, such as LicensesList.vue -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 23940] New: Create SQL with mana in Reports
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '24

26 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23940 Bug ID: 23940 Summary: Create SQL with mana in Reports Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Mana-kb Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com >From the main page of the Reports Module (reports-home.pl), you can create a guided report or create a SQL report. From the guided_reports.pl page, you can create a guided report, sql report or SQL report from Mana. It would be very nice if the option to create a SQL report from Mana would be also an option on the reports-home.pl page. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 20780] New: EDI: Add support for 'AcqItemSetSubfieldsWhenRecieved'
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '24

26 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20780 Bug ID: 20780 Summary: EDI: Add support for 'AcqItemSetSubfieldsWhenRecieved' 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org EDI, as it stands, does not respect the AcqItemSetSubfieldsWhenRecieved system preference.. it should ;) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29

[Bug 22348] New: Koha::EDI has no tests
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '24

26 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22348 Bug ID: 22348 Summary: Koha::EDI has no tests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The utility functions in Koha::EDI are entirely untested and as such prone to regressions... we should write tests for them -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 32595] New: Price format cost in ILL requests table
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '24

25 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32595 Bug ID: 32595 Summary: Price format cost in ILL requests table 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: katrin.fischer(a)bsz-bw.de The table with all ILL requests on the start page of the ILL module shows the Cost as 4.00 indepent of the PriceFormat system preference. It needs to have price formatting applied. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 35938] New: Add lots of biblios to a list causes a URL too long error
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '24

25 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35938 Bug ID: 35938 Summary: Add lots of biblios to a list causes a URL too long error Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl /virtualshelves/addbybiblionumber.pl can easily exceed the maximum number of characters a URL is allowed to contain when submitting large numbers of biblionumbers. We should be able to significantly reduce this by simply reducing the parameter name from 'biblionumber' to 'bib' or 'b'.. or we could work on an alternative submission mechanism. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 24807] New: Add "year" type to improve sorting by publication date
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '24

25 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24807 Bug ID: 24807 Summary: Add "year" type to improve sorting by publication date Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: glasklas(a)gmail.com When sorting on date-of-publication (a year, field 008, positions 7-10), the current behavior when the field contains an invalid year (containing word characters like "uuuu" or just whitespace), these results appear first when sorting in descending order. Invalid values like these should really not be indexed at all. If so (having null values instead) they will always appear last when sorting, regardless of sort order. This fix adds a "year" search field type, that will reject any non-year values, resulting in a more user friendly sorting behavior. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 69

[Bug 30280] New: Koha does not currently support authority posts with common subject headings from different thesaurus
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '24

25 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30280 Bug ID: 30280 Summary: Koha does not currently support authority posts with common subject headings from different thesaurus Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: frank.hansen(a)ub.lu.se QA Contact: testopia(a)bugs.koha-community.org Consider this three following examples 650 _ 0 $a Feminism 650 _ 7 $a Feminism $2 sao 650 _ 7 $a Feminism $2 barn The first example above is the LCSH term. The two other sao (controlled Swedish subject heading system) and barn (Swedish children subject heading system). These three using basically the same TOPIC_TERM Feminism but they belongs to different thesaurus. According to https://www.loc.gov/marc/authority/ (Library of Congress), subject heading thesaurus/system is specified in 008/11 in the authority record. When other thesaurus/system is used, the value of 008/11 is "z" (Other) and the convention used is marked up in field 040$f. But Koha currently not seems to support the use of different thesaurus. The script link_bibs_to_authorites.pl will treat authority records with the same TOPIC_TERM from different thesaurus as duplicates and will not be able to link the subject heading to its corresponding authority record. We would like if Koha could let authority records from different thesaurus co-exist in Koha and "learn" Koha how to distinguish between them. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 80

[Bug 28504] New: Hold pickup library match (hold_fulfillment_policy) not enforced when filling holds if set to "patron's group" / 'patrongroup'
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '24

24 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28504 Bug ID: 28504 Summary: Hold pickup library match (hold_fulfillment_policy) not enforced when filling holds if set to "patron's group" / 'patrongroup' 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 The case is simply not covered in the code In C4::Reserves::CheckReserves: 908 my $hold_fulfillment_policy = $branchitemrule->{hold_fulfillment_policy}; 909 next if ( ($hold_fulfillment_policy eq 'holdgroup') && (!$library->validate_hold_sibling({branchcode => $res->{branchcode}})) ); 910 next if ( ($hold_fulfillment_policy eq 'homebranch') && ($res->{branchcode} ne $item->$hold_fulfillment_policy) ); 911 next if ( ($hold_fulfillment_policy eq 'holdingbranch') && ($res->{branchcode} ne $item->$hold_fulfillment_policy) ); 912 next unless $item->can_be_transferred( { to => Koha::Libraries->find( $res->{branchcode} ) } ); -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 25836] New: MARC fields not able to be reordered in basic editor
by bugzilla-daemon＠bugs.koha-community.org 21 Jun '24

21 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25836 Bug ID: 25836 Summary: MARC fields not able to be reordered in basic editor Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl >From bug 7882, it seems that MARC fields should be able to be reordered, however it does not appear to be working. For instance, if I have a record with 3 650 fields and 2 651 fields, I cannot move the 651 fields above the 650 fields. I can rearrange the 650 fields amongst themselves, but that's it. The move icon/hamburger shows on all fields, which leads one to think that all fields can be reordered, when this is clearly not the case. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4