[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #70 from Emily Lamancusa --- *** Bug 30208 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Emily Lamancusa changed: What|Removed |Added Status|Needs Signoff |Failed QA --- Comment #69 from Emily Lamancusa --- Thanks for the fixes! I added a follow-up with a couple of trivial fixes to the alerts. :) The notice is sent twice when reverting or cancelling an item-level hold from the prompt (sorry for missing that the last time I tested). Is there a reason LostItem needs to be called a second time when the user responds to the prompt of whether to revert or cancel an item-level hold? Couldn't the prompt cancel/revert the hold directly at that point, and avoid re-doing all the lost item processing (including the second notice)? Also, tests are failing: # Subtest: Waiting item is marked as lost 1..17 ok 1 - Biblio-level hold placed not ok 70 - Waiting item is marked as lost # Looks like you planned 17 tests but ran 1. # Failed test 'Waiting item is marked as lost' # at t/db_dependent/Reserves.t line 1546. Can't call method "effective_itemtype" on an undefined value at /kohadevbox/koha/Koha/Hold.pm line 234. # Looks like your test exited with 11 just after 70. Dubious, test returned 11 (wstat 2816, 0xb00) Failed 9/78 subtests -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #68 from Emily Lamancusa --- Created attachment 159111 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=159111=edit Bug 20844: (follow-up) Fix alert boxes for item-level holds Fix styling on the alert in additem.tt Don't show alert in moredetail page if RevertBibLevelHolds is disabled -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Attachment #150480|0 |1 is obsolete|| --- Comment #67 from Aleisha Amohia --- Created attachment 159065 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=159065=edit Bug 20844: (follow-up) Fixes for lists, objects, templates, tests -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Attachment #150350|0 |1 is obsolete|| --- Comment #66 from Aleisha Amohia --- Created attachment 159064 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=159064=edit Bug 20844: (follow-up) Get working with transfers Test: 1) Change branch to Branch B 2) Place a biblio-level hold at Branch B 3) Change branch to Branch A 4) Check in item at Branch A and set waiting and trigger transfer 5) Go to edit item and set item as lost 6) Check borrower's notices tab and confirm the lost_waiting_hold notice was enqueued 7) Follow test plan again with item-level hold Sponsored-by: Catalyst IT -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Attachment #150349|0 |1 is obsolete|| --- Comment #65 from Aleisha Amohia --- Created attachment 159063 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=159063=edit Bug 20844: (follow-up) SendLostHoldNotices This patch adds a new syspref SendLostHoldNotices Test: 1) Update database and restart memcached 2) Enable the SendLostHoldNotices system preference 3) Place a hold on an item 4) Check in the item and set the hold to waiting 5) Go to edit the item and set an item lost status 6) Check the borrower's notices and confirm the notice has been enqueued 7) Confirm the notice is not sent twice when reverting or cancelling the hold 8) Confirm notice enqueues as expected for a bib-level hold Sponsored-by: Catalyst IT -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Attachment #150348|0 |1 is obsolete|| --- Comment #64 from Aleisha Amohia --- Created attachment 159062 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=159062=edit Bug 20844: Revert or cancel lost holds This patch introduces the RevertLostBibLevelHolds syspref. When an item is marked as lost, if there is a bib-level hold on it waiting, the hold is reverted. If there is an item-level hold on it waiting, there is an alert box asking if the library would like to revert the hold or cancel it. Test: 1) Update database and restart memcached/plack 2) Place a hold on Biblio A 3) Check in Item A from Biblio A and set the hold as waiting 4) Edit Item A and give it a lost status (952$1, you may need to edit your MARC frameworks to have this visible in the Editor) 5) Look at your hold. Notice it is still waiting. 6) Go to Administration -> System preferences. Find the RevertLostBibLevelHolds system preference and enable it. 7) Cancel your hold and remove Item A's lost status. Place another biblio-level hold on the same biblio 8) Check in Item A from Biblio A and set the hold as waiting 9) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 10) Edit Item A and give it a lost status 11) Once the page reloads, go to view your hold. It should no longer be waiting and have no item allocated. 12) Cancel your hold and remove Item A's lost status. Place an item-level hold on Item A 13) Check in Item A and set the hold as waiting 14) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 15) Give Item A a lost status and save changes 16) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 17) Confirm your hold is no longer waiting, but the item is still allocated 18) Remove Item A's lost status 19) Check in Item A and set the hold as waiting 20) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 21) Give Item A a lost status and save changes 22) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 23) Confirm the hold is now cancelled 24) Remove Item A's lost status 25) Place an item-level hold on Item A 26) Check in Item A and set the hold as waiting 27) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 28) Give Item A a lost status and save changes 29) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 30) Confirm your hold is no longer waiting, but the item is still allocated 31) Remove Item A's lost status 32) Check in Item A and set the hold as waiting 33) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 34) Give Item A a lost status and save changes 35) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 36) Confirm the hold is now cancelled 37) Remove Item A's lost status 38) Place an item-level hold on Item A. Check in Item A and set the hold as waiting 39) Place an item-level hold on Item B (same biblio) for another borrower. Check in Item B and set the hold as waiting. 40) Give both Items A and B lost statuses. 41) Confirm that both Items are included in the alert box on page when editing items (cataloguing/additem.pl) 42) Confirm that both Items have individual alert boxes on the Items tab (catalogue/moredetail.pl) 43) Confirm tests pass t/db_dependent/Reserves.t Sponsored-by: Catalyst IT -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Status|Patch doesn't apply |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Emily Lamancusa changed: What|Removed |Added See Also||https://bugs.koha-community ||.org/bugzilla3/show_bug.cgi ||?id=1 -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Katie Bliss changed: What|Removed |Added CC||kebl...@dmpl.org -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844
Emily Lamancusa changed:
What|Removed |Added
Status|Failed QA |Patch doesn't apply
--- Comment #63 from Emily Lamancusa
---
I'd love to see this move forward soon! It needs a minor rebase and fixes for
the two issues I noticed the last time I tested, but then I think I'll be able
to sign off on it.
I was able to fix the first issue locally by making the following change in
circulation.pref:
- 690yes: Revert
- 691no: "Don't revert"
+ 6901: Revert
+ 6910: "Don't revert"
The issue was that the code in most places checked the syspref as follows:
if ( C4::Context->preference('RevertLostBibLevelHolds') )
which evaluates to true for both "yes" and "no". (The default was put into the
database as 0, so the odd behavior only occurs after the pref has been
changed.)
For the second issue - do moredetail.tt and additem.tt have access to the
syspref value in any way? It's not clear to me whether either of the template
files is taking the value of the syspref into account when determining whether
to display the confirmation alert for handling a lost item-level hold. However,
all of the .pl files in the patches perform the actual handling of lost
item-level holds inside of a conditional that checks the syspref. I assume the
templates should be checking that data somehow as well, so as to display the
alert only if the syspref is set to "revert"?
--
You are receiving this mail because:
You are watching all bug changes.
___
Koha-bugs mailing list
Koha-bugs@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Emily Lamancusa changed: What|Removed |Added Status|Needs Signoff |Failed QA --- Comment #62 from Emily Lamancusa --- The majority of the test plan works - just a few more bugs to be worked out: - If RevertLostBibLevelHolds is set to "Revert" and later switched back to "Don't Revert", the holds continue to automatically revert even after the syspref is disabled. And yes, I did double-check that I actually clicked "Save" and that the syspref was still set to "Don't Revert" if I navigated away from the System Preferences page and then back ;) - When RevertLostBibLevelHolds is disabled, if a waiting item on an item-level hold is marked as lost, the alert asking whether to revert or cancel the hold still appears, but the "Revert" and "Cancel" buttons have no effect. In combination with the previous bug, the effect is this: * If RevertLostBibLevelHolds has never been enabled, the effect just described occurs. * If RevertLostBibLevelHolds was enabled and then disabled, the alert appears and the buttons revert/cancel the hold, as would be expected if the pref was still enabled A thought: the preference is called RevertLostBibLevelHolds, but if I'm understanding correctly it affects the behavior of both bib level and item level holds. It seems to me that it could more accurately be called RevertLostHolds, and maybe add a note to the description explaining that item-level holds will ask whether they should be reverted or cancelled. Finally, I just want to clarify something from the test plan: > 41) Confirm that both Items are included in the alert box on page when > editing items (cataloguing/additem.pl) As far as I know, additem.pl can only edit one item at a time - is there a way to edit two at once from that page? (When I edited them one at a time they each got an alert as expected, so may not be an issue - just wanted to check.) -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #61 from Aleisha Amohia --- Created attachment 150480 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=150480=edit Bug 20844: (follow-up) Fixes for lists, objects, templates, tests -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844
Emily Lamancusa changed:
What|Removed |Added
Status|Needs Signoff |Failed QA
--- Comment #60 from Emily Lamancusa
---
Hi Aleisha,
I encountered a few errors while trying to test this patchset.
#1
After changing RevertLostBibLevelHolds to "Revert", I get the following error
on cataloguing/additem.pl:
The method Koha::Items->holds is not covered by tests!
Trace begun at /kohadevbox/koha/Koha/Objects.pm line 572
Koha::Objects::AUTOLOAD('Koha::Items=HASH(0x564bf159f540)',
'HASH(0x564bf1743f18)') called at /kohadevbox/koha/cataloguing/additem.pl line
757
eval {...} at /kohadevbox/koha/cataloguing/additem.pl line 2
The error persists even if I change RevertLostBibLevelHolds to "Don't Revert"
and restart all. (It does not occur before I change the syspref, and does not
persist if I reset all.)
-
#2
I get the following error on moredetail.pl:
Can't call method "holds" on an undefined value at
/kohadevbox/koha/catalogue/moredetail.pl line 251
The line in question is:
$item_info->{waiting_holds} = $item->{object}->holds({ found => [ 'W', 'T' ],
item_level_hold => { '!=' => 0 } })->count;
I tried replacing "$item->{object}->holds" with "$item->holds" and that seemed
to fix it (and had no effect on error #1).
-
#3
Tests don't pass:
t/db_dependent/Reserves.t .. "my" variable $item masks earlier declaration in
same scope at /kohadevbox/koha/C4/Circulation.pm line 4029.
t/db_dependent/Reserves.t .. 24/78 No reserves HOLD_CANCELLATION letter
transported by email at /kohadevbox/koha/C4/Letters.pm line 588.
t/db_dependent/Reserves.t .. 73/78 # Looks like you planned 17 tests but
ran 13.
# Failed test 'Waiting item is marked as lost'
# at t/db_dependent/Reserves.t line 1563.
Can't call method "notice_email_address" on unblessed reference at
/kohadevbox/koha/C4/Message.pm line 185.
# Looks like your test exited with 11 just after 73.
t/db_dependent/Reserves.t .. Dubious, test returned 11 (wstat 2816, 0xb00)
Failed 6/78 subtests
--
You are receiving this mail because:
You are watching all bug changes.
___
Koha-bugs mailing list
Koha-bugs@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Attachment #140216|0 |1 is obsolete|| --- Comment #59 from Aleisha Amohia --- Created attachment 150350 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=150350=edit Bug 20844: (follow-up) Get working with transfers Test: 1) Change branch to Branch B 2) Place a biblio-level hold at Branch B 3) Change branch to Branch A 4) Check in item at Branch A and set waiting and trigger transfer 5) Go to edit item and set item as lost 6) Check borrower's notices tab and confirm the lost_waiting_hold notice was enqueued 7) Follow test plan again with item-level hold Sponsored-by: Catalyst IT -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Attachment #140215|0 |1 is obsolete|| --- Comment #58 from Aleisha Amohia --- Created attachment 150349 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=150349=edit Bug 20844: (follow-up) SendLostHoldNotices This patch adds a new syspref SendLostHoldNotices Test: 1) Update database and restart memcached 2) Enable the SendLostHoldNotices system preference 3) Place a hold on an item 4) Check in the item and set the hold to waiting 5) Go to edit the item and set an item lost status 6) Check the borrower's notices and confirm the notice has been enqueued 7) Confirm the notice is not sent twice when reverting or cancelling the hold 8) Confirm notice enqueues as expected for a bib-level hold Sponsored-by: Catalyst IT -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Attachment #140214|0 |1 is obsolete|| --- Comment #57 from Aleisha Amohia --- Created attachment 150348 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=150348=edit Bug 20844: Revert or cancel lost holds This patch introduces the RevertLostBibLevelHolds syspref. When an item is marked as lost, if there is a bib-level hold on it waiting, the hold is reverted. If there is an item-level hold on it waiting, there is an alert box asking if the library would like to revert the hold or cancel it. Test: 1) Update database and restart memcached/plack 2) Place a hold on Biblio A 3) Check in Item A from Biblio A and set the hold as waiting 4) Edit Item A and give it a lost status (952$1, you may need to edit your MARC frameworks to have this visible in the Editor) 5) Look at your hold. Notice it is still waiting. 6) Go to Administration -> System preferences. Find the RevertLostBibLevelHolds system preference and enable it. 7) Cancel your hold and remove Item A's lost status. Place another biblio-level hold on the same biblio 8) Check in Item A from Biblio A and set the hold as waiting 9) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 10) Edit Item A and give it a lost status 11) Once the page reloads, go to view your hold. It should no longer be waiting and have no item allocated. 12) Cancel your hold and remove Item A's lost status. Place an item-level hold on Item A 13) Check in Item A and set the hold as waiting 14) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 15) Give Item A a lost status and save changes 16) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 17) Confirm your hold is no longer waiting, but the item is still allocated 18) Remove Item A's lost status 19) Check in Item A and set the hold as waiting 20) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 21) Give Item A a lost status and save changes 22) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 23) Confirm the hold is now cancelled 24) Remove Item A's lost status 25) Place an item-level hold on Item A 26) Check in Item A and set the hold as waiting 27) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 28) Give Item A a lost status and save changes 29) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 30) Confirm your hold is no longer waiting, but the item is still allocated 31) Remove Item A's lost status 32) Check in Item A and set the hold as waiting 33) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 34) Give Item A a lost status and save changes 35) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 36) Confirm the hold is now cancelled 37) Remove Item A's lost status 38) Place an item-level hold on Item A. Check in Item A and set the hold as waiting 39) Place an item-level hold on Item B (same biblio) for another borrower. Check in Item B and set the hold as waiting. 40) Give both Items A and B lost statuses. 41) Confirm that both Items are included in the alert box on page when editing items (cataloguing/additem.pl) 42) Confirm that both Items have individual alert boxes on the Items tab (catalogue/moredetail.pl) 43) Confirm tests pass t/db_dependent/Reserves.t Sponsored-by: Catalyst IT -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Status|Patch doesn't apply |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Emily Lamancusa changed: What|Removed |Added Status|Needs Signoff |Patch doesn't apply CC||emily.lamancusa@montgomeryc ||ountymd.gov --- Comment #56 from Emily Lamancusa --- Patch doesn't apply Merge conflicts in: koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/moredetail.tt koha-tmpl/intranet-tmpl/prog/en/modules/admin/prefrences/circulation.pref catalogue/moredetail.pl -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #55 from Aleisha Amohia --- (In reply to Felicity Brown from comment #51) > Does this apply to setting a status to "missing" as well as lost? The short answer is Yes. The long answer: this uses items.itemlost value in the database to determine if the item is lost. By default, this is usually linked to the LOST authorised value. So, any selected value of LOST (which might be Lost, or Missing, or Long Overdue) will flag items.itemlost in the database as true. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Attachment #125439|0 |1 is obsolete|| --- Comment #54 from Aleisha Amohia --- Created attachment 140216 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=140216=edit Bug 20844: (follow-up) Get working with transfers Test: 1) Change branch to Branch B 2) Place a biblio-level hold at Branch B 3) Change branch to Branch A 4) Check in item at Branch A and set waiting and trigger transfer 5) Go to edit item and set item as lost 6) Check borrower's notices tab and confirm the lost_waiting_hold notice was enqueued 7) Follow test plan again with item-level hold Sponsored-by: Catalyst IT -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Attachment #125438|0 |1 is obsolete|| --- Comment #53 from Aleisha Amohia --- Created attachment 140215 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=140215=edit Bug 20844: (follow-up) SendLostHoldNotices This patch adds a new syspref SendLostHoldNotices Test: 1) Update database and restart memcached 2) Enable the SendLostHoldNotices system preference 3) Place a hold on an item 4) Check in the item and set the hold to waiting 5) Go to edit the item and set an item lost status 6) Check the borrower's notices and confirm the notice has been enqueued 7) Confirm the notice is not sent twice when reverting or cancelling the hold 8) Confirm notice enqueues as expected for a bib-level hold Sponsored-by: Catalyst IT -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Attachment #125437|0 |1 is obsolete|| --- Comment #52 from Aleisha Amohia --- Created attachment 140214 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=140214=edit Bug 20844: Revert or cancel lost holds This patch introduces the RevertLostBibLevelHolds syspref. When an item is marked as lost, if there is a bib-level hold on it waiting, the hold is reverted. If there is an item-level hold on it waiting, there is an alert box asking if the library would like to revert the hold or cancel it. Test: 1) Update database and restart memcached/plack 2) Place a hold on Biblio A 3) Check in Item A from Biblio A and set the hold as waiting 4) Edit Item A and give it a lost status (952$1, you may need to edit your MARC frameworks to have this visible in the Editor) 5) Look at your hold. Notice it is still waiting. 6) Go to Administration -> System preferences. Find the RevertLostBibLevelHolds system preference and enable it. 7) Cancel your hold and remove Item A's lost status. Place another biblio-level hold on the same biblio 8) Check in Item A from Biblio A and set the hold as waiting 9) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 10) Edit Item A and give it a lost status 11) Once the page reloads, go to view your hold. It should no longer be waiting and have no item allocated. 12) Cancel your hold and remove Item A's lost status. Place an item-level hold on Item A 13) Check in Item A and set the hold as waiting 14) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 15) Give Item A a lost status and save changes 16) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 17) Confirm your hold is no longer waiting, but the item is still allocated 18) Remove Item A's lost status 19) Check in Item A and set the hold as waiting 20) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 21) Give Item A a lost status and save changes 22) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 23) Confirm the hold is now cancelled 24) Remove Item A's lost status 25) Place an item-level hold on Item A 26) Check in Item A and set the hold as waiting 27) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 28) Give Item A a lost status and save changes 29) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 30) Confirm your hold is no longer waiting, but the item is still allocated 31) Remove Item A's lost status 32) Check in Item A and set the hold as waiting 33) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 34) Give Item A a lost status and save changes 35) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 36) Confirm the hold is now cancelled 37) Remove Item A's lost status 38) Place an item-level hold on Item A. Check in Item A and set the hold as waiting 39) Place an item-level hold on Item B (same biblio) for another borrower. Check in Item B and set the hold as waiting. 40) Give both Items A and B lost statuses. 41) Confirm that both Items are included in the alert box on page when editing items (cataloguing/additem.pl) 42) Confirm that both Items have individual alert boxes on the Items tab (catalogue/moredetail.pl) 43) Confirm tests pass t/db_dependent/Reserves.t Sponsored-by: Catalyst IT -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Status|Patch doesn't apply |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Owen Leonard changed: What|Removed |Added Status|Needs Signoff |Patch doesn't apply -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Felicity Brown changed: What|Removed |Added CC||felicity.brown@montgomeryco ||untymd.gov --- Comment #51 from Felicity Brown --- Does this apply to setting a status to "missing" as well as lost? -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #50 from Andrew Fuerste-Henry --- (In reply to Aleisha Amohia from comment #49) > Hi Andrew, it seems that bug exists regardless of this new work. I can work > on Bug 21729 but waiting on that patch shouldn't hold up the signoff for > this enhancement. > > Thanks You're absolutely correct! I didn't add 21729 as a blocker here as it doesn't technically break this feature. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #49 from Aleisha Amohia --- Hi Andrew, it seems that bug exists regardless of this new work. I can work on Bug 21729 but waiting on that patch shouldn't hold up the signoff for this enhancement. Thanks -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Andrew Fuerste-Henry changed: What|Removed |Added CC||and...@bywatersolutions.com --- Comment #48 from Andrew Fuerste-Henry --- On initial testing, this technically works, but is severely hampered by bug 21729 -- when a hold goes to Waiting, the expiration date is set based on ReservesMaxPickUpDelay. When the hold is reverted, that expiration date remains. Without patching 21729, this feature will leave most libraries with a bunch of bib-level holds that expire within a week or so. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Attachment #118266|0 |1 is obsolete|| --- Comment #47 from Aleisha Amohia --- Created attachment 125439 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=125439=edit Bug 20844: (follow-up) Get working with transfers Test: 1) Change branch to Branch B 2) Place a biblio-level hold at Branch B 3) Change branch to Branch A 4) Check in item at Branch A and set waiting and trigger transfer 5) Go to edit item and set item as lost 6) Check borrower's notices tab and confirm the lost_waiting_hold notice was enqueued 7) Follow test plan again with item-level hold Sponsored-by: Catalyst IT -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Attachment #118265|0 |1 is obsolete|| --- Comment #46 from Aleisha Amohia --- Created attachment 125438 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=125438=edit Bug 20844: (follow-up) SendLostHoldNotices This patch adds a new syspref SendLostHoldNotices Test: 1) Update database and restart memcached 2) Enable the SendLostHoldNotices system preference 3) Place a hold on an item 4) Check in the item and set the hold to waiting 5) Go to edit the item and set an item lost status 6) Check the borrower's notices and confirm the notice has been enqueued 7) Confirm the notice is not sent twice when reverting or cancelling the hold 8) Confirm notice enqueues as expected for a bib-level hold Sponsored-by: Catalyst IT -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Attachment #118264|0 |1 is obsolete|| --- Comment #45 from Aleisha Amohia --- Created attachment 125437 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=125437=edit Bug 20844: Revert or cancel lost holds This patch introduces the RevertLostBibLevelHolds syspref. When an item is marked as lost, if there is a bib-level hold on it waiting, the hold is reverted. If there is an item-level hold on it waiting, there is an alert box asking if the library would like to revert the hold or cancel it. Test: 1) Update database and restart memcached/plack 2) Place a hold on Biblio A 3) Check in Item A from Biblio A and set the hold as waiting 4) Edit Item A and give it a lost status (952$1, you may need to edit your MARC frameworks to have this visible in the Editor) 5) Look at your hold. Notice it is still waiting. 6) Go to Administration -> System preferences. Find the RevertLostBibLevelHolds system preference and enable it. 7) Cancel your hold and remove Item A's lost status. Place another biblio-level hold on the same biblio 8) Check in Item A from Biblio A and set the hold as waiting 9) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 10) Edit Item A and give it a lost status 11) Once the page reloads, go to view your hold. It should no longer be waiting and have no item allocated. 12) Cancel your hold and remove Item A's lost status. Place an item-level hold on Item A 13) Check in Item A and set the hold as waiting 14) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 15) Give Item A a lost status and save changes 16) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 17) Confirm your hold is no longer waiting, but the item is still allocated 18) Remove Item A's lost status 19) Check in Item A and set the hold as waiting 20) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 21) Give Item A a lost status and save changes 22) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 23) Confirm the hold is now cancelled 24) Remove Item A's lost status 25) Place an item-level hold on Item A 26) Check in Item A and set the hold as waiting 27) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 28) Give Item A a lost status and save changes 29) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 30) Confirm your hold is no longer waiting, but the item is still allocated 31) Remove Item A's lost status 32) Check in Item A and set the hold as waiting 33) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 34) Give Item A a lost status and save changes 35) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 36) Confirm the hold is now cancelled 37) Remove Item A's lost status 38) Place an item-level hold on Item A. Check in Item A and set the hold as waiting 39) Place an item-level hold on Item B (same biblio) for another borrower. Check in Item B and set the hold as waiting. 40) Give both Items A and B lost statuses. 41) Confirm that both Items are included in the alert box on page when editing items (cataloguing/additem.pl) 42) Confirm that both Items have individual alert boxes on the Items tab (catalogue/moredetail.pl) 43) Confirm tests pass t/db_dependent/Reserves.t Sponsored-by: Catalyst IT -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Status|Patch doesn't apply |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Owen Leonard changed: What|Removed |Added Status|Needs Signoff |Patch doesn't apply -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Klas Blomberg changed: What|Removed |Added CC||klas.blomb...@skovde.se -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Attachment #113210|0 |1 is obsolete|| --- Comment #44 from Aleisha Amohia --- Created attachment 118266 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=118266=edit Bug 20844: (follow-up) Get working with transfers Test: 1) Change branch to Branch B 2) Place a biblio-level hold at Branch B 3) Change branch to Branch A 4) Check in item at Branch A and set waiting and trigger transfer 5) Go to edit item and set item as lost 6) Check borrower's notices tab and confirm the lost_waiting_hold notice was enqueued 7) Follow test plan again with item-level hold Sponsored-by: Catalyst IT -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Attachment #113209|0 |1 is obsolete|| --- Comment #43 from Aleisha Amohia --- Created attachment 118265 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=118265=edit Bug 20844: (follow-up) SendLostHoldNotices This patch adds a new syspref SendLostHoldNotices Test: 1) Update database and restart memcached 2) Enable the SendLostHoldNotices system preference 3) Place a hold on an item 4) Check in the item and set the hold to waiting 5) Go to edit the item and set an item lost status 6) Check the borrower's notices and confirm the notice has been enqueued 7) Confirm the notice is not sent twice when reverting or cancelling the hold 8) Confirm notice enqueues as expected for a bib-level hold Sponsored-by: Catalyst IT -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Attachment #113208|0 |1 is obsolete|| --- Comment #42 from Aleisha Amohia --- Created attachment 118264 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=118264=edit Bug 20844: Revert or cancel lost holds This patch introduces the RevertLostBibLevelHolds syspref. When an item is marked as lost, if there is a bib-level hold on it waiting, the hold is reverted. If there is an item-level hold on it waiting, there is an alert box asking if the library would like to revert the hold or cancel it. Test: 1) Update database and restart memcached/plack 2) Place a hold on Biblio A 3) Check in Item A from Biblio A and set the hold as waiting 4) Edit Item A and give it a lost status (952$1, you may need to edit your MARC frameworks to have this visible in the Editor) 5) Look at your hold. Notice it is still waiting. 6) Go to Administration -> System preferences. Find the RevertLostBibLevelHolds system preference and enable it. 7) Cancel your hold and remove Item A's lost status. Place another biblio-level hold on the same biblio 8) Check in Item A from Biblio A and set the hold as waiting 9) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 10) Edit Item A and give it a lost status 11) Once the page reloads, go to view your hold. It should no longer be waiting and have no item allocated. 12) Cancel your hold and remove Item A's lost status. Place an item-level hold on Item A 13) Check in Item A and set the hold as waiting 14) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 15) Give Item A a lost status and save changes 16) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 17) Confirm your hold is no longer waiting, but the item is still allocated 18) Remove Item A's lost status 19) Check in Item A and set the hold as waiting 20) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 21) Give Item A a lost status and save changes 22) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 23) Confirm the hold is now cancelled 24) Remove Item A's lost status 25) Place an item-level hold on Item A 26) Check in Item A and set the hold as waiting 27) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 28) Give Item A a lost status and save changes 29) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 30) Confirm your hold is no longer waiting, but the item is still allocated 31) Remove Item A's lost status 32) Check in Item A and set the hold as waiting 33) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 34) Give Item A a lost status and save changes 35) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 36) Confirm the hold is now cancelled 37) Remove Item A's lost status 38) Place an item-level hold on Item A. Check in Item A and set the hold as waiting 39) Place an item-level hold on Item B (same biblio) for another borrower. Check in Item B and set the hold as waiting. 40) Give both Items A and B lost statuses. 41) Confirm that both Items are included in the alert box on page when editing items (cataloguing/additem.pl) 42) Confirm that both Items have individual alert boxes on the Items tab (catalogue/moredetail.pl) 43) Confirm tests pass t/db_dependent/Reserves.t Sponsored-by: Catalyst IT -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Status|Patch doesn't apply |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Owen Leonard changed: What|Removed |Added Status|Needs Signoff |Patch doesn't apply -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Niamh Walker-Headon changed: What|Removed |Added CC||niamh.walkerhea...@hse.ie -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Attachment #102336|0 |1 is obsolete|| --- Comment #41 from Aleisha Amohia --- Created attachment 113210 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=113210=edit Bug 20844: (follow-up) Get working with transfers Test: 1) Change branch to Branch B 2) Place a biblio-level hold at Branch B 3) Change branch to Branch A 4) Check in item at Branch A and set waiting and trigger transfer 5) Go to edit item and set item as lost 6) Check borrower's notices tab and confirm the lost_waiting_hold notice was enqueued 7) Follow test plan again with item-level hold Sponsored-by: Catalyst IT -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Attachment #102335|0 |1 is obsolete|| --- Comment #40 from Aleisha Amohia --- Created attachment 113209 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=113209=edit Bug 20844: (follow-up) SendLostHoldNotices This patch adds a new syspref SendLostHoldNotices Test: 1) Update database and restart memcached 2) Enable the SendLostHoldNotices system preference 3) Place a hold on an item 4) Check in the item and set the hold to waiting 5) Go to edit the item and set an item lost status 6) Check the borrower's notices and confirm the notice has been enqueued 7) Confirm the notice is not sent twice when reverting or cancelling the hold 8) Confirm notice enqueues as expected for a bib-level hold Sponsored-by: Catalyst IT -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Status|Patch doesn't apply |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Attachment #102334|0 |1 is obsolete|| --- Comment #39 from Aleisha Amohia --- Created attachment 113208 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=113208=edit Bug 20844: Revert or cancel lost holds This patch introduces the RevertLostBibLevelHolds syspref. When an item is marked as lost, if there is a bib-level hold on it waiting, the hold is reverted. If there is an item-level hold on it waiting, there is an alert box asking if the library would like to revert the hold or cancel it. Test: 1) Update database and restart memcached/plack 2) Place a hold on Biblio A 3) Check in Item A from Biblio A and set the hold as waiting 4) Edit Item A and give it a lost status (952$1, you may need to edit your MARC frameworks to have this visible in the Editor) 5) Look at your hold. Notice it is still waiting. 6) Go to Administration -> System preferences. Find the RevertLostBibLevelHolds system preference and enable it. 7) Cancel your hold and remove Item A's lost status. Place another biblio-level hold on the same biblio 8) Check in Item A from Biblio A and set the hold as waiting 9) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 10) Edit Item A and give it a lost status 11) Once the page reloads, go to view your hold. It should no longer be waiting and have no item allocated. 12) Cancel your hold and remove Item A's lost status. Place an item-level hold on Item A 13) Check in Item A and set the hold as waiting 14) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 15) Give Item A a lost status and save changes 16) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 17) Confirm your hold is no longer waiting, but the item is still allocated 18) Remove Item A's lost status 19) Check in Item A and set the hold as waiting 20) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 21) Give Item A a lost status and save changes 22) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 23) Confirm the hold is now cancelled 24) Remove Item A's lost status 25) Place an item-level hold on Item A 26) Check in Item A and set the hold as waiting 27) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 28) Give Item A a lost status and save changes 29) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 30) Confirm your hold is no longer waiting, but the item is still allocated 31) Remove Item A's lost status 32) Check in Item A and set the hold as waiting 33) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 34) Give Item A a lost status and save changes 35) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 36) Confirm the hold is now cancelled 37) Remove Item A's lost status 38) Place an item-level hold on Item A. Check in Item A and set the hold as waiting 39) Place an item-level hold on Item B (same biblio) for another borrower. Check in Item B and set the hold as waiting. 40) Give both Items A and B lost statuses. 41) Confirm that both Items are included in the alert box on page when editing items (cataloguing/additem.pl) 42) Confirm that both Items have individual alert boxes on the Items tab (catalogue/moredetail.pl) 43) Confirm tests pass t/db_dependent/Reserves.t Sponsored-by: Catalyst IT -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Sally changed: What|Removed |Added CC||sally.healey@cheshireshared ||services.gov.uk Status|Needs Signoff |Patch doesn't apply --- Comment #38 from Sally --- Patch doesn't apply. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #37 from Aleisha Amohia --- Created attachment 102336 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=102336=edit Bug 20844: (follow-up) Get working with transfers Test: 1) Change branch to Branch B 2) Place a biblio-level hold at Branch B 3) Change branch to Branch A 4) Check in item at Branch A and set waiting and trigger transfer 5) Go to edit item and set item as lost 6) Check borrower's notices tab and confirm the lost_waiting_hold notice was enqueued 7) Follow test plan again with item-level hold Sponsored-by: Catalyst IT -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Status|ASSIGNED|Needs Signoff -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #36 from Aleisha Amohia --- Created attachment 102335 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=102335=edit Bug 20844: (follow-up) SendLostHoldNotices This patch adds a new syspref SendLostHoldNotices Test: 1) Update database and restart memcached 2) Enable the SendLostHoldNotices system preference 3) Place a hold on an item 4) Check in the item and set the hold to waiting 5) Go to edit the item and set an item lost status 6) Check the borrower's notices and confirm the notice has been enqueued 7) Confirm the notice is not sent twice when reverting or cancelling the hold 8) Confirm notice enqueues as expected for a bib-level hold Sponsored-by: Catalyst IT -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Attachment #81710|0 |1 is obsolete|| Attachment #81711|0 |1 is obsolete|| Attachment #81712|0 |1 is obsolete|| --- Comment #35 from Aleisha Amohia --- Created attachment 102334 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=102334=edit Bug 20844: Revert or cancel lost holds This patch introduces the RevertLostBibLevelHolds syspref. When an item is marked as lost, if there is a bib-level hold on it waiting, the hold is reverted. If there is an item-level hold on it waiting, there is an alert box asking if the library would like to revert the hold or cancel it. Test: 1) Update database and restart memcached/plack 2) Place a hold on Biblio A 3) Check in Item A from Biblio A and set the hold as waiting 4) Edit Item A and give it a lost status (952$1, you may need to edit your MARC frameworks to have this visible in the Editor) 5) Look at your hold. Notice it is still waiting. 6) Go to Administration -> System preferences. Find the RevertLostBibLevelHolds system preference and enable it. 7) Cancel your hold and remove Item A's lost status. Place another biblio-level hold on the same biblio 8) Check in Item A from Biblio A and set the hold as waiting 9) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 10) Edit Item A and give it a lost status 11) Once the page reloads, go to view your hold. It should no longer be waiting and have no item allocated. 12) Cancel your hold and remove Item A's lost status. Place an item-level hold on Item A 13) Check in Item A and set the hold as waiting 14) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 15) Give Item A a lost status and save changes 16) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 17) Confirm your hold is no longer waiting, but the item is still allocated 18) Remove Item A's lost status 19) Check in Item A and set the hold as waiting 20) Go to the catalogue detail page for Biblio A (catalogue/detail.pl) and click 'Edit' for Item A (end up on cataloguing/additem.pl) 21) Give Item A a lost status and save changes 22) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 23) Confirm the hold is now cancelled 24) Remove Item A's lost status 25) Place an item-level hold on Item A 26) Check in Item A and set the hold as waiting 27) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 28) Give Item A a lost status and save changes 29) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Revert 30) Confirm your hold is no longer waiting, but the item is still allocated 31) Remove Item A's lost status 32) Check in Item A and set the hold as waiting 33) Go to the Items tab for Biblio A (catalogue/moredetail.pl) 34) Give Item A a lost status and save changes 35) Once the page reloads, confirm there is an alert box asking you to revert or cancel the hold. Click Cancel 36) Confirm the hold is now cancelled 37) Remove Item A's lost status 38) Place an item-level hold on Item A. Check in Item A and set the hold as waiting 39) Place an item-level hold on Item B (same biblio) for another borrower. Check in Item B and set the hold as waiting. 40) Give both Items A and B lost statuses. 41) Confirm that both Items are included in the alert box on page when editing items (cataloguing/additem.pl) 42) Confirm that both Items have individual alert boxes on the Items tab (catalogue/moredetail.pl) 43) Confirm tests pass t/db_dependent/Reserves.t Sponsored-by: Catalyst IT -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Status|In Discussion |ASSIGNED --- Comment #34 from Aleisha Amohia --- The code has moved on a bit since these patches were originally written. Will see if I can revive. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 David Cook changed: What|Removed |Added CC||dc...@prosentient.com.au --- Comment #33 from David Cook --- Ran into this problem as it was causing /usr/share/koha/bin/cronjobs/longoverdue.pl to seemingly randomly die when this patch is applied. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844
--- Comment #32 from David Cook ---
Comment on attachment 81710
--> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=81710
Bug 20844: Revert hold when setting an item to lost
Review of attachment 81710:
-->
(https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html=20844=81710)
-
::: C4/Circulation.pm
@@ +3688,5 @@
> +my $LostItemLevelHold;
> +if ( $restype eq "Waiting" || $restype eq "Reserved" ) {
> +if ( $res->{originalholdtype} eq "B" ) {
> +#originalholdtype equalling "B" means this is a bib level hold
> +C4::Reserves::RevertWaitingStatus({itemnumber => $itemnumber});
This line appears to be buggy. I haven't fully investigated, but if the hold
type is B, the itemnumber can't be used to look up the reserve, and eventually
causes a fatal error in _FixPriority (due to a lack of error handling in
RevertWaitingStatus, _FixPriority, etc.)
--
You are receiving this mail because:
You are watching all bug changes.
___
Koha-bugs mailing list
Koha-bugs@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Nick Clemens changed: What|Removed |Added CC||n...@bywatersolutions.com Depends on||9834 --- Comment #31 from Nick Clemens --- 9834 allows for manual reversion of hold to take original state of hold (item level vs next available) This should be adapted to use that code, or maybe that fix satisfies the requirements here? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9834 [Bug 9834] Reverting a waiting hold should lead to the former hold type (item or biblio level) -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Alex Buckley changed: What|Removed |Added Assignee|alexbuck...@catalyst.net.nz |alei...@catalyst.net.nz -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Aleisha Amohia changed: What|Removed |Added Status|ASSIGNED|In Discussion CC||alei...@catalyst.net.nz --- Comment #30 from Aleisha Amohia --- (In reply to Alex Buckley from comment #29) > > It would be good to have a consistent approach throughout Koha for dealing > with reserves on lost items. > > A question do you think it would be best to split this patch up so it is > only dealing with allocated (waiting) holds. This would alter the behavior > of the patches on the bug report which check for reserve type of 'waiting' > or 'reserved'. > > Then we would only need to add reserve handling to /tools/batchMod.pl as > longoverdue.pl and pendingreserves.pl don't touch waiting reserves. > > Amending longoverdue.pl and pendingreserves.pl could go in another bug > report building on this to handle un-allocated holds, just to prevent too > much scope creep on this bug report? > It would be great to have some feedback on this so we know what the next steps are. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Koha Team Lyon 3 changed: What|Removed |Added CC||k...@univ-lyon3.fr -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Bug 20844 depends on bug 21754, which changed state. Bug 21754 Summary: If an item is marked as lost, any outstanding transfers upon it should be automatically cancelled https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21754 What|Removed |Added Status|Pushed to Master|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Martin Renvoize changed: What|Removed |Added See Also||https://bugs.koha-community ||.org/bugzilla3/show_bug.cgi ||?id=21780 -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Martin Renvoize changed: What|Removed |Added Depends on||21754 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21754 [Bug 21754] If an item is marked as lost, any outstanding transfers upon it should be automatically cancelled -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Bug 20844 depends on bug 21732, which changed state. Bug 21732 Summary: If an item is marked as lost, any outstanding transfers upon it should be cancelled https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21732 What|Removed |Added Status|Needs Signoff |RESOLVED Resolution|--- |DUPLICATE -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #29 from Alex Buckley --- Hi Martin Thanks for your feedback. I have tested and looked through the code calls in /circ/pendingreserves.pl, /tools/batchMod.pl and misc/cronjobs/longoverdue.pl I have noticed they are not consistent in their current handling of the reserves on lost items. * /circ/pendingreserves.pl - This cancels non-waiting item level reserves when item is marked as lost. Doesn't show allocated (waiting) holds. * /tools/batchMod.pl - Doesn’t cancel item-level or allocated bib-level reserves. * /misc/cronjob/longoverdue.pl - Doesn't cancel non-waiting (un-allocated) reserves It would be good to have a consistent approach throughout Koha for dealing with reserves on lost items. A question do you think it would be best to split this patch up so it is only dealing with allocated (waiting) holds. This would alter the behavior of the patches on the bug report which check for reserve type of 'waiting' or 'reserved'. Then we would only need to add reserve handling to /tools/batchMod.pl as longoverdue.pl and pendingreserves.pl don't touch waiting reserves. Amending longoverdue.pl and pendingreserves.pl could go in another bug report building on this to handle un-allocated holds, just to prevent too much scope creep on this bug report? Cheers, Alex -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Alex Buckley changed: What|Removed |Added Status|Failed QA |ASSIGNED -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Martin Renvoize changed: What|Removed |Added Status|Signed Off |Failed QA --- Comment #28 from Martin Renvoize --- I'm afraid I'm not confident enough thought has been given to this regarding all the different ways an item can be marked as lost. /tools/batchMod.pl, circ/pendingreserves.pl and mist/cronjobs/longoverdue.pl all call LostItem and would need some level of handling for the new workflow which require user input. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Martin Renvoize changed: What|Removed |Added Attachment #81698|0 |1 is obsolete|| --- Comment #26 from Martin Renvoize --- Created attachment 81711 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=81711=edit Bug 20844: (follow-up) Fix style of dialogs This patch modifies the add item and item detail templates so that the hold cancellation dialogs match other similar dialogs in Koha. To test, apply the patch and perform step 10 or the original test plan. Confirm that the confirmation dialogs look correct. Confirmation dialogs look correct Signed-off-by: Alex Buckley Signed-off-by: Martin Renvoize -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Martin Renvoize changed: What|Removed |Added Attachment #81697|0 |1 is obsolete|| --- Comment #25 from Martin Renvoize --- Created attachment 81710 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=81710=edit Bug 20844: Revert hold when setting an item to lost If an item is marked as 'Lost' then this patch introduces the following new functionality: 1. Check if there is a bib-level or item-level hold on the item with the status of 'W' (waiting). This is an allocated hold which is not yet checked out to the requesting patron. 1.a. If the hold was originally a bib-level reserve (reserves.originalholdtype='B') then do the following: * Revert the waiting status of the reserve * Set the reserves.itemnumber=NULL so the hold is reset to a bib-level hold 1.b. If the hold was originally (and still is) a item-level hold (reserves.originalholdtype='I') then display a alert dialog box on the additem.pl interface asking the librarian to select one of two options: * Cancel the hold - This deletes the hold altogether * Retain the hold - This does not change the hold. Therefore the requester will still have a hold on a lost item NOTE: Previously an allocated bib-level hold was identical to a item-level hold in the database. As the first available item on the bib record had been allocated to the requester and so an itemnumber had been set in the record in the reserves table. However this patch introduces a atomicupdate which adds the new column 'originalholdtype' to the reserves table. This allows us to track if the reserve was originally a bib level hold and treat it differently when the allocated item is being marked as 'Lost' Test plan: 1. Place a bib-level hold on a biblio 2. Check out an item from the biblio to a different patron 3. Query the reserves db table for biblio you placed the bib-level hold and notice it has no 'itemnumber' or 'status' value 4. Return the item and confirm the hold in the modal box that is loaded 5. Query the reserves db table and notice the itemnumber field is now filled with the returned item's itemnumber and the status is 'W' 6. Set the item to 'Lost' either by clicking on Edit->Edit items from the detail.pl page OR clicking on the Items tab on the left side of the detail.pl page 7. Notice the waiting item-level hold still exists after the item is marked as 'lost' 8. Repeat steps 1-7 but this time place an item-level hold on an item in step 1 and then check that same item out in step 2. Notice in the repeated step 7 that the hold remains after marking the item as 'Lost' 9. Apply patch and run ./updatedatabase.pl from the koha-shell in the installer/data/mysql/ directory 9. Repeat steps 1-6 placing an bib-level hold and then query the database and notice the bib-level hold which was changed to an allocated waiting item-level hold when the item was returned and the hold confirmed is now reverted to a bib-level hold again. This is controlled by the LostBibLevelHoldsRevert syspref. If this syspref is not enabled then the allocated item-level (originally bib-level hold) will remain after the item is marked as lost. 10. Repeat 1-6 but this time place an item-level hold on the item. Notice when you mark the item as 'Lost' a yellow warning box is displayed asking if you want to 'Retain hold' or 'Cancel hold'. Select 'Retain hold' and notice the item-level hold remains now the item is marked as lost. 11. Repeat step 10 but choose 'Cancel hold' option and notice the hold is deleted now. 12. Now enable the new 'LostItemCancelOutstandingTransfers' syspref. This will now cancel any outstanding transfers on the item when it is marked as lost. 13. Find a item which is in transfer, i.e. find an item with the text in the 'Status' field of the table in detail.pl that indicates it is in transfer 14. Now mark that item as 'Lost' and now notice the transfer is cancelled 15. Go into koha-shell from the Koha home dir: sudo koha-shell 16. Run the RevertWaitingStatus.t test file: prove t/db_dependent/Holds/RevertWaitingStatus.t Sponsored-By: Brimbank Library, Australia Signed-off-by: Owen Leonard Signed-off-by: Martin Renvoize -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #27 from Martin Renvoize --- Created attachment 81712 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=81712=edit Bug 20884: (QA follow-up) Remove Data::Dumper Signed-off-by: Martin Renvoize -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Martin Renvoize changed: What|Removed |Added Keywords||Manual -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Martin Renvoize changed: What|Removed |Added Text to go in the|This enhancement gives |This enhancement gives release notes|librarians easier control |librarians easier control |over waiting holds when |over waiting holds when |items are marked as lost. |items are marked as lost. || |When an item with a waiting |When an item with a waiting |item-level hold on it is|item-level hold on it is |marked as lost the |marked as lost the |librarian is given the |librarian is given the |option to retain the hold |option to retain the hold |or to cancel it. |or to cancel it. | | |When a |When a |lost item has an allocated |lost item has an allocated |waiting bib-level hold on |waiting bib-level hold on |it then if the |it then if the |'LostBibLevelHoldsRevert' |'LostBibLevelHoldsRevert' |syspref is enabled then the |syspref is enabled then the |allocated hold is reverted |allocated hold is reverted |to an unallocated bib-level |to an unallocated bib-level |hold. |hold. | | |If the | |'LostItemCancelOutstandingT | |ransfers' syspref is| |enabled then any| |outstanding holds on the| |lost item are cancelled.| -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Martin Renvoize changed: What|Removed |Added CC||martin.renvoize@ptfs-europe ||.com QA Contact|testo...@bugs.koha-communit |martin.renvoize@ptfs-europe |y.org |.com --- Comment #24 from Martin Renvoize --- I've split this into two distinct bugs.. one for the enhancement details here and another for the included LostItem change which cleans up transfers as I count that as it's own bug. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Martin Renvoize changed: What|Removed |Added Attachment #81623|0 |1 is obsolete|| --- Comment #22 from Martin Renvoize --- Created attachment 81697 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=81697=edit Bug 20844: Revert hold when setting an item to lost If an item is marked as 'Lost' then this patch introduces the following new functionality: 1. Check if there is a bib-level or item-level hold on the item with the status of 'W' (waiting). This is an allocated hold which is not yet checked out to the requesting patron. 1.a. If the hold was originally a bib-level reserve (reserves.originalholdtype='B') then do the following: * Revert the waiting status of the reserve * Set the reserves.itemnumber=NULL so the hold is reset to a bib-level hold 1.b. If the hold was originally (and still is) a item-level hold (reserves.originalholdtype='I') then display a alert dialog box on the additem.pl interface asking the librarian to select one of two options: * Cancel the hold - This deletes the hold altogether * Retain the hold - This does not change the hold. Therefore the requester will still have a hold on a lost item NOTE: Previously an allocated bib-level hold was identical to a item-level hold in the database. As the first available item on the bib record had been allocated to the requester and so an itemnumber had been set in the record in the reserves table. However this patch introduces a atomicupdate which adds the new column 'originalholdtype' to the reserves table. This allows us to track if the reserve was originally a bib level hold and treat it differently when the allocated item is being marked as 'Lost' Test plan: 1. Place a bib-level hold on a biblio 2. Check out an item from the biblio to a different patron 3. Query the reserves db table for biblio you placed the bib-level hold and notice it has no 'itemnumber' or 'status' value 4. Return the item and confirm the hold in the modal box that is loaded 5. Query the reserves db table and notice the itemnumber field is now filled with the returned item's itemnumber and the status is 'W' 6. Set the item to 'Lost' either by clicking on Edit->Edit items from the detail.pl page OR clicking on the Items tab on the left side of the detail.pl page 7. Notice the waiting item-level hold still exists after the item is marked as 'lost' 8. Repeat steps 1-7 but this time place an item-level hold on an item in step 1 and then check that same item out in step 2. Notice in the repeated step 7 that the hold remains after marking the item as 'Lost' 9. Apply patch and run ./updatedatabase.pl from the koha-shell in the installer/data/mysql/ directory 9. Repeat steps 1-6 placing an bib-level hold and then query the database and notice the bib-level hold which was changed to an allocated waiting item-level hold when the item was returned and the hold confirmed is now reverted to a bib-level hold again. This is controlled by the LostBibLevelHoldsRevert syspref. If this syspref is not enabled then the allocated item-level (originally bib-level hold) will remain after the item is marked as lost. 10. Repeat 1-6 but this time place an item-level hold on the item. Notice when you mark the item as 'Lost' a yellow warning box is displayed asking if you want to 'Retain hold' or 'Cancel hold'. Select 'Retain hold' and notice the item-level hold remains now the item is marked as lost. 11. Repeat step 10 but choose 'Cancel hold' option and notice the hold is deleted now. 12. Now enable the new 'LostItemCancelOutstandingTransfers' syspref. This will now cancel any outstanding transfers on the item when it is marked as lost. 13. Find a item which is in transfer, i.e. find an item with the text in the 'Status' field of the table in detail.pl that indicates it is in transfer 14. Now mark that item as 'Lost' and now notice the transfer is cancelled 15. Go into koha-shell from the Koha home dir: sudo koha-shell 16. Run the RevertWaitingStatus.t test file: prove t/db_dependent/Holds/RevertWaitingStatus.t Sponsored-By: Brimbank Library, Australia Signed-off-by: Owen Leonard -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Martin Renvoize changed: What|Removed |Added Attachment #81640|0 |1 is obsolete|| --- Comment #23 from Martin Renvoize --- Created attachment 81698 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=81698=edit Bug 20844: (follow-up) Fix style of dialogs This patch modifies the add item and item detail templates so that the hold cancellation dialogs match other similar dialogs in Koha. To test, apply the patch and perform step 10 or the original test plan. Confirm that the confirmation dialogs look correct. Confirmation dialogs look correct Signed-off-by: Alex Buckley -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Martin Renvoize changed: What|Removed |Added Depends on||21732 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21732 [Bug 21732] If an item is marked as lost, any outstanding transfers upon it should be cancelled -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Alex Buckley changed: What|Removed |Added Text to go in the||This enhancement gives release notes||librarians easier control ||over waiting holds when ||items are marked as lost. || ||When an item with a waiting ||item-level hold on it is ||marked as lost the ||librarian is given the ||option to retain the hold ||or to cancel it. || ||When a ||lost item has an allocated ||waiting bib-level hold on ||it then if the ||'LostBibLevelHoldsRevert' ||syspref is enabled then the ||allocated hold is reverted ||to an unallocated bib-level ||hold. || ||If the ||'LostItemCancelOutstandingT ||ransfers' syspref is ||enabled then any ||outstanding holds on the ||lost item are cancelled. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Alex Buckley changed: What|Removed |Added Status|Needs Signoff |Signed Off --- Comment #21 from Alex Buckley --- Thanks Owen for testing my patch I have tested your follow-up and the dialogs look correct so I have signed off on it. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #20 from Alex Buckley --- Created attachment 81640 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=81640=edit Bug 20844: (follow-up) Fix style of dialogs This patch modifies the add item and item detail templates so that the hold cancellation dialogs match other similar dialogs in Koha. To test, apply the patch and perform step 10 or the original test plan. Confirm that the confirmation dialogs look correct. Confirmation dialogs look correct Signed-off-by: Alex Buckley -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Alex Buckley changed: What|Removed |Added Attachment #81624|0 |1 is obsolete|| -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Owen Leonard changed: What|Removed |Added Patch complexity|--- |Medium patch Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Owen Leonard changed: What|Removed |Added Status|Signed Off |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #19 from Owen Leonard --- Created attachment 81624 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=81624=edit Bug 20844: (follow-up) Fix style of dialogs This patch modifies the add item and item detail templates so that the hold cancellation dialogs match other similar dialogs in Koha. To test, apply the patch and perform step 10 or the original test plan. Confirm that the confirmation dialogs look correct. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Owen Leonard changed: What|Removed |Added Attachment #81531|0 |1 is obsolete|| --- Comment #18 from Owen Leonard --- Created attachment 81623 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=81623=edit Bug 20844: Revert hold when setting an item to lost If an item is marked as 'Lost' then this patch introduces the following new functionality: 1. Check if there is a bib-level or item-level hold on the item with the status of 'W' (waiting). This is an allocated hold which is not yet checked out to the requesting patron. 1.a. If the hold was originally a bib-level reserve (reserves.originalholdtype='B') then do the following: * Revert the waiting status of the reserve * Set the reserves.itemnumber=NULL so the hold is reset to a bib-level hold 1.b. If the hold was originally (and still is) a item-level hold (reserves.originalholdtype='I') then display a alert dialog box on the additem.pl interface asking the librarian to select one of two options: * Cancel the hold - This deletes the hold altogether * Retain the hold - This does not change the hold. Therefore the requester will still have a hold on a lost item NOTE: Previously an allocated bib-level hold was identical to a item-level hold in the database. As the first available item on the bib record had been allocated to the requester and so an itemnumber had been set in the record in the reserves table. However this patch introduces a atomicupdate which adds the new column 'originalholdtype' to the reserves table. This allows us to track if the reserve was originally a bib level hold and treat it differently when the allocated item is being marked as 'Lost' Test plan: 1. Place a bib-level hold on a biblio 2. Check out an item from the biblio to a different patron 3. Query the reserves db table for biblio you placed the bib-level hold and notice it has no 'itemnumber' or 'status' value 4. Return the item and confirm the hold in the modal box that is loaded 5. Query the reserves db table and notice the itemnumber field is now filled with the returned item's itemnumber and the status is 'W' 6. Set the item to 'Lost' either by clicking on Edit->Edit items from the detail.pl page OR clicking on the Items tab on the left side of the detail.pl page 7. Notice the waiting item-level hold still exists after the item is marked as 'lost' 8. Repeat steps 1-7 but this time place an item-level hold on an item in step 1 and then check that same item out in step 2. Notice in the repeated step 7 that the hold remains after marking the item as 'Lost' 9. Apply patch and run ./updatedatabase.pl from the koha-shell in the installer/data/mysql/ directory 9. Repeat steps 1-6 placing an bib-level hold and then query the database and notice the bib-level hold which was changed to an allocated waiting item-level hold when the item was returned and the hold confirmed is now reverted to a bib-level hold again. This is controlled by the LostBibLevelHoldsRevert syspref. If this syspref is not enabled then the allocated item-level (originally bib-level hold) will remain after the item is marked as lost. 10. Repeat 1-6 but this time place an item-level hold on the item. Notice when you mark the item as 'Lost' a yellow warning box is displayed asking if you want to 'Retain hold' or 'Cancel hold'. Select 'Retain hold' and notice the item-level hold remains now the item is marked as lost. 11. Repeat step 10 but choose 'Cancel hold' option and notice the hold is deleted now. 12. Now enable the new 'LostItemCancelOutstandingTransfers' syspref. This will now cancel any outstanding transfers on the item when it is marked as lost. 13. Find a item which is in transfer, i.e. find an item with the text in the 'Status' field of the table in detail.pl that indicates it is in transfer 14. Now mark that item as 'Lost' and now notice the transfer is cancelled 15. Go into koha-shell from the Koha home dir: sudo koha-shell 16. Run the RevertWaitingStatus.t test file: prove t/db_dependent/Holds/RevertWaitingStatus.t Sponsored-By: Brimbank Library, Australia Signed-off-by: Owen Leonard -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #17 from Alex Buckley --- Created attachment 81531 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=81531=edit Bug 20844: Revert hold when setting an item to lost If an item is marked as 'Lost' then this patch introduces the following new functionality: 1. Check if there is a bib-level or item-level hold on the item with the status of 'W' (waiting). This is an allocated hold which is not yet checked out to the requesting patron. 1.a. If the hold was originally a bib-level reserve (reserves.originalholdtype='B') then do the following: * Revert the waiting status of the reserve * Set the reserves.itemnumber=NULL so the hold is reset to a bib-level hold 1.b. If the hold was originally (and still is) a item-level hold (reserves.originalholdtype='I') then display a alert dialog box on the additem.pl interface asking the librarian to select one of two options: * Cancel the hold - This deletes the hold altogether * Retain the hold - This does not change the hold. Therefore the requester will still have a hold on a lost item NOTE: Previously an allocated bib-level hold was identical to a item-level hold in the database. As the first available item on the bib record had been allocated to the requester and so an itemnumber had been set in the record in the reserves table. However this patch introduces a atomicupdate which adds the new column 'originalholdtype' to the reserves table. This allows us to track if the reserve was originally a bib level hold and treat it differently when the allocated item is being marked as 'Lost' Test plan: 1. Place a bib-level hold on a biblio 2. Check out an item from the biblio to a different patron 3. Query the reserves db table for biblio you placed the bib-level hold and notice it has no 'itemnumber' or 'status' value 4. Return the item and confirm the hold in the modal box that is loaded 5. Query the reserves db table and notice the itemnumber field is now filled with the returned item's itemnumber and the status is 'W' 6. Set the item to 'Lost' either by clicking on Edit->Edit items from the detail.pl page OR clicking on the Items tab on the left side of the detail.pl page 7. Notice the waiting item-level hold still exists after the item is marked as 'lost' 8. Repeat steps 1-7 but this time place an item-level hold on an item in step 1 and then check that same item out in step 2. Notice in the repeated step 7 that the hold remains after marking the item as 'Lost' 9. Apply patch and run ./updatedatabase.pl from the koha-shell in the installer/data/mysql/ directory 9. Repeat steps 1-6 placing an bib-level hold and then query the database and notice the bib-level hold which was changed to an allocated waiting item-level hold when the item was returned and the hold confirmed is now reverted to a bib-level hold again. This is controlled by the LostBibLevelHoldsRevert syspref. If this syspref is not enabled then the allocated item-level (originally bib-level hold) will remain after the item is marked as lost. 10. Repeat 1-6 but this time place an item-level hold on the item. Notice when you mark the item as 'Lost' a yellow warning box is displayed asking if you want to 'Retain hold' or 'Cancel hold'. Select 'Retain hold' and notice the item-level hold remains now the item is marked as lost. 11. Repeat step 10 but choose 'Cancel hold' option and notice the hold is deleted now. 12. Now enable the new 'LostItemCancelOutstandingTransfers' syspref. This will now cancel any outstanding transfers on the item when it is marked as lost. 13. Find a item which is in transfer, i.e. find an item with the text in the 'Status' field of the table in detail.pl that indicates it is in transfer 14. Now mark that item as 'Lost' and now notice the transfer is cancelled 15. Go into koha-shell from the Koha home dir: sudo koha-shell 16. Run the RevertWaitingStatus.t test file: prove t/db_dependent/Holds/RevertWaitingStatus.t Sponsored-By: Brimbank Library, Australia -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Alex Buckley changed: What|Removed |Added Attachment #81045|0 |1 is obsolete|| -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #16 from Alex Buckley --- With the feature freeze coming up very soon are we able to get this moving along with testing? -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #15 from Alex Buckley --- Apologies that should be 'Hi Michal' -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Alex Buckley changed: What|Removed |Added Status|Failed QA |Needs Signoff --- Comment #14 from Alex Buckley --- Hi Michael Thanks for testing. Can you please try testing now using the test plan in the patch I have just attached. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #13 from Alex Buckley --- Created attachment 81045 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=81045=edit Bug 20844: Revert hold when setting an item to lost If an item is marked as 'Lost' then this patch introduces the following new functionality: 1. Check if there is a bib-level or item-level hold on the item with the status of 'W' (waiting). This is an allocated hold which is not yet checked out to the requesting patron. 1.a. If the hold was originally a bib-level reserve (reserves.originalholdtype='B') then do the following: * Revert the waiting status of the reserve * Set the reserves.itemnumber=NULL so the hold is reset to a bib-level hold 1.b. If the hold was originally (and still is) a item-level hold (reserves.originalholdtype='I') then display a alert dialog box on the additem.pl interface asking the librarian to select one of two options: * Cancel the hold - This deletes the hold altogether * Retain the hold - This does not change the hold. Therefore the requester will still have a hold on a lost item NOTE: Previously an allocated bib-level hold was identical to a item-level hold in the database. As the first available item on the bib record had been allocated to the requester and so an itemnumber had been set in the record in the reserves table. However this patch introduces a atomicupdate which adds the new column 'originalholdtype' to the reserves table. This allows us to track if the reserve was originally a bib level hold and treat it differently when the allocated item is being marked as 'Lost' Test plan: 1. Place a bib-level hold on a biblio 2. Check out an item from the biblio to a different patron 3. Query the reserves db table for biblio you placed the bib-level hold and notice it has no 'itemnumber' or 'status' value 4. Return the item and confirm the hold in the modal box that is loaded 5. Query the reserves db table and notice the itemnumber field is now filled with the returned item's itemnumber and the status is 'W' 6. Set the item to 'Lost' either by clicking on Edit->Edit items from the detail.pl page OR clicking on the Items tab on the left side of the detail.pl page 7. Notice the waiting item-level hold still exists after the item is marked as 'lost' 8. Repeat steps 1-7 but this time place an item-level hold on an item in step 1 and then check that same item out in step 2. Notice in the repeated step 7 that the hold remains after marking the item as 'Lost' 9. Apply patch and run ./updatedatabase.pl from the koha-shell in the installer/data/mysql/ directory 9. Repeat steps 1-6 placing an bib-level hold and then query the database and notice the bib-level hold which was changed to an allocated waiting item-level hold when the item was returned and the hold confirmed is now reverted to a bib-level hold again. This is controlled by the LostBibLevelHoldsRevert syspref. If this syspref is not enabled then the allocated item-level (originally bib-level hold) will remain after the item is marked as lost. 10. Repeat 1-6 but this time place an item-level hold on the item. Notice when you mark the item as 'Lost' a yellow warning box is displayed asking if you want to 'Retain hold' or 'Cancel hold'. Select 'Retain hold' and notice the item-level hold remains now the item is marked as lost. 11. Repeat step 10 but choose 'Cancel hold' option and notice the hold is deleted now. 12. Now enable the new 'LostItemCancelOutstandingTransfers' syspref. This will now cancel any outstanding transfers on the item when it is marked as lost. 13. Find a item which is in transfer, i.e. find an item with the text in the 'Status' field of the table in detail.pl that indicates it is in transfer 14. Now mark that item as 'Lost' and now notice the transfer is cancelled 15. Go into koha-shell from the Koha home dir: sudo koha-shell 16. Run the RevertWaitingStatus.t test file: prove t/db_dependent/Holds/RevertWaitingStatus.t Sponsored-By: Brimbank Library, Australia -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Alex Buckley changed: What|Removed |Added Attachment #80891|0 |1 is obsolete|| -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Alex Buckley changed: What|Removed |Added Attachment #80760|0 |1 is obsolete|| -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Alex Buckley changed: What|Removed |Added Attachment #80890|0 |1 is obsolete|| -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Michal Denar changed: What|Removed |Added CC||blac...@gmail.com Status|Needs Signoff |Failed QA --- Comment #12 from Michal Denar --- Hi, on kohadevbox I get: kohadev-koha@kohadevbox:/home/vagrant/kohaclone$ prove t/db_dependent/Holds/RevertWaitingStatus.t t/db_dependent/Holds/RevertWaitingStatus.t .. DBD::mysql::st execute failed: Unknown column 'originalholdtype' in 'field list' [for Statement "INSERT INTO `reserves` ( `biblionumber`, `borrowernumber`, `branchcode`, `expirationdate`, `found`, `itemnumber`, `itemtype`, `originalholdtype`, `priority`, `reservedate`, `reservenotes`, `waitingdate`) VALUES ( ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ? )" with ParamValues: 0='439', 1='53', 2='YbGPVdI', 3=undef, 4=undef, 5=undef, 6=undef, 7='B', 8=undef, 9='2018-10-19', 10='', 11=undef] at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1836. Can't locate object method "rethrow" via package "DBD::mysql::st execute failed: Unknown column 'originalholdtype' in 'field list' [for Statement "INSERT INTO `reserves` ( `biblionumber`, `borrowernumber`, `branchcode`, `expirationdate`, `found`, `itemnumber`, `itemtype`, `originalholdtype`, `priority`, `reservedate`, `reservenotes`, `waitingdate`) VALUES ( ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ? )" with ParamValues: 0='439', 1='53', 2='YbGPVdI', 3=undef, 4=undef, 5=undef, 6=undef, 7='B', 8=undef, 9='2018-10-19', 10='', 11=undef] at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1836. " (perhaps you forgot to load "DBD::mysql::st execute failed: Unknown column 'originalholdtype' in 'field list' [for Statement "INSERT INTO `reserves` ( `biblionumber`, `borrowernumber`, `branchcode`, `expirationdate`, `found`, `itemnumber`, `itemtype`, `originalholdtype`, `priority`, `reservedate`, `reservenotes`, `waitingdate`) VALUES ( ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ? )" with ParamValues: 0='439', 1='53', 2='YbGPVdI', 3=undef, 4=undef, 5=undef, 6=undef, 7='B', 8=undef, 9='2018-10-19', 10='', 11=undef] at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1836. "?) at /home/vagrant/kohaclone/Koha/Object.pm line 148. # Looks like your test exited with 11 before it could output anything. t/db_dependent/Holds/RevertWaitingStatus.t .. Dubious, test returned 11 (wstat 2816, 0xb00) Failed 12/12 subtests -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Alex Buckley changed: What|Removed |Added CC||oleon...@myacpl.org -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #11 from Alex Buckley --- Hi all I've added unit tests for the two new subroutines I added to C4/Reserves.pm which were RevertWaitingStatus() and RevertItemLevelHoldToBibLevelHold(). Also all three patches pass the QA test tool now. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #10 from Alex Buckley --- Created attachment 80891 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=80891=edit Bug 20844: Added tests of the RevertWaitingStatus and RevertItemLevelHoldToBibLevelHold subroutines in C4/Reserves.pm I have added unit tests for the two aforementioned subroutines which I added in the previous patches on bug 20844, to the t/db_dependent/Holds/RevertWaitingStatus.t test. Test plan: 1. Apply the patches on bug 20844 2. Go into koha-shell from the Koha home dir: sudo koha-shell 3. Run the RevertWaitingStatus.t test file: prove t/db_dependent/Holds/RevertWaitingStatus.t Sponsored-By: Brimbank Library, Australia -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #9 from Alex Buckley --- Created attachment 80890 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=80890=edit Bug 20844: Fixed error when cancelling hold from cataloguing/additem.pl Also fixed qa test tool failure on C4/Circulation.pm Sponsored-By: Brimbank Library, Australia -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Alex Buckley changed: What|Removed |Added Attachment #80761|0 |1 is obsolete|| -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Alex Buckley changed: What|Removed |Added Status|Failed QA |Needs Signoff --- Comment #8 from Alex Buckley --- Hi Owen Thanks for testing. I have corrected the commit message in the first patch, and have just attached a second path which corrects the issue you saw trying to cancel a hold on the cataloguing/additem.pl interface. This second patch also corrects the qa warning on C4/Circulation.pm Can you please test again? Cheers, Alex -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #7 from Alex Buckley --- Created attachment 80761 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=80761=edit Bug 20844: Fixed error when cancelling hold from cataloguing/additem.pl Also fixed qa test tool failure on C4/Circulation.pm Sponsored-By: Brimbank Library, Australia -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #6 from Alex Buckley --- Created attachment 80760 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=80760=edit Bug 20844: Revert hold when setting an item to lost If an item is marked as 'Lost' then this patch introduces the following new functionality: 1. Check if there is a bib-level or item-level hold on the item with the status of 'W' (waiting). This is an allocated hold which is not yet checked out to the requesting patron. 1.a. If the hold was originally a bib-level reserve (reserves.originalholdtype='B') then do the following: * Revert the waiting status of the reserve * Set the reserves.itemnumber=NULL so the hold is reset to a bib-level hold 1.b. If the hold was originally (and still is) a item-level hold (reserves.originalholdtype='I') then display a alert dialog box on the additem.pl interface asking the librarian to select one of two options: * Cancel the hold - This deletes the hold altogether * Retain the hold - This does not change the hold. Therefore the requester will still have a hold on a lost item NOTE: Previously an allocated bib-level hold was identical to a item-level hold in the database. As the first available item on the bib record had been allocated to the requester and so an itemnumber had been set in the record in the reserves table. However this patch introduces a atomicupdate which adds the new column 'originalholdtype' to the reserves table. This allows us to track if the reserve was originally a bib level hold and treat it differently when the allocated item is being marked as 'Lost' Test plan: 1. Place a bib-level hold on a biblio 2. Check out an item from the biblio to a different patron 3. Query the reserves db table for biblio you placed the bib-level hold and notice it has no 'itemnumber' or 'status' value 4. Return the item and confirm the hold in the modal box that is loaded 5. Query the reserves db table and notice the itemnumber field is now filled with the returned item's itemnumber and the status is 'W' 6. Set the item to 'Lost' either by clicking on Edit->Edit items from the detail.pl page OR clicking on the Items tab on the left side of the detail.pl page 7. Notice the waiting item-level hold still exists after the item is marked as 'lost' 8. Repeat steps 1-7 but this time place an item-level hold on an item in step 1 and then check that same item out in step 2. Notice in the repeated step 7 that the hold remains after marking the item as 'Lost' 9. Apply patch and run ./updatedatabase.pl from the koha-shell in the installer/data/mysql/ directory 9. Repeat steps 1-6 placing an bib-level hold and then query the database and notice the bib-level hold which was changed to an allocated waiting item-level hold when the item was returned and the hold confirmed is now reverted to a bib-level hold again. This is controlled by the LostBibLevelHoldsRevert syspref. If this syspref is not enabled then the allocated item-level (originally bib-level hold) will remain after the item is marked as lost. 10. Repeat 1-6 but this time place an item-level hold on the item. Notice when you mark the item as 'Lost' a yellow warning box is displayed asking if you want to 'Retain hold' or 'Cancel hold'. Select 'Retain hold' and notice the item-level hold remains now the item is marked as lost. 11. Repeat step 10 but choose 'Cancel hold' option and notice the hold is deleted now. 12. Now enable the new 'LostItemCancelOutstandingTransfers' syspref. This will now cancel any outstanding transfers on the item when it is marked as lost. 13. Find a item which is in transfer, i.e. find an item with the text in the 'Status' field of the table in detail.pl that indicates it is in transfer 14. Now mark that item as 'Lost' and now notice the transfer is cancelled Sponsored-By: Brimbank Library, Australia -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
