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

[Bug 31336] New: In-progress background jobs give incorrect progress message
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '23

18 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31336 Bug ID: 31336 Summary: In-progress background jobs give incorrect progress message 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: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 31245 If one loads the background job details page (background_jobs.pl) for a job that has started but not yet completed, Koha shows a message of "No items modified." We should give an accurate message along the lines of "This job is still in progress." A completed job lists all of the modified items/bibs/whatever. I'm ambivalent about whether or not we need to list the already-modified records when loading this page for an incomplete job. To recreate: 1 - write a report, SELECT itemnumber FROM items. With the default dev data, that's 961 items. 2 - use your report to send all of those to batch mod. The page will take a while to load 3 - while your batch mod page is loading, open background_jobs.pl in another tab and have it ready to go 4 - modify something in all 961 records -- add a public note or something -- once you submit this job it should take about 45 seconds to complete 5 - BEFORE THE JOB IS DONE - reload background_jobs.pl, see your job is listed and shows status=started. click to the details view for your job, see it shows a message of "No items modified." Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31245 [Bug 31245] Job detail view for batch mod explode if job not started -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 31580] New: Koha::BackgroundJob->finish should consider the 'failed' case
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '23

18 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31580 Bug ID: 31580 Summary: Koha::BackgroundJob->finish should consider the 'failed' case Change sponsored?: --- Product: Koha Version: unspecified 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org See bug 27421, which introduces it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 31363] New: Background jobs table should include columns for name and branch of initiating staff user
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '23

18 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31363 Bug ID: 31363 Summary: Background jobs table should include columns for name and branch of initiating staff user Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: jrobb(a)sekls.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There is no clear indicator within the background jobs table of who initiated the job. This is problematic in our consortium setting as many different people are triggering jobs in a given day and if we want to check on a specific job, we either need to know the exact time the job was started or the exact number of items that were touched. It would be handy if the table included a column for the initiating staff user's name and a column for their branch to make it easier to distinguish who did what and filter down the table. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 27258] New: Rename BackgroundJobs => Tasks
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '23

18 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27258 Bug ID: 27258 Summary: Rename BackgroundJobs => Tasks Change sponsored?: --- Product: Koha Version: master 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 We should make the change now it is fresh. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 32481] New: Rabbit times out when too many jobs are queued and the response takes too long
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '23

18 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32481 Bug ID: 32481 Summary: Rabbit times out when too many jobs are queued and the response takes too long 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 We saw this happen several times - a library would queue up 6 batch modifications that would take roughly 6 minutes each. The jobs would process normally, until the 30 minute configured timeout would hit - then the remaining job would fail, and rabbit would disconnect and not reconnect, and jobs would pile up It seems that koha receives all of the jobs immediately, but only acknowledges when complete - so the final job was waiting over 30 minutes for acknowledgement and this caused issues -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 52

[Bug 26558] New: Guarantor information is lost when an error occurs during new account creation
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '23

17 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26558 Bug ID: 26558 Summary: Guarantor information is lost when an error occurs during new account creation Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: george(a)nekls.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To reproduce: 1. Create a new account but cause an error that will keep the account from saving (enter the wrong age for a category or give the patron a username that's already being used) 2. Search for and select a guarantor 3. Try to save the account and wait for the "The following fields are wrong. Please fix them." message 4. Note that the guarantor information is gone and you need to search for and select the guarantor again -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 21812] New: When adding items while ordering, the quantity field should not look like it can be edited
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '23

17 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21812 Bug ID: 21812 Summary: When adding items while ordering, the quantity field should not look like it can be edited Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: enhancement 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 adding items during creating the order in acquisitions, the quantity field cannot be edited, you have to use the item form and table above for increasing and decreasing the amount of items ordered. This if often misunderstood in traning, in part because the input field looks like it can be edited, when it's actually read-only. It would be nice if this could be improved, maybe even with a hint to use the form above. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 31254] New: Add additional fields for accountlines
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '23

17 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31254 Bug ID: 31254 Summary: Add additional fields for accountlines Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 30556] New: OPAC shows "Place hold" button on available items even if on shelf holds aren't allowed
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '23

17 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30556 Bug ID: 30556 Summary: OPAC shows "Place hold" button on available items even if on shelf holds aren't allowed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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: gmcharlt(a)gmail.com When circulation rules don't allow on shelf holds, the "Place hold" button still appears on the OPAC next to available items. 1. Create a circulation rule with on shelf holds set to "If all unavailable" 2. Create or modify a record to match the items itype to the circulation rule 3. Use a patron matching the circ rule category to log into the opac 4. Look for the record The Place hold button should not appear, but currently, it does. I think this may be related to Bug 3142? I'm not sure... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 81

[Bug 21828] New: Improve efficiency of C4::Biblio::LinkBibHeadingsToAuthorities
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '23

17 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21828 Bug ID: 21828 Summary: Improve efficiency of C4::Biblio::LinkBibHeadingsToAuthorities Change sponsored?: --- Product: Koha Version: master 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org The routine iterates through all fields in a biblio and compares them to a list of acceptable tags that may link to an authority. It may be more efficient to do the opposite iteration, working through acceptable authority tags and looking for the existence of that field in the biblio. (Note.. I've not tested this hypothesis.. it depends heavily on how efficient it is to fetch a single MARC tag using Marc::Record) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23