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

[Bug 12388] IssueSlip output should be sorted by date_due, not timestamp
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '22

14 Sep '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12388 --- Comment #18 from Emmi Takkinen <emmi.takkinen(a)koha-suomi.fi> --- (In reply to Joonas Kylmälä from comment #17) > Running prove t/db_dependent/Members/IssueSlip.t gives the following warning: > > t/db_dependent/Members/IssueSlip.t .. > DBIx::Class::ResultSet::_construct_results(): Unable to properly collapse > has_many results in iterator mode due to order criteria - performed an eager > cursor slurp underneath. Consider using ->all() instead at > /kohadevbox/koha/Koha/Objects.pm line 312 > If I understand correctly (and correct me if I'm wrong), this happens because sub pending_checkouts uses prefetch to get data (at least) from biblio table. Bug 28561 handled same kind of problem, comment from there: > DBIx says about prefetching and collapse the following: > If an "order_by" is already declared, and orders the resultset in a way that > makes collapsing as described above impossible (e.g. ORDER BY > has_many_rel.column or ORDER BY RANDOM()), DBIC will automatically switch to > "eager" mode and slurp the entire resultset before constructing the first > object returned by "next". In bug 28561 this was handled by replacing prefetch with join. However using this same approach here would mean we lose data from biblio table since join returns data only from, in this case, issues table. At least one solution for this would be to move those order_by statements (date_due, issuedate) from sub IssuesSlip to sub pending_reserves. However I'm not sure if this could have some side effects in other parts of Koha. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 31554] New: Sorting of acquisition info appears to be broken
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '22

14 Sep '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31554 Bug ID: 31554 Summary: Sorting of acquisition info appears to be broken Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 20726 According to the notes on bug 20726 the acquisition details for subscriptions should sort by status (open/pending) first and then by ordernumber. The first appears to work, but the second doesn't. Looking at the subscription details of a record with all status being 'complete' the secondary sorting doesn't appear to work. In the column order number, we see: 1683 948 2095 So it doesn't appear to sort alphabetically either. In the column basket we have 2... (603) B... (328) 2... (774) So neither works. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20726 [Bug 20726] Display acquisition details on the subscription detail page -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 31539] New: Delay not taken in account when items with different due date are listed in overdue notices
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '22

13 Sep '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31539 Bug ID: 31539 Summary: Delay not taken in account when items with different due date are listed in overdue notices Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: noemie.labine(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org Hi, When we set 3 overdue notices in the Overdue notice/status triggers tool, delay depends on the due date. But if a user has a couple of overdue documents, the notices sent take all of the documents without taking the delay into account. I have 3 triggers set, the first overdue notice (odue1) is set to be sent after a delay of 1 day, the second overdue notice (odue2) is set to be sent after a delay of 7 days and the third one (odue3) after a delay of 21 days. In each of the notice's body I have items informations like title and author between html tags(<Item><Item/>). Let's say I have one document due on september 1st (Harry Potter) and one due on september 10 (Lord of the Ring). On september 2 odue1 is sent and in the message body it says "Your document : Harry Potter is overdue, bla bla bla" On september 8, odue2 is sent for Harry Potter with the right message "Your document : Harry Potter is overdue, bla bla bla". But, on september 11 an odue1 is sent for Lord of the Ring, but the message body it also mentions Harry Potter even tho we are way past the 1 day delay, at that point we are at 10 days. "Your documents : -Harry Potter -Lord of the Ring is overdue, bla bla bla" On september 22, odue3 is sent for Harry Potter and also mentions Lord of the Ring even tho at that point LotR has only been overdued for 12 days. So, it seems that overdue_notices.pl takes all of the overdue documents in an user account and add those document's informations even tho they are not concerned by the trigger delay. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 6419] Add customizable areas to intranet home pages
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '22

13 Sep '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6419 --- Comment #15 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- Yeah, I rebased it, but I also think perhaps it should be done using more modern options. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 20726] New: Display acquisition details on the subscription detail page
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '22

13 Sep '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20726 Bug ID: 20726 Summary: Display acquisition details on the subscription detail page Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Serials Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Bug 20365 will add the ability to create several pending orders on the same subscription. To make it clear we should add a history of the acquisition on the subscription detail page. -- You are receiving this mail because: You are watching all bug changes.

1 60

[Bug 31456] New: Optionally hide lightbox_descriptions from intranet lightbox gallery
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '22

13 Sep '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31456 Bug ID: 31456 Summary: Optionally hide lightbox_descriptions from intranet lightbox gallery Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Like in bug 31446 libraries should have the option to hide the descriptions displaying under items in the lightbox galleries on the intranet item detail pages. This is particularly useful for libraries that only have one source of images enabled - e.g. Coce - in which case displaying where the item is from when it is the only image displaying on an item detail page, is not always useful. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 31446] New: Optionally hide lightbox_descriptions from OPAC lightbox gallery
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '22

13 Sep '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31446 Bug ID: 31446 Summary: Optionally hide lightbox_descriptions from OPAC lightbox gallery Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Since bug 28180 lightbox descriptions have displayed under cover images in the OPAC lightbox gallery. For example: 'Coce image from Amazon.com'. These descriptions are useful if there are multiple cover images in the lightbox gallery. But if there is only one image (for example the library only uses coce images, and not local cover images or other sources) then it would be useful to be able to optionally hide these descriptions. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 12242] Allow hiding branches from the OPAC search pulldowns
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '22

12 Sep '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12242 --- Comment #9 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Katrin Fischer from comment #6) > ON bug 27360 David Cook suggested to use the OPAC public flag for this. I > think this is not a bad idea to extend it's scope. What do others think? I think that David Cook is on to something there... ;) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12242] Allow hiding branches from the OPAC search pulldowns
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '22

12 Sep '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12242 --- Comment #8 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Magnus Enger from comment #4) > paxed: Will you be using some other functionality to hide the items from > searches? What happens if an item connected to your hidden branch turns up > in a search? Yeah, you'd use OpacSuppression or OpacHideItems for that. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 31546] New: Hold delays
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '22

12 Sep '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31546 Bug ID: 31546 Summary: Hold delays Change sponsored?: --- Product: Koha Version: 21.11 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 It seems there is a disadvantage to hold fulfillment if holds are delayed in transit. Take for example, Joe requests an item in a record to be picked up at library A. Library B checks that item in and triggers Joes request. It is in transit, but for any number of reasons, transit is taking longer than usual. Meanwhile, other patrons request items from that same record, and are triggered and fulfilled. Joe is at the mercy of the system and the delays in transit. Would there be a way for other items on the record that happen to get checked in at library A to step in and swap holds with the one in transit and fulfill his hold quicker, since he is at the top of the list waiting? Maybe based on his priority level? So, for example, another item from that record comes in, and if it doesn't have a hold and Joe's hold was a first available, it could take the place of the one in transit? And if there is a hold for that item and lower than Joe's priority, the one in hand could be changed to Joe, and the one in transit would be reassigned to the patron the ready one was for? I don't know if this would wreak havoc with the local holds priority, but this scenario seems more fair than making someone at the top of the list wait because of something out of their control. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2