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

[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 24 Jun '24

24 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

[Bug 27421] New: Porting tools/stage-marc-import.pl to BackgroundJob
by bugzilla-daemon＠bugs.koha-community.org 21 Jun '24

21 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27421 Bug ID: 27421 Summary: Porting tools/stage-marc-import.pl to BackgroundJob Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: domm(a)plix.at QA Contact: testopia(a)bugs.koha-community.org Hi! I recently started to convert tools/stage-marc-import.pl to use the new BackgroundJobs, because we're using the Plack version, which does not like the old forking implementation. While I've realized now that we can still use the old CGI script by running it directly via the frontend Apache, I'm not very happy with this workaround. So, here is my current first sort-of-working prototype: https://github.com/Koha-Community/Koha/compare/master...domm:MARCImporter Before I continue my work, I'd really appreciate some feedback if what I'm doing makes sense and matches your general plans. Obviously there is still a lot missing: * Proper feedback after starting the staging process (i.e. a link to the job) * Probably I will also need to check if the job has finished, and present a link to the next step (copy the staged records into the library) (which AFAIK will also need to be converted to BackgroundJobs) I also have a few questions: * Is it neccessary to get the job-size before starting it? If yes, then I assume I'll have to first parse the MARC file to get the job size, throwing the results away (and this might not work, because we want to do the parsing in the background in the first place). Or is there an easy way to get the number of records? * When I try to update job_size later, I get an exception (something like "job_size not tested") * Can I actually use BatchStageMarcRecords in BackgroundJob? * I see I can pass a batch size to BatchStageMarcRecords. But this will not result in more forking? This is "only" used to fire the progress callback? I'm also not sure if the bug tracker or the dev mailing list is the best place to discuss my questions? Anyway, looking forward to some feedback! Greetings, domm -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 136

[Bug 31719] New: Course name should enforce non-white-space character requirement
by bugzilla-daemon＠bugs.koha-community.org 20 Jun '24

20 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31719 Bug ID: 31719 Summary: Course name should enforce non-white-space character requirement Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org While a course name is required on a course reserve, if that field is populated with a space, Koha accepts it as having a name, but there's no further way to get back to that course or interact with it afterwards since the only link is via name. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 28981] New: Add a syspref for marking items as unavailable in Z3950Responder
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '24

18 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28981 Bug ID: 28981 Summary: Add a syspref for marking items as unavailable in Z3950Responder Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Proposal: 1 - Add a new system preference "Z39ResponderUnavailable" 2 - Similar to 'OpacHiddenItems' this will accept a list of column/value pairs 3 - Update Koha::Z3950Responder::Session::add_item_status to check the preference and mark item as unavailable 4 - Item status message will be pulled from Z3950_STATUS authorized value list -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 35254] New: Adding files to basket from a staged file uses wrong inputs for order information when not all records are selected
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '24

18 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35254 Bug ID: 35254 Summary: Adding files to basket from a staged file uses wrong inputs for order information when not all records are selected 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 32166 fixed the issue of items and inputs not matching up for item level details, however, the problem still exists for order level information To recreate: 1 - Find a vendor in acquisitions 2 - Create or find an open basket 3 - Add to basket form a new file 4 - Stage file and add to basket 5 - Select the second record in the list 6 - Enter price info 7 - Save (don't forget, you need to set item type in the second tab) 8 - The order has no price info! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 24161] New: Late orders improvements - keeping track of claims
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '24

18 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24161 Bug ID: 24161 Summary: Late orders improvements - keeping track of claims Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org * Allow multiple claim dates to be associated with an individual order line * Show multiple claim dates against an order line in the late orders page * Show multiple claim dates against an order line in the basket page -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 102