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

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

30 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7012 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=5463 -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 13498] 'email' templates used for printing slips
by bugzilla-daemon＠bugs.koha-community.org 30 Nov '22

30 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13498 --- Comment #20 from Emmi Takkinen <emmi.takkinen(a)koha-suomi.fi> --- (In reply to Emmi Takkinen from comment #19) > Tested this a little (sorry if I'm repeating what has already been said). We > call printslip.pl when printing ISSUESLIP or ISSUEQSLIP and from there we > call IssueSlip(). This then calls GetPreparedLetter(). > If we add message_transport_type => 'print' parameter to that > GetPreparedLetter() call in IssueSlip(), print notice is printed correctly. > However if 'print' notice isn't found, GetPreparedLetter() fails to, because > > my $mtt = $params{message_transport_type} || 'email'; > > obviously has value 'print', not undef and doesn't fall back to email. > > So we need to 1) add message_transport_type => 'print' param when calling > notices that are primaly printed (not just to printslip.pl but also > hold-transfer-slip.pl etc.) 2) determine in GetPreparedLetter() if print > notice actually exists and then fall back to email notice. Correcting the first point, we need to add message_transport_type to methods which are called when printing mainly 'print' notices. E.g. printslip.pl -> IssueSlip(), hold-transfer-slip.pl -> ReserveSlip(). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 13498] 'email' templates used for printing slips
by bugzilla-daemon＠bugs.koha-community.org 30 Nov '22

30 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13498 --- Comment #19 from Emmi Takkinen <emmi.takkinen(a)koha-suomi.fi> --- Tested this a little (sorry if I'm repeating what has already been said). We call printslip.pl when printing ISSUESLIP or ISSUEQSLIP and from there we call IssueSlip(). This then calls GetPreparedLetter(). If we add message_transport_type => 'print' parameter to that GetPreparedLetter() call in IssueSlip(), print notice is printed correctly. However if 'print' notice isn't found, GetPreparedLetter() fails to, because my $mtt = $params{message_transport_type} || 'email'; obviously has value 'print', not undef and doesn't fall back to email. So we need to 1) add message_transport_type => 'print' param when calling notices that are primaly printed (not just to printslip.pl but also hold-transfer-slip.pl etc.) 2) determine in GetPreparedLetter() if print notice actually exists and then fall back to email notice. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 13498] 'email' templates used for printing slips
by bugzilla-daemon＠bugs.koha-community.org 30 Nov '22

30 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13498 --- Comment #18 from Emmi Takkinen <emmi.takkinen(a)koha-suomi.fi> --- Problem still exists on current master. This also happens when printing via "print and clear screen" button. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 13498] 'email' templates used for printing slips
by bugzilla-daemon＠bugs.koha-community.org 30 Nov '22

30 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13498 Emmi Takkinen <emmi.takkinen(a)koha-suomi.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emmi.takkinen(a)koha-suomi.fi -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 32374] New: CHECKIN notice preview not accurate
by bugzilla-daemon＠bugs.koha-community.org 29 Nov '22

29 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32374 Bug ID: 32374 Summary: CHECKIN notice preview not accurate Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org TO recreate: I'm using this CHECKIN notice template: [% borrower.firstname %] [% borrower.surname %] The following items have been checked in: ---- [% biblio.title %] ---- Thank you. 1. Add my sample notice. 2. Checkout an item. 3. Use that item's barcode to generate a preview. 4. Notice the firstname and surname are missing 5. Check the item in to generate the actual notice. ( make sure the patron's messaging prefs are set to receive one ) 6. It accurately adds the firstname and surname. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 15500] Add FRBRized view to OPAC & staff interface results
by bugzilla-daemon＠bugs.koha-community.org 29 Nov '22

29 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15500 Lauren Denny <lauren_denny(a)sil.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lauren_denny(a)sil.org -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 30181] New: Koha::BackgroundJob->_derived_class returns an empty object
by bugzilla-daemon＠bugs.koha-community.org 29 Nov '22

29 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30181 Bug ID: 30181 Summary: Koha::BackgroundJob->_derived_class returns an empty object 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 If you look at Koha::BackgroundJob->process, you will notice some funky stuff. After re-reading how background_jobs_worker.pl does its job, you notice that the main loop can only deal with Koha::BackgrounJob objects (i.e. not Koha::BackgroundJob::BatchUpdateItem). This is because it either gets a job id (STOMP use case) or it uses a Koha::BackgroundJobs->search to find jobs. So, when a job is found (say $job), the worker eventually calls $job->process. At that point, it needs to instantiate the 'real' class to properly call its overridden ->process method. When it does so, it creates a new/empty object, that is passed... the id. So, devs implementing background jobs need to take care of retrieving the job object so they are able to update the job status. This is not cool. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 5463] limit to available shows on hold items
by bugzilla-daemon＠bugs.koha-community.org 29 Nov '22

29 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5463 --- Comment #9 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- (In reply to Sam Passey from comment #4) > Does anyone have updates on this one? This is problematic. Available now to > me means that something is on the shelf at that moment that someone should > be able to grab. There is not update. No one is working on this bug, unfortunately. -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 32371] New: Restart Hold Process
by bugzilla-daemon＠bugs.koha-community.org 29 Nov '22

29 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32371 Bug ID: 32371 Summary: Restart Hold Process 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 How about an option to restart a hold that is waiting? Currently, you can revert the waiting status to next in line, but sometimes patrons or staff need to cancel the hold, and start the hold process again. Perhaps the patron can't pick up the hold and wants to go back on the list, but they need to go to the end of the queue again. This is a tedious process that could be simplified with an action choice. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0