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

[Bug 34030] New: Print slips in a batch from the preservation module
by bugzilla-daemon＠bugs.koha-community.org 08 May '24

08 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34030 Bug ID: 34030 Summary: Print slips in a batch from the preservation module Change sponsored?: Sponsored Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Tools Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 33547 Bug 33547 add a 'print slip' button to print the info for a given item, but it would be great to have a 'print slips' action button that could be clicked after we have selected a bunch of items and that would print all slips on the same document. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33547 [Bug 33547] Print slips from the preservation module -- You are receiving this mail because: You are watching all bug changes.

1 34

[Bug 25324] New: After editing an authority record with CatalogModuleRelink on, relinking appears to happen before the edited record is saved
by bugzilla-daemon＠bugs.koha-community.org 08 May '24

08 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25324 Bug ID: 25324 Summary: After editing an authority record with CatalogModuleRelink on, relinking appears to happen before the edited record is saved Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org The actual behavior these contrived steps imitate is using AutoCreateAuthorities and CatalogModuleRelink, using LinkerModule: First Match so that in case of duplicate authorities the linker will choose the first, oldest, lowest authid, and then buying one book by an author before he dies, cataloged with Name, Birthyear-, and then buying another after he dies, cataloged with Name, Birthyear-Deathyear. 1. Set AutoCreateAuthorities, BiblioAddsAuthorities, CatalogModuleRelink, and LinkerModule: First Match 2. Create a personal name authority record with 100 1# $aBrzezinski, Zbigniew,$d1928- (imitating one you imported before 2017) 3. In any existing bib record, add a 700 linked to that authority record, just so it has a linked bib 3. Cataloging, new from Z39.50, search for Brzezinski, Zbigniew as author, import and save any record with the 100 field having his $d as 1928-2017. 4. Since your report of newly created authority records shows Brzezinski, Zbigniew, 1928-2017 when you know you already owned something he wrote, go to Authorities and search for Brzezinski. You need to update your previously imported record (well, the fake of one you created), so Edit the one without a 2017, Replace record via Z39.50, find the 1928-2017 record and import and save it. 5. Search again for Brzezinski. Expected results: Because you created the one that was originally 1928- first, before the one autocreated as 1928-2017 from your imported bib record, and you set First Match as your LinkerModule, you should expect that when you edit the first record in a way that causes the two records to become duplicates, that relinking would link both bib records to the first match. Actual results: Both bib records are linked to the second match, the autocreated one, rather than to the original, looking very much like the bib record without -2017 was updated and both bib records were relinked before the authority record you turned into a match actually was a match. As a result, rather than just being able to delete a now-unused autocreated record, you have to merge it to your newly edited record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 10734] Add Publication Date Facet in Searching
by bugzilla-daemon＠bugs.koha-community.org 07 May '24

07 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10734 Laura Escamilla <Laura.escamilla(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Laura.escamilla@bywatersolu | |tions.com --- Comment #15 from Laura Escamilla <Laura.escamilla(a)bywatersolutions.com> --- This would be a great feature to have! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36107] New: Port default DUEDGST and PREDUEDGST notices to Template Toolkit
by bugzilla-daemon＠bugs.koha-community.org 07 May '24

07 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36107 Bug ID: 36107 Summary: Port default DUEDGST and PREDUEDGST notices to Template Toolkit Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: roadmap_24_05 Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Blocks: 15278 The following notices need to be updated to use Template Toolkit syntax: DUEDGST (email) DUEDGST (sms) PREDUEDGST (email) PREDUEDGST (sms) These will be a bit trickier, as they make use of <<items.content>>. The default information in <<items.content>> is the due date, title, author, and barcode of the item. Since this bug is limited to changing the default notice text, and won't affect existing installations, we could be okay to simply replicate that information with Template Toolkit variables for now. We will need to decide what to do about <<items.content>> if/when we deprecate hungry alligator syntax in the long run, though. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 [Bug 15278] [Omnibus] Port default slips and notices from bespoke syntax to Template Toolkit -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 36776] New: Clarify description of BatchCheckouts* system preferences.
by bugzilla-daemon＠bugs.koha-community.org 07 May '24

07 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36776 Bug ID: 36776 Summary: Clarify description of BatchCheckouts* system preferences. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, pedro.amorim(a)ptfs-europe.com These are the system preferences in question: BatchCheckouts : General ON/OFF switch. BatchCheckoutsValidCategories : Patron categories allowed to checkout in a batch. We should make clear in their description: * that they apply to circulation in the staff interface * that the patron categories are the ones you can batch checkout to as a staff user, not the patron categories allowed to perform batch checkouts We could also consider REMOVING BatchCheckouts as "not having set any patron categories" also deactivates the feature effectively. (adding Pedro so he sees that suggestion ;D ) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 36504] New: Run report should have an option to only send the attachment
by bugzilla-daemon＠bugs.koha-community.org 06 May '24

06 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36504 Bug ID: 36504 Summary: Run report should have an option to only send the attachment Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Currently, if runreport sends results via email, they are included in the body when also supplied as an attachment. Some libraries would like to receive only the attachment, to make the email less cluttered for large reports. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 36765] New: TestBuilder should explode if FK broken
by bugzilla-daemon＠bugs.koha-community.org 06 May '24

06 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36765 Bug ID: 36765 Summary: TestBuilder should explode if FK broken Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Right now, it only warns and continues. While this might mean 'there already exists a resource with the value we need for the test', this is really hiding a design issue with the tests. For example ```perl my $library = $builde->build_object( { class => 'Koha::Libraries, value => { branchcode => 'ILL', pickup_location => 1 } } ); ``` might fail because 'ILL' already exists, but if the DB entry doesn't contain the other fixed condition (pickup_location=1) then the tests could fail weirdly, and tracking it would be harder (i.e. you read the code, see you are setting pickup_location=1, but it fails because it is not). I propose we make it explode loudly instead. And fix the poorly written tests that explode because of it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 8838] Digest option for HOLD notice
by bugzilla-daemon＠bugs.koha-community.org 06 May '24

06 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8838 Jonathan Druart <jonathan.druart(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |36790 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36790 [Bug 36790] 230600052.pl is failing -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36784] New: No translation is required
by bugzilla-daemon＠bugs.koha-community.org 06 May '24

06 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36784 Bug ID: 36784 Summary: No translation is required Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: translate.koha-community.org Assignee: koha-bugs(a)lists.koha-community.org Reporter: Igor.A.Sychev(a)mail.ru QA Contact: testopia(a)bugs.koha-community.org %s %s %s %s [%% # [ WRAPPER tab_item tabname= "tab_name_1" bt_active= 1 ] %1$s: END %2$s: # BOOTSTRAP TAB WRAPPER USAGE %3$s: # [ WRAPPER tabs id= "tabs_container_id" ] %4$s: # [ WRAPPER tabs_nav ] -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 36783] New: No translation is required
by bugzilla-daemon＠bugs.koha-community.org 06 May '24

06 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36783 Bug ID: 36783 Summary: No translation is required Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: translate.koha-community.org Assignee: koha-bugs(a)lists.koha-community.org Reporter: Igor.A.Sychev(a)mail.ru QA Contact: testopia(a)bugs.koha-community.org [200a][, 200b][ 200d][ ; 200c][ (200f)] installer/data/mysql/en/marcflavour/unimarc/mandatory/authorities_normal_unimarc.yml:auth_types:1:row:2 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0