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

[Bug 27915] New: Change wording on Holds Over tab on Holds Awaiting Pickup Report
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '21

10 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27915 Bug ID: 27915 Summary: Change wording on Holds Over tab on Holds Awaiting Pickup Report Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com With bug 8367, Koha is adding the ability to have different hold periods per item type/patron category. It would be nice to have the Holds Awaiting Pickup report change slightly for this new enhancement. Currently, the Holds Awaiting Pick-up report has two tabs, Current Holds, and Holds Awaiting Over x days. This X comes from the system preference- but since this time period can no vary, it would be nice if this tab's wording could change to "Holds Past Expiration Date"- so all Holds that have expired due to the sys pref rule or a circ rule will appear here. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 5697] Automatic linking in guided reports
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '21

10 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5697 --- Comment #25 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to Jonathan Druart from comment #20) > Why opening in a new window? (target="_blank") > Let's teach people middle-click exists! :D We always add target="_blank" because we don't want them to rerun the more complicated queries a lot of times because they don't know about the middle click or forget about it. I would prefer it opening in a new tab by default in this case! if you middle click it anyway, that would not hurt. -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

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

10 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 Emmi Takkinen <emmi.takkinen(a)koha-suomi.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- 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 10 Mar '21

10 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 Emmi Takkinen <emmi.takkinen(a)koha-suomi.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #118017|0 |1 is obsolete| | --- Comment #149 from Emmi Takkinen <emmi.takkinen(a)koha-suomi.fi> --- Created attachment 118021 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=118021&action=e… Bug 8367: Add holds_pickup_period circulation rule So that pickup delay can have a different value per patron category, item type or branch. To test: 1) Update database, restart services 2) Set ReservesMaxPickUpDelay syspref (if not already set) 3) Edit your circulation rules and set a value under 'Holds pickup period (day) that is DIFFERENT from ReservesMaxPickUpDelay. Set a few different numbers for different branches as well. 4) Place a hold on a biblio from the staff client. 5) Check in an item from that biblio and confirm the hold as waiting 6) Confirm the expiration date is calculated using the 'Holds pickup period' value instead of the ReservesMaxPickUpDelay syspref 7) Revert the waiting status and delete the hold 8) Re-place the hold on the biblio on the OPAC. Notice that when you change the pick up location, the number of days in the pickup message below the dropdown changes based on the circ rules. 9) Create a holiday with a date that will overlap with the 'Holds pickup period' 10) Check in an item from that biblio and confirm the hold as waiting 11) Confirm the expiration date is calculated using the 'Holds pickup period' value AND considers the special holiday 12) Confirm tests pass t/db_dependent/Holds/WaitingReserves.t 13) Test Talking Tech: 13a) Enable TalkingTechItivaPhoneNotification 13b) Go to Tools -> Notices & slips. Add content to the HOLD phone (itiva) notice. 13c) In your terminal, run perl /path/to/koha/misc/cronjobs/thirdparty/TalkingTech_itiva_outbound.pl -o ~/itiva.tmp -w 0 --type=RESERVE Sponsored-by: Catalyst IT Signed-off-by: Emmi Takkinen <emmi.takkinen(a)koha-suomi.fi> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 27914] New: Sound material type displays wrong icon in OPAC/Staff details
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '21

10 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27914 Bug ID: 27914 Summary: Sound material type displays wrong icon in OPAC/Staff details Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: hagud(a)orex.es QA Contact: testopia(a)bugs.koha-community.org There is a minor issue in material type between results and detail displau, it doesn't match the icon at results and display (opac and staff) Material type j is PR in results, and MU in details (OPAC & Staff) MARC21slim2OPACResults.xsl </xsl:when> <xsl:when test="$leader6='t'">BK</xsl:when> <xsl:when test="$leader6='o' or $leader6='p'">MX</xsl:when> <xsl:when test="$leader6='m'">CF</xsl:when> <xsl:when test="$leader6='e' or $leader6='f'">MP</xsl:when> <xsl:when test="$leader6='g'">VM</xsl:when> <xsl:when test="$leader6='k'">PK</xsl:when> <xsl:when test="$leader6='r'">OB</xsl:when> <xsl:when test="$leader6='i'">MU</xsl:when> <xsl:when test="$leader6='j'">MU</xsl:when> <-- THIS IS PR IN results--> <xsl:when test="$leader6='c' or $leader6='d'">PR</xsl:when> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 5697] Automatic linking in guided reports
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '21

