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

[Bug 31582] New: With UseACQFrameworkForBiblioRecords 942$c doesn't display the itemtype pull-down
by bugzilla-daemon＠bugs.koha-community.org 23 Apr '23

23 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31582 Bug ID: 31582 Summary: With UseACQFrameworkForBiblioRecords 942$c doesn't display the itemtype pull-down Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When using UseACQFrameworkForBiblioRecords, the itemtype pull down for 942$c doesn't show up correctly. To test: * Activate UseACQFrameworkForBiblioRecords in system preferences * Create an ACQ framework or edit the existing one, adding 942$c mapped to bibioitems.itemtype * Add a new order using the 'from a new empty record' option * Verify 942c shows, but as a freetext input field -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 28488] New: Javascript error in self-checkout (__ is not defined)
by bugzilla-daemon＠bugs.koha-community.org 23 Apr '23

23 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28488 Bug ID: 28488 Summary: Javascript error in self-checkout (__ is not defined) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org datatables_20.1200050.js:32 Uncaught ReferenceError: __ is not defined at datatables_20.1200050.js:32 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 32386] New: Record Matching rules not being created
by bugzilla-daemon＠bugs.koha-community.org 23 Apr '23

23 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32386 Bug ID: 32386 Summary: Record Matching rules not being created Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: manishalibtech(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 144379 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=144379&action=e… error 500 Creating new record matching rules is not working. Getting error 500 at attached. Even editing the sample record matching rules is not working. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 15660] Prevent sharing budgets
by bugzilla-daemon＠bugs.koha-community.org 23 Apr '23

23 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15660 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WORKSFORME Summary|prevent sharing budgets |Prevent sharing budgets Status|NEW |RESOLVED --- Comment #3 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- I think this actually already works. You need to make sure the users don't have budget_manage_all and then limit the funds to library (and optionally to fund and user). That will also affect visibility on the start page. I have tested it a few times and it works. Nicole's original report was from 2016, I think it might not have worked back then. Wondering if another level of permissions would be needed here - permission control in acq is already very granular, it might makes things more complicated? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 15428] Different timeout preference for OPAC and staff interface
by bugzilla-daemon＠bugs.koha-community.org 23 Apr '23

23 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15428 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on|32385 | Summary|Different timeout |Different timeout |preference for opac and |preference for OPAC and |intranet |staff interface --- Comment #7 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Marked bug 32385 as a dependency for this one. I think in order to have different timeouts, we need different sessions first. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32385 [Bug 32385] OPAC and staff (intranet) should not share the same session and cookie -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15428] Different timeout preference for opac and intranet
by bugzilla-daemon＠bugs.koha-community.org 23 Apr '23

23 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15428 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |32385 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32385 [Bug 32385] OPAC and staff (intranet) should not share the same session and cookie -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15399] MARCXML records larger than 1 MB (1048576 bytes) are not searchable.
by bugzilla-daemon＠bugs.koha-community.org 23 Apr '23

23 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15399 --- Comment #21 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to David Cook from comment #20) > (In reply to Katrin Fischer from comment #19) > > (In reply to David Cook from comment #18) > > > I was sure that I replied to this already... > > > > > > I changed zebra_max_record_size to 4096 in prod for one instance since there > > > were MARCXML records with large numbers of records, and it works fine. > > > > Could we add this to the wiki for Zebra troubleshooting? > > https://wiki.koha-community.org/wiki/ > Troubleshooting_Zebra#Records_with_lots_of_items_not_indexing Awesome, thanks David! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15348] Change/Edit estimated delivery date per order line
by bugzilla-daemon＠bugs.koha-community.org 23 Apr '23

23 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15348 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to master |Needs documenting --- Comment #135 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Should this be needs documenting? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15347] itemcallnumber syspref does not work when adding items through acquisitions
by bugzilla-daemon＠bugs.koha-community.org 23 Apr '23

23 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15347 --- Comment #10 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to Katrin Fischer from comment #7) > I can confirm that the itemcallnumber system preference doesn't work for > adding items from acquisition. > > To test: > - Make sure itemcallnumber preference is set to field and subfield, that > exists > in the records you want to use for testing. > - Verify that preference works in general in your installation: > - Add new item for an existing record with the field. > - Verify that the callnumber is filled with the value from the > bibliographic record as a suggestion. > - Set AcqCreateItem to 'on order' > - Create a new basket > - Add a order line to it > - Verify that the callnumber remains empty unlike in cataloging. > Set AcqCreateItem to 'on receive' > - Create a new basket > - Add a order line to it > - Close basket > - Receive shipment > - Verify that callnumber remains empty unlike in cataloging. > > If I enter a callnumber to the item in one of those steps, it's stored > correctly and visible in the catalog immediately after saving. > > I think it doesn't matter if it's from Z39.50 or from an existing records - > it never works. Can confirm this is still an issue in current master. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 15347] itemcallnumber syspref does not work when adding items through acquisitions
by bugzilla-daemon＠bugs.koha-community.org 23 Apr '23

23 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15347 --- Comment #9 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to Kate Fitz from comment #8) > We have recently experienced this issue when importing MARC records from an > outside vendor. After import, the Call Number is in the record, but does not > display on items on either the staff catalog or public catalog until the > record has been opened, saved, and closed. That's the correct behaviour. You imported with the callnumber in the record and it won't be added to the items automatically. Because you have set itemcallnumber system preference it will suggest the callnumber from the record when you edit an item with an empty callnumber field. Now when you save hte callnumber is actually added to the item. You might want to shift the callnumber into the items (952$o) before importing. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0