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

[Bug 7012] Limit to available does not exclude in-transit items
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '23

22 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7012 Christopher Brannon <cbrannon(a)cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cbrannon(a)cdalibrary.org --- Comment #11 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- I am hoping this feature will get some much needed attention. It has been unreliable for way too long. -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 33287] New: Race condition in Koha::BackgroundJob?
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '23

22 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33287 Bug ID: 33287 Summary: Race condition in Koha::BackgroundJob? Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: major Priority: P3 Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org With 22.11.03, I am experiencing the following: with ES indexing on, some record, sometimes, are not being indexed. A long time after record insertion I can still find respective entries in Administration > Manage jobs, and also background_jobs entries with status ‘new’, background_jobs.enqueued_on equal to respective action_logs.timestamp entry, background_jobs.started_on == background_jobs.ended_on == NULL. At the same time, in worker-output.log there is a line like: [2023/03/20 17:18:10] [WARN] No job found for id=13218 main:: /usr/share/koha/bin/background_jobs_worker.pl (114) What is worth noting, the timestamp from worker-output.log is identical with those of action_logs.timestamp and background_jobs.enqueued_on. Closer inspection of rabbitmq shows that the queue is empty. I wonder if the following scenario could be true: 1. in Koha::BackgroundJob::enqueue, the job description is being stored in DB and the job is enqueued, i.e. sent to rabbitmq 2. the worker process immediately reads the queue element from rabbitmq, getting the job_id as a part of the answer ($args->{job_id}) 3. as a consequence, the worker tries to get the job from DB with Koha::BackgroundJobs->find($args->{job_id}), but the DBIx at this very moment Koha::BackgroundJobs does not answer with a job object, because 'store' story has not finished yet (?) 4. as a result, the worker generates the warning "No job found for id=n" 5. unfortunately, the element has already been read from the queue and the worker will never return to it When I than imitate the worker function with my own script, looking for the unfulfilled background jobs, I get the job objects from Koha::BackgroundJobs and I can successfully call $args = $job->json->decode($job->data); and $job->process( $args ); If p. 3 was true, then we would have a race condition here. Or maybe there is another explanation for this behavior...? I wonder if anybody is experiencing same problem. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 10941] MARC21 documentation links while adding an authority
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '23

22 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10941 Juliet Heltibridle <jheltibridle(a)rcplib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jheltibridle(a)rcplib.org --- Comment #5 from Juliet Heltibridle <jheltibridle(a)rcplib.org> --- I would like to see this added, I use the documentation links on bibliographic records very often and would use them if they were included on authority records as well. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 27211] New: Shelving locations for holds
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '23

22 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27211 Bug ID: 27211 Summary: Shelving locations for holds 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Every library handles holds differently, but one thing remains the same through most, if not all...when a hold is triggered, it waits somewhere in the building. Some libraries might have more than one shelving location. One issue that has always been a problem for libraries that have automatically expired holds, or any library that has a cancelled hold. Unless someone is going through each of the holds on the hold shelf daily, how do you find the item? If you look up an held item that has automatically expired (guessing on this, as we don't do this), or an item that is cancelled, the item shows the regular shelving location and that it is AVAILABLE. This is of no help to staff or the patron. One solution might be to use the CART feature, and update the temporary location to reflect a given shelving location for holds. There are a few issues for using this feature: 1) the CART location reverts back to the permanent shelving location after X amount of days. This would have to be overridden to stick until the item is actually not being held and is checked in, and then go through the regular CART routine, if any. 2) When triggering a hold, the hold would have to know which shelving location is being used. We could either define a default location that could be changed to a select few locations (maybe a HOLDLOC table?), so the default could be used without extra steps, OR even further, a default shelving location defined for each desk (I know the desk feature is part of an upcoming Koha upgrade). If staff don't want the public to know that the item is on a public hold pickup shelf, the OPAC description could simply read "See staff for assistance". Thoughts? Is this doable? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 8367] How long is a hold waiting for pickup at a more granular level
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '23

