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

[Bug 29252] New: Document the uses of 942c (MARC21)
by bugzilla-daemon＠bugs.koha-community.org 12 May '23

12 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29252 Bug ID: 29252 Summary: Document the uses of 942c (MARC21) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org There was a discussion on the mailing list about the reasons of 942c. See this thread : https://lists.katipo.co.nz/pipermail/koha/2021-October/056838.html >Good afternoon, > >I recall reading (in the Koha manual?) the explanation for why it is >advantageous to define Koha item type in the bib 942 field. I believe it >has to do with exporting records, or the scope of records that is included >when doing some type of report? I'm trying to locate that information >again, but can't find it for the life of me. > >Does this seem familiar to anyone? Thanks. > > >Tasha Bales ------------ >I can't find the information right now, though I know I've seen it somewhere. >My understanding is when importing a MARC record, 942$c is treated as the >item type in the bibliographic record, and 952$y is the item type >for the item record (assuming a 952 holding field was present). > >I have also observed that when you create a new item record from an >existing bib record, 942$c gets copied into the new item's type. So >it's helpful to make sure that the item type in the bib record was set >correctly when it was created (or imported). > >This wiki page talks about 952, but not 942: > >https://wiki.koha-community.org/wiki/Holdings_data_fields_(9xx) > >I'm sure someone more knowledgeable can correct this if I'm wrong. -------------------- >942$c - defines the type of material the bibliographic record represents, >sort of like it's GMD (general material description). Has no bearing on >circulation of material. Stored as marcxml in biblio_metadata. > >952$y - defines the item-level item, and is used mandatorily for Koha's >circulation rules which work as a permutation of (a) branchcodes (b) patron >categories and (c) item-level item types. Stored as itype column in items >table. > >Hope this helps >Indranil --------------------- >952$y is mandatory for circulation IF item-level_itypes is set to "specific >item". Otherwise, 942$c is used as the item type for circulation. > >Another thing that I have observed about 942$c is that it is indexed for the >search in the same way as 952$y. So if you have records without items (for >journal articles, websites or ebooks for example), these will still be >searchable through the item type filter. > >Also, if 942$c and 952$y are not the same in one record (for example, 942$c is >Book and 952$y is Reference), they will show in the results of a search for >either type. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 22839] New: Manual screenshots and description in Acquisition (Funds) are outdated
by bugzilla-daemon＠bugs.koha-community.org 12 May '23

12 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22839 Bug ID: 22839 Summary: Manual screenshots and description in Acquisition (Funds) are outdated Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: christian.stelzenmueller(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The screenshots and the text ("To see all active funds you can click the checkbox next to ‘Show active and inactive’ above the funds table.") in the Manual for the funds in the section Acquisitions are outdated. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 32988] New: Cannot clear guarantor with clear link
by bugzilla-daemon＠bugs.koha-community.org 11 May '23

11 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32988 Bug ID: 32988 Summary: Cannot clear guarantor with clear link Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When trying to clear a manually entered guarantor, the clear link does nothing. You have to clear the text boxes manually. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 30995] New: Bug 29504 - Confirm item parts requires force_checkout permission (batch checkout)
by bugzilla-daemon＠bugs.koha-community.org 11 May '23

11 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30995 Bug ID: 30995 Summary: Bug 29504 - Confirm item parts requires force_checkout permission (batch checkout) Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com Depends on: 29504 We still see the issue or a similar one as from bug 29504 on the batch checkout of items with $3 and CircConfirmItemParts: Test plan: 1. Set a staff member with circ permissions, but not FORCE_CHECKOUT 2. Turn on: CircConfirmItemParts, BatchCheckouts, BatchCheckoutsValidCategories (all) 3. Log in as staff member in step 1 4. Attempt to checkout an item with a 952$3 from the batch checkout tab 5. The button to process/confirm the checkouts is missing. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29504 [Bug 29504] Confirm item parts requires force_checkout permission -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 29431] New: Hold queue does not consider expiration date
by bugzilla-daemon＠bugs.koha-community.org 11 May '23

11 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29431 Bug ID: 29431 Summary: Hold queue does not consider expiration date Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The holds queue does not take a hold expiration date into consideration. If a hold has an expiration date, the title will show on the queue as needed to be pulled, and when staff check it in, the hold is expired. For libraries that do not auto expire waiting holds, this is a problem. If a hold has an expiration date prior to the current date, it should not show as needing to be pulled, or have some sort of indicator the expiration date of the hold is passed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 32929] New: ERM - 'Submit' button untranslatable
by bugzilla-daemon＠bugs.koha-community.org 11 May '23

11 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32929 Bug ID: 32929 Summary: ERM - 'Submit' button untranslatable Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Hopefully, this is a "me" problem, but for some reason, I can't get the "Submit" button in the ERM module to translate. To get to the button: 1. Enable the ERMModule system preference 2. Go to E-resource management 3. Click "Agreements" 4. Click "New agreement" --> "Submit" button is at the bottom of the form I found this string in the xx-XX-messages-js.po file (example in fr-CA, but I also tried in es-ES and de-DE) #: koha-tmpl/intranet-tmpl/prog/js/vue/dist/main.js:2 msgid "Submit" msgstr "Valider" I did ./translate install xx-XX but the button stays in English -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 33118] New: Bug 30472 provoke a DBI Exception when upgrading from 22.05.x to 22.11.02-1
by bugzilla-daemon＠bugs.koha-community.org 11 May '23

11 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33118 Bug ID: 33118 Summary: Bug 30472 provoke a DBI Exception when upgrading from 22.05.x to 22.11.02-1 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: pablo.bianchi(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Rising the comment 8 from bug 30472 to a new bug: Upgrading to 22.11.02-1 from an updated 22.05 on a Debian 11 crash with this error: Upgrade to 22.06.00.048 [18:33:27]: Bug 30472 - borrower_relationships.guarantor_id NOT NULL ERROR - {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: Cannot change column 'guarantor_id': used in a foreign key constraint 'r_guarantor' at /usr/share/koha/lib/C4/Installer.pm line 739 Maybe is the same issue as on bug 32399?. One of the people who sent me a PM suggest a workaround: changing the DEFAULT to NOT on "`guarantor_id` int DEFAULT NULL,". -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 32745] New: Background jobs view breaks when there are jobs with context IS NULL
by bugzilla-daemon＠bugs.koha-community.org 11 May '23

11 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32745 Bug ID: 32745 Summary: Background jobs view breaks when there are jobs with context IS NULL Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration 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 In 22.11.01 the background jobs view breaks, when there are entries with context = NULL in the database. In our case these are old entries for "batch_biblio_record_modification" from 2021. Newer entries seem to always have context set. Maybe an update issue with old data? * Manipulate database * Go to Administration > Manage jobs * Uncheck both checkboxes on top of the list if necessary -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 33250] New: DELETE /biblios/:biblio_id fails when ES is enabled
by bugzilla-daemon＠bugs.koha-community.org 11 May '23

11 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33250 Bug ID: 33250 Summary: DELETE /biblios/:biblio_id fails when ES is enabled Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com Not sure what made this fail, but here you go. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 33279] New: OAI-PMH should not die on record errors
by bugzilla-daemon＠bugs.koha-community.org 11 May '23

11 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33279 Bug ID: 33279 Summary: OAI-PMH should not die on record errors Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently if the OAI listRecords command hits a bad record the script dies and there is no output. We should wrap the code in an eval or try and handle the error gracefully, allowing the rest of the catalogue to be harvested and reporting the problem in a way it can be addressed -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2