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

[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 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 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