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

[Bug 12029] Patrons should be able to delete their patron messages
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '23

23 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12029 --- Comment #67 from Jonathan Druart <jonathan.druart+koha(a)gmail.com> --- Not blocker, but noting: 1. A REST API endpoint would have been better for this job 2. We don't have access to already read notes. Could be added later if needed. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33319] New: Unprintable characters/whitepace breaks item search
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '23

23 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33319 Bug ID: 33319 Summary: Unprintable characters/whitepace breaks item search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When libraries copy and paste callnumbers and other information into items, sometimes additional characters appearing as whitespace in front or the end of the entry are added. These break the item search and you get stuck with 'loading' forever. I wonder if there is a way we could strip any whitespace appearing at the front or end of the string automatically to avoid this issue. At the moment you need to analyze the JSON error and fix all of them manually for the item search to start working again, something that is very laborsome. It might also be nice to automatically trim in the item form as well, at least as an option. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 28201] New: Add API routes to update and create biblio record
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '23

23 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28201 Bug ID: 28201 Summary: Add API routes to update and create biblio record Change sponsored?: --- Product: Koha Version: master Hardware: All URL: https://wiki.koha-community.org/wiki/Biblios_endpoint_ RFC OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi CC: tomascohen(a)gmail.com Blocks: 17371 We need PUT and POST API routes to modify and create biblio records. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17371 [Bug 17371] Add routes for biblios [OMNIBUS] -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 15187] Adding 880 Fields to index-list in order to Increase Search for ALL non-latin Scripts
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '23

23 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15187 --- Comment #37 from David Cook <dcook(a)prosentient.com.au> --- Looks like this wasn't reverted out of 22.05... -- You are receiving this mail because: You are watching all bug changes.

1 0

[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