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

[Bug 2486] Show user comments in staff interface
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '24

15 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2486 Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to main |Needs documenting -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 23387] New: Cache ClassSource
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '24

15 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23387 Bug ID: 23387 Summary: Cache ClassSource Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: ian(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The data in the class_source table is not prone to frequent change, but is looked up for every biblio, biblioitem and item imported, resulting in needless DB calls and slowness. Caching this relatively static data would provide a moderate performance boost to importing, particularly bulkmarcimport.pl -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 24471] New: Rename ILL method handle_commit_maybe
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '24

15 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24471 Bug ID: 24471 Summary: Rename ILL method handle_commit_maybe Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com The naming of “handle_commit_maybe” is very misleading. As far as I can see from comments and old commits, it was intended to do more at some point but all it does, and has ever done, is redirect the user based on some conditions. A better name would be something simpler like “redirect_user” -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 6532] Way to move items to another record in batches
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '24

15 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6532 --- Comment #10 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- +1 We currently have large print and regular print items in the same records, and we are starting a project where we need to split these up. There is no current workflow to do this efficiently. -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 8425] Autobarcode generates duplicate barcodes with AcqCreateItems = on order
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '24

15 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8425 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff --- Comment #23 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> --- > +if(typeof autobarcodetype == 'undefined') { > + var autobarcodetype = "$autoBarcodeType"; > + var attempt = -1; > +} > => This does not look good either? Why are we conditionally declaring vars here? @Marcel I did not address this point, tell me if you see a clean solution for this dirty code :) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8425] Autobarcode generates duplicate barcodes with AcqCreateItems = on order
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '24

15 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8425 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #171350|0 |1 is obsolete| | Attachment #171351|0 |1 is obsolete| | --- Comment #22 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> --- Created attachment 174602 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=174602&action=e… Bug 8425: Increment the barcode on each call of set_barcode() Duplicate barcodes are generated when placing an Order in Acquisitions when AcqCreateItem = "placing an order" and Autobarcode is turned on. The problem is that you can accidentally attach 3 items to an order, but only 1 will be saved to the database. When you go to receive your order, you can only receive 1 item as the other two were never made, since the barcode wasn't unique. In 3.8.0, a software error comes up which prevent any item creation, I believe, but master (3.9.x) doesn't throw any warnings or errors. Yes.. This tries and solve a bug from 3.8.0 /o/ Test plan: 1 - set syspref "autoBarcode" to generated in the form <branchcode> yymm001 2 - set the barcode field to "barcode.pl" in marc structure 3 - create a new basket 4 - add one item to this basket 5 - click on the barcode field -> it should have a barcode 6 - click on add item and click on the new barcode fiels, it should have the same value APPLY PATCH: 7 - click on the barcode field -> it should have a barcode 8 - click on add item and click on the new barcode fields, it should have an higher barcode. Note : The barcode is incremented each time the barcode with an empty value is clicked on. Therefore, if the librarian removes the value from barcode and click again, they could get another barcode. I do not know if it is an issue. Note: This patch is not splitted in two parts anymore Signed-off-by: Sam Sowanick <sam.sowanick(a)corvallisoregon.gov> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 31921] New: No confirmation alert when deleting a vendor
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '24

15 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31921 Bug ID: 31921 Summary: No confirmation alert when deleting a vendor Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 28082 First vendor of the page has a confirmation alert, but the answer is ignored! I guess it's coming from Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28082 [Bug 28082] Add acquisitions toolbar to vendors on vendor search page -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 34544] New: Add file option to delete_items.pl
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '24

15 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34544 Bug ID: 34544 Summary: Add file option to delete_items.pl Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: Slodico(a)knoxlib.org QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Writeoff_debts.pl and delete_patrons.pl can both be run with input from a file. Please add this option to delete_items.pl. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 8425] Autobarcode generates duplicate barcodes with AcqCreateItems = on order
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '24

15 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8425 --- Comment #21 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> --- (In reply to Marcel de Rooy from comment #20) > get_barcode > my $scr = qq~ > let elt = \$("#"+id); > let homebranch = elt.parents('fieldset.rows:first') > > .find('input[name="kohafield"][value="items.homebranch"]') > .siblings("select") > .val(); > > if(typeof offset == 'undefined'){ > var offset = 0; > } > if ( \$(elt).val() == '' ) { > \$(elt).val(homebranch + ($nextnum + offset)); > } > ~; > TOGETHER WITH > +function set_barcode(id, force, offset=0) { > => Default is zero. Why are we checking the type then later? Seems useless? Tbh I'm very unsecure with this part of the code and I'm unable to prove that this body is not appended to any other function without this prototype, hence to secure the behavior I prefered adding this. If there is a way to be sure this function definition will not be appended to any other prototype, then this part of the code is useless. > +if(typeof autobarcodetype == 'undefined') { > + var autobarcodetype = "$autoBarcodeType"; > + var attempt = -1; > +} > => This does not look good either? Why are we conditionally declaring vars > here? The point here is that due to the way this works, the script is imported each time you click on "add item", hence this will reset the number of attempts and so one. This is also true if you put it in a document.ready. We might use attempts as condition and only do this for attempts, it might be more understandable. > Why are we fixing this only for a specific autobarcode type? Good question, I'm on it. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38445] New: msgid "" breaks translation process
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '24

15 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38445 Bug ID: 38445 Summary: msgid "" breaks translation process Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: f.demians(a)tamil.fr, jonathan.druart(a)gmail.com Added Tibetan and ended up with an empty msgid and it broke the translation process https://gitlab.com/koha-community/koha-l10n/-/commit/c4fa26cc6023fc67428ae8… misc/translator/po/bo-CN-marc-MARC21.po: warning: Charset missing in header. Message conversion to user's charset will not work. misc/translator/po/bo-CN-marc-MARC21.po:19859: duplicate message definition... misc/translator/po/bo-CN-marc-MARC21.po:2: ...this is the location of the first definition msgmerge: found 1 fatal error Coming from koha-tmpl/intranet-tmpl/prog/en/xslt/MARC21slimUtils-MODS31.xsl:16 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6