10 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5697 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@ptfs-europe | |.com, | |nick(a)bywatersolutions.com Status|Passed QA |Signed Off --- Comment #24 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Martin, Nick, can you have a look at the last patch please? -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 5697] Automatic linking in guided reports
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '21

10 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5697 --- Comment #23 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Hum, should we expect an impact on perfs with this last patch? -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

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

10 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 Aleisha Amohia <aleisha(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #117284|0 |1 is obsolete| | --- Comment #148 from Aleisha Amohia <aleisha(a)catalyst.net.nz> --- Created attachment 118017 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=118017&action=e… Bug 8367: Add holds_pickup_period circulation rule So that pickup delay can have a different value per patron category, item type or branch. To test: 1) Update database, restart services 2) Set ReservesMaxPickUpDelay syspref (if not already set) 3) Edit your circulation rules and set a value under 'Holds pickup period (day) that is DIFFERENT from ReservesMaxPickUpDelay. Set a few different numbers for different branches as well. 4) Place a hold on a biblio from the staff client. 5) Check in an item from that biblio and confirm the hold as waiting 6) Confirm the expiration date is calculated using the 'Holds pickup period' value instead of the ReservesMaxPickUpDelay syspref 7) Revert the waiting status and delete the hold 8) Re-place the hold on the biblio on the OPAC. Notice that when you change the pick up location, the number of days in the pickup message below the dropdown changes based on the circ rules. 9) Create a holiday with a date that will overlap with the 'Holds pickup period' 10) Check in an item from that biblio and confirm the hold as waiting 11) Confirm the expiration date is calculated using the 'Holds pickup period' value AND considers the special holiday 12) Confirm tests pass t/db_dependent/Holds/WaitingReserves.t 13) Test Talking Tech: 13a) Enable TalkingTechItivaPhoneNotification 13b) Go to Tools -> Notices & slips. Add content to the HOLD phone (itiva) notice. 13c) In your terminal, run perl /path/to/koha/misc/cronjobs/thirdparty/TalkingTech_itiva_outbound.pl -o ~/itiva.tmp -w 0 --type=RESERVE Sponsored-by: Catalyst IT -- 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 10 Mar '21

10 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 Aleisha Amohia <aleisha(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 27910] New: Fines and Fees workflow for consortiums
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '21

09 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27910 Bug ID: 27910 Summary: Fines and Fees workflow for consortiums Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Not all fines and fees can be accepted by the library the patron comes into in a consortium. Some consortiums let the circing library keep overdue fines. Others may want to recover those funds for their library. The same goes for lost fees. It would be great if there were options to define if funds stay at the circing library for fines or fees. If there were such an option, we would need to develop how those funds are recorded and processed. It is very difficult for a library to accept funds and then parse those funds out to other libraries after they have been recorded as being taken at their own library. Let's assume a lost item for library B is being paid for at library A. Library B has set their register to claim all lost fees on their items. So, when this item is paid for at Library A, it is recorded as accepted at Library A, but the Cash Up would track any amounts collected for other libraries and would calculate how much goes to Library B, and then what is left for Library A. Only the funds that are not for other libraries would be recorded as the actual incoming funds for Library A. I would think that the totals for each library should have some kind of fund transfer number next to it. That number is recorded (or printed maybe with a barcode) and sent with the funds to that library. Library B would then need to record the receipt of those incoming funds by inputting the transfer number (or maybe scanning the slip), and confirming the amount that came with the slip. The transactions for those funds would then be recorded in the tables as payments received at Library B at that time and would show in their Cash Up for that day. And there would have to be some kind of procedure figured out for discrepancies during the transfer. I know this seems a bit daunting, but at some point this would be a great enhancement for consortiums. I welcome other consortiums to weigh in and give their input on this workflow. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0