22 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 ByWater Sandboxes <bws.sandboxes(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #147807|0 |1 is obsolete| | --- Comment #233 from ByWater Sandboxes <bws.sandboxes(a)gmail.com> --- Created attachment 148545 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=148545&action=e… Bug 8367: (QA follow-up) Improve display when value not set for rule When a rule is not set for a speficic line, the value in the syspref will be used. This should be made clear in the interface. To test: 1 - Add a new rule for a specific item type 2 - Do not fill the 'Hold pickup period' 3 - Confirm that the rule defaults to the system preference 4 - Hover on 'Default' in the circ rules under 'Hold pickup period' 5 - Confirm the text is readable Signed-off-by: Nick Clemens <nick(a)bywatersolutions.com> Signed-off-by: Kelly <kelly(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8367] How long is a hold waiting for pickup at a more granular level
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '23

22 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 ByWater Sandboxes <bws.sandboxes(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #147806|0 |1 is obsolete| | --- Comment #232 from ByWater Sandboxes <bws.sandboxes(a)gmail.com> --- Created attachment 148544 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=148544&action=e… Bug 8376: (QA follow-up) Update message on Hold waiting pickup report Signed-off-by: Nick Clemens <nick(a)bywatersolutions.com> https://bugs.koha-community.org/show_bug.cgi?id=8367 Signed-off-by: Kelly <kelly(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8367] How long is a hold waiting for pickup at a more granular level
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '23

22 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 ByWater Sandboxes <bws.sandboxes(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #147805|0 |1 is obsolete| | --- Comment #231 from ByWater Sandboxes <bws.sandboxes(a)gmail.com> --- Created attachment 148543 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=148543&action=e… Bug 8367: (follow-up) possible to delete circ rule Signed-off-by: Emmi Takkinen <emmi.takkinen(a)koha-suomi.fi> Signed-off-by: Nick Clemens <nick(a)bywatersolutions.com> Signed-off-by: Kelly <kelly(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8367] How long is a hold waiting for pickup at a more granular level
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '23

22 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 ByWater Sandboxes <bws.sandboxes(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #147804|0 |1 is obsolete| | --- Comment #230 from ByWater Sandboxes <bws.sandboxes(a)gmail.com> --- Created attachment 148542 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=148542&action=e… Bug 8367: (follow-up) Remove unnecessary code and atomic update Signed-off-by: Emmi Takkinen <emmi.takkinen(a)koha-suomi.fi> Signed-off-by: Nick Clemens <nick(a)bywatersolutions.com> Signed-off-by: Kelly <kelly(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8367] How long is a hold waiting for pickup at a more granular level
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '23

22 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 ByWater Sandboxes <bws.sandboxes(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #147803|0 |1 is obsolete| | --- Comment #229 from ByWater Sandboxes <bws.sandboxes(a)gmail.com> --- Created attachment 148541 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=148541&action=e… Bug 8367: (follow-up) Fix tests Signed-off-by: Emmi Takkinen <emmi.takkinen(a)koha-suomi.fi> Signed-off-by: Nick Clemens <nick(a)bywatersolutions.com> Signed-off-by: Kelly <kelly(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8367] How long is a hold waiting for pickup at a more granular level
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '23

22 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 ByWater Sandboxes <bws.sandboxes(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #147802|0 |1 is obsolete| | --- Comment #228 from ByWater Sandboxes <bws.sandboxes(a)gmail.com> --- Created attachment 148540 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=148540&action=e… Bug 8367: (follow-up) Remove pickup delay message from OPAC It adds unnecessary complexity and information. Signed-off-by: Emmi Takkinen <emmi.takkinen(a)koha-suomi.fi> Signed-off-by: Nick Clemens <nick(a)bywatersolutions.com> Signed-off-by: Kelly <kelly(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0