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

[Bug 3007] Remove untranslated unimarc_field_700-4 value builder
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '23

08 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3007 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alex.arnaud(a)biblibre.com, | |gladys.cathelain(a)biblibre.c | |om Assignee|koha-bugs(a)lists.koha-commun |katrin.fischer(a)bsz-bw.de |ity.org | Summary|Translate UNIMARC value |Remove untranslated |builders macles and |unimarc_field_700-4 value |unimarc_field_700-4 into |builder |English for translations | --- Comment #12 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Maybe making a risky suggestion here: but after I tried to translate the value builder and fount it not working... and an authorised value list used instead in the sample frameworks. I wonder: maybe we should remove it? -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 3007] Translate UNIMARC value builders macles and unimarc_field_700-4 into English for translations
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '23

08 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3007 --- Comment #11 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Created attachment 156700 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=156700&action=e… Bug 3007: Remove unimarc_field_700-4.pl value builder I tried translating it, found it not working and replaced by the annif authorised value list with relator terms/codes. To test: * Make sure the unimarc_field_700-4.pl is no longer listed in frameworks. * Make sure it's not used in the standard frameworks. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. You are the QA Contact for the bug.

1 0

[Bug 3007] Translate UNIMARC value builders macles and unimarc_field_700-4 into English for translations
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '23

08 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3007 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff Patch complexity|--- |Trivial patch -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 13870] Add warnings about subscriptions and orders when deleting items
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '23

07 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13870 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=35005 Summary|Add subscription and order |Add warnings about |count to new batch record |subscriptions and orders |deletion tool |when deleting items --- Comment #6 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hi Thibaud, I was excited to see this, but it turned out a little bit different to what I had expected: 1) The bug was filed for the 'batch record deletion tool'. Your patch deals with deleting single items. This can be fixed rather easily by changing the bug description and re-filing (see bug 35005) 2) For orders, I think we need to make some difference between an order that has been completed and one that is still pending. Deleting an item that is linked to a pending order would get us in trouble. Throwing out an old item purchased long ago not. Concerning order status would be: new, ordered, partial OK to delete: cancelled, complete 4) This line appears unrelated to the intention of the patch: + $i->{nomod} = 1 unless $patron->can_edit_items_from($item->homebranch); 5) The warnings messages you created are untranslatable, they need to be moved into the templates: cataloguing/additem.pl + if ($i_order) { + $warning_messages{$i->{itemnumber}} = sprintf('There is an order (ordernumber %s) on this item', $i_order->{ordernumber} ); + } + if ($i_serialid) { + $warning_messages{$i->{itemnumber}} = 'A subscription is linked to this item' 6) The subscription count on item batch modification doesn't seem to work right. I added a subscription and created an item on receiving an issue, so it's linked to the subscription. But it still said "None" on the batch mod page. 7) The order count on item batch modification doesn't appear to work either. I added an order with 'create items on order' and that item to the batch edit - The column remained at "None". 8) The notes work OK on the normal item editing form. I like the approach with the little warning sign. 9) QA tools are failing for a missing filter and tidiness. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9567] Favorite reports per user
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '23

07 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9567 --- Comment #6 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- (In reply to paxed from comment #3) > I see couple "easy" ways of doing this, without needing database changes: 1) > All in the client side, with cookies and javascript, or 2) Using a borrower > attribute to store the favorite report IDs I would not be in favor of anything that wouldn't follow you. Staff bounce around on different computers. This would be a difficult way to manage favorites. A table for tracking pages/tables/and borrower ids would be ideal. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9567] Favorite reports per user
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '23

07 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9567 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cbrannon(a)cdalibrary.org --- Comment #5 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- *** Bug 34925 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8577] build_holds_queue.pl needs command-line options for help, verbosity, and summary
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '23

07 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8577 --- Comment #3 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- So quiet would be used to suppress the warning, while the holds queue is only rebuilt for instances with RelTimeHoldsQueue off? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 27187] New: Cannot delete/update local cover image with LocalCoverImages off
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '23

06 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27187 Bug ID: 27187 Summary: Cannot delete/update local cover image with LocalCoverImages off Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When the LocalCoverImages syspref is set to "Don't display," Koha hides the image itself as well as the Images tab on the bib details page. However, if a library has OPACLocalCoverImages on, they'll likely want to access that Images tab to delete or change the images they're displaying on the OPAC. Could we hide the tab only if *both* sysprefs are off? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 8179] Receiving multiple order lines at once
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '23

06 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8179 Slava Shishkin <slavashishkin(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |35004 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35004 [Bug 35004] Error about no quantity set on acquisitions order receive confirmation. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33864] New: Modal broken when "AcqCreateItem" set to "cataloguing"
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '23

06 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 Bug ID: 33864 Summary: Modal broken when "AcqCreateItem" set to "cataloguing" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: tomascohen(a)gmail.com Reporter: nugged(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 33784 To test: 0. Set syspref to "AcqCreateItem" set to "cataloguing" ( /cgi-bin/koha/admin/preferences.pl?tab=&op=search&searchfield=AcqCreateItem ) 1. Create a basket 1.1. Go to Acquisitions 1.2. Search for a vendor 1.3. Click New > Basket 1.4. Fill out the basket form 1.5. Click Save 2. Add at least one order to the basket 2.1. Click Add to basket 2.2. Click From a new (empty) record 2.3. Fill out the order form 2.4. Click Save 3. Click Close basket and confirm 4. Click Receive shipments 5. THE PROBLEM IS HERE: - "Confirm" button never gets enabled even if we fill in the form fields, - "Date received:" not prefilled but better should be filled (auto? or from DB?), - "Quantity received:" not prefilled, but on 22.11 it was "1" by default and anyway saved clicks for librarians, and maybe it also should be filled with some cleverly even in "AcqCreateItem" set to "cataloguing" (=1?) NOTE: "AcqCreateItem" set to "cataloguing" is used in our libraries because they receive newspapers and magazines which not then have physical items but by quantity per-biblio, that's why and hos this option is used in our case. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33784 [Bug 33784] Save clicks on single order receive -- You are receiving this mail because: You are watching all bug changes.

1 43