Someone added a new modal for holds/transfers in return.tt (yay!). They left the old dialog in the background, and if you ignore the modal, it remains. To replicate: 1) Place a hold on an item from Branch A to be delivered to Branch B. 2) Checkin in the item at Branch A and confirm the hold to transfer. 3) Be human and make a mistake. Login as Branch C and check the item in. 4) Note the great modal to redirect the hold. Note that the old dialog is behind it!
Created attachment 78724 [details] [review] [PATCH] Bug 21346: Remove old hold/transfer dialog TO TEST: 1) Place a hold on an item from Branch A to be delivered to Branch B. 2) Checkin the item at Branch A and confirm the hold to transfer. 3) Be human and make a mistake. Login as Branch C and check the item in. 4) Note the great modal to redirect the hold. Note that the old dialog is behind it! 5) Apply the patch. 6) Repeat step 3. Now note that the old dialog is no longer on the page.
Created attachment 78726 [details] [review] Bug 21346: Remove old hold/transfer dialog TO TEST: 1) Place a hold on an item from Branch A to be delivered to Branch B. 2) Checkin the item at Branch A and confirm the hold to transfer. 3) Be human and make a mistake. Login as Branch C and check the item in. 4) Note the great modal to redirect the hold. Note that the old dialog is behind it! 5) Apply the patch. 6) Repeat step 3. Now note that the old dialog is no longer on the page. Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
I found that this broke something else. Back to the drawing board!
I managed to fix the patch AND fix the bug with the waiting holds being checked in at the wrong location that do nothing! Test plan to come.
Created attachment 78902 [details] [review] Bug 21346: Update/Fix dialogs - Fix hold waiting TEST PLAN 1) Place a hold on an item from Branch A to be delivered to Branch B. 2) Checkin the item at Branch A and confifm the hold to transfer. 3) Be human and make a mistake. Login as Branch C and check the item in 4) Note the great modal to redirect the hold. Note that the old dialog is behind it! 5) Check in the item at Branch B to put it in waiting status. 6) Be human and make another mistake. Login as Branch C and check the item in. Notice it does nothing except a local hold. 7) Check out an item at Branch A. 8) Check in the item at Branch B. Notice the classic blue transfer dialog at the top of page. 9) Apply the patch. 10) Check everything in at their branches. 11) Repeat steps 1-8. Now note the classic dialogs are gone and nothing but the modals left. Note that the waiting hold will now reroute back the place it should be waiting.
Everything is functional- however when an item is checked in to transfer back to its home branch (not on hold) there is no confirm option- only a force to print a slip. WE don't print slips for non-hold transfers. If that scenario offered a simple "confirm" choice, it would work well.
Created attachment 78915 [details] [review] Bug 21346: Update buttons on transfer only Added a confirm only button and updated text on print button for the transfer dialog so you are not forced to print.
Added button per Spencer's suggestion. Thanks for testing! Please try again.
Created attachment 78916 [details] [review] Bug 21346: Update buttons on transfer only Added a confirm only button and updated text on print button for the transfer dialog so you are not forced to print. Signed-off-by: Spencer <ssmith3@mckinneytexas.org>
*** Bug 17339 has been marked as a duplicate of this bug. ***
(In reply to ByWater Sandboxes from comment #9) > Created attachment 78916 [details] [review] [review] > Bug 21346: Update buttons on transfer only > > Added a confirm only button and updated text on print button for the > transfer dialog so you are not forced to print. > > Signed-off-by: Spencer <ssmith3@mckinneytexas.org> Spencer, when signing off, if there is more than one patch involved, you need to sign off on the whole thing, not just a single patch. Have Ed show you how. :)
Created attachment 78942 [details] [review] Bug 21346: Update/Fix dialogs - Fix hold waiting TEST PLAN 1) Place a hold on an item from Branch A to be delivered to Branch B. 2) Checkin the item at Branch A and confifm the hold to transfer. 3) Be human and make a mistake. Login as Branch C and check the item in 4) Note the great modal to redirect the hold. Note that the old dialog is behind it! 5) Check in the item at Branch B to put it in waiting status. 6) Be human and make another mistake. Login as Branch C and check the item in. Notice it does nothing except a local hold. 7) Check out an item at Branch A. 8) Check in the item at Branch B. Notice the classic blue transfer dialog at the top of page. 9) Apply the patch. 10) Check everything in at their branches. 11) Repeat steps 1-8. Now note the classic dialogs are gone and nothing but the modals left. Note that the waiting hold will now reroute back the place it should be waiting. Signed-off-by: Fred King <fred.king@medstar.net>
Created attachment 78943 [details] [review] Bug 21346: Update buttons on transfer only Added a confirm only button and updated text on print button for the transfer dialog so you are not forced to print. Signed-off-by: Spencer <ssmith3@mckinneytexas.org> Signed-off-by: Fred King <fred.king@medstar.net>
*** Bug 13153 has been marked as a duplicate of this bug. ***
*** Bug 19720 has been marked as a duplicate of this bug. ***
This is bugfix, not an enhancement, right? I would suggest to provide a patch which would not contain the indentation changes, that will generate conflicts and make the backport harder.
(In reply to Jonathan Druart from comment #16) > This is bugfix, not an enhancement, right? > I would suggest to provide a patch which would not contain the indentation > changes, that will generate conflicts and make the backport harder. It is both. Please explain. I don't understand the issue.
(In reply to Christopher Brannon from comment #17) > (In reply to Jonathan Druart from comment #16) > > This is bugfix, not an enhancement, right? > > I would suggest to provide a patch which would not contain the indentation > > changes, that will generate conflicts and make the backport harder. > > It is both. Please explain. I don't understand the issue. Never mind. I think I understand.
Created attachment 79685 [details] [review] Bug 21346: Update/Fix dialogs - Fix hold waiting TEST PLAN 1) Place a hold on an item from Branch A to be delivered to Branch B. 2) Checkin the item at Branch A and confifm the hold to transfer. 3) Be human and make a mistake. Login as Branch C and check the item in 4) Note the great modal to redirect the hold. Note that the old dialog is behind it! 5) Check in the item at Branch B to put it in waiting status. 6) Be human and make another mistake. Login as Branch C and check the item in. Notice it does nothing except a local hold. 7) Check out an item at Branch A. 8) Check in the item at Branch B. Notice the classic blue transfer dialog at the top of page. 9) Apply the patch. 10) Check everything in at their branches. 11) Repeat steps 1-8. Now note the classic dialogs are gone and nothing but the modals left. Note that the waiting hold will now reroute back the place it should be waiting.
Resubmitted patch, removing indent changes per request and combined patches. No new code.
Created attachment 79686 [details] [review] Bug 21346: Update/Fix dialogs - Fix hold waiting TEST PLAN 1) Place a hold on an item from Branch A to be delivered to Branch B. 2) Checkin the item at Branch A and confifm the hold to transfer. 3) Be human and make a mistake. Login as Branch C and check the item in 4) Note the great modal to redirect the hold. Note that the old dialog is behind it! 5) Check in the item at Branch B to put it in waiting status. 6) Be human and make another mistake. Login as Branch C and check the item in. Notice it does nothing except a local use. 7) Check out an item at Branch A. 8) Check in the item at Branch B. Notice the classic blue transfer dialog at the top of page. 9) Apply the patch. 10) Check everything in at their branches. 11) Repeat steps 1-8. Now note the classic dialogs are gone and nothing but the modals left. Note that the waiting hold will now reroute back the place it should be waiting.
Fixed typo in plan. We should be good now.
Found a logic problem. Hold-found2 modal triggering on top of hold-found1 modal if you check an item that is already waiting at that location. I will go in and update the logic to not show hold-found2 modal if waiting. I will put this back to needs sign-off when complete.
Created attachment 80879 [details] [review] Bug 21346: Fixes dual modals on waiting hold.
I've isolated the flaw. We are good to go again. Test plan remains the same. I will also submit a patch to clean up the tabs.
Changing this to a bug fix, as it fixes dialog issues and a known bug. Not really adding anything new in terms of features.
Found another issue. While I have fixed the routing issue, an item marked waiting and turned in to the wrong branch will re-route the item correctly, but does not set the item back to top priority. Looking into this. Failing for now.
Created attachment 81100 [details] [review] Bug 21346: Restore values needed for buttons
I am going to revamp this bug, once again. There are some other issues at hand that need to be done to handle this more appropriately: * I will be mapping out hold and transfer behaviors * Clean up some logic - some of it is a bit cobbled together: For example, found is used specificly when a hold is found, but has been used for some simple transfers as well. * Clarify some variables - found is too generic * Add a routine for correcting waiting holds - there is no current method for reverting a hold from waiting to in transit in returns. * Finish converting dialogs to modals.
Created attachment 81836 [details] [review] Bug 21346: Streamline logic in holds and transfers 1) Replaced comparison with string to make testing branch easier. 2) Replaced useless 0 values with undef. Does not change any behavior, only simplifies code.
Created attachment 81853 [details] [review] Bug 21346: Remove double dialog To Test: 1) Place a hold on an item for pickup at another branch. 2) Check in item to trigger hold and transfer. 3) Check in item again without changing location. Note modal AND old dialog behind modal. 4) Apply patch. 5) Check in item again without changing location. Note modal without the old dialog.
Created attachment 81921 [details] [review] Bug 21346: Convert dialogs to modals This addresses most of the transfer dialogs. There are some dialogs that I have not converted because I don't know what triggers them, therefore I cannot test them. The following scenarios have been addresses, and should be tested: FOR TRANSFERS 1) Checkin with no issue, hold or transfer; not at home (AutomaticItemReturn set to Don't) * Should give 3 options - Yes, Yes with print, or No. * Yes and Yes with print should trigger a transfer back home. * No should do nothing. * Print should open a window for printing, with correct information. * All three options should close the modal. TO TEST: 1) Set AutomaticItemREturn to Don't. 2) Check in an item with no issues, holds or transfers set, at a location other than the owning library. 3) Test conditions above. 2) Checkin with no issue, hold or transfer; not at home (AutomaticItemReturn set to Do) * Should give 2 options - Print or OK. * Should automatically set transfer. * Print should open a window for printing, with correct information. * Both buttons should close modal. TO TEST: 1) Set AutomaticItemReturn to Do. 2) Check in an item with no issues, holds or transfers set, at a location other than the owning library. 3) Test conditions above. 3) Checkin with no issues or holds, but transfer already set * Should give 3 options - OK, Print or Cancel. * OK and print should not touch existing transfer. * Cancel should remove the exisiting transfer. * Print should open a window for printing, with correct information. * All three options should close the modal. TO TEST: 1) Check in an item following step 2 of either test above. 2) Check in item again, while a transfer exists. 3) Test conditions above. WRONG BRANCH 4) If AllowReturnToBranch is not set "to any library", and the item is not checked in at the appropriate branch, the wrong-branch-modal pops up: * Should give 1 option - OK. * Should not check anything in or initiate a transfer. * OK should close the modal. TO TEST: 1) Set AllowReturnToBranch to "only the library the item is from". You can test the other settings, as long as you pay attention to where you are checking the item in at. 2) Check in an item at a branch other than the owning library. 3) Test conditions above.
Okay, patches for cleanup are set. Now addressing the waiting hold at the wrong location. It must: * Bring up a modal. * Only prompt to send the item to the pickup location. * Update current location in item. * Initiate a transfer. * Update the reserve from a W to T in the found field. * Remove the waiting date in the reserves.
Created attachment 81924 [details] [review] Bug 21346: Convert dialogs to modals. This addresses most of the transfer dialogs. There are some dialogs that I have not converted because I don't know what triggers them, therefore I cannot test them. The following scenarios have been addresses, and should be tested: FOR TRANSFERS 1) Checkin with no issue, hold or transfer; not at home (AutomaticItemReturn set to Don't) * Should give 3 options - Yes, Yes with print, or No. * Yes and Yes with print should trigger a transfer back home. * No should do nothing. * Print should open a window for printing, with correct information. * All three options should close the modal. TO TEST: 1) Set AutomaticItemREturn to Don't. 2) Check in an item with no issues, holds or transfers set, at a location other than the owning library. 3) Test conditions above. 2) Checkin with no issue, hold or transfer; not at home (AutomaticItemReturn set to Do) * Should give 2 options - Print or OK. * Should automatically set transfer. * Print should open a window for printing, with correct information. * Both buttons should close modal. TO TEST: 1) Set AutomaticItemReturn to Do. 2) Check in an item with no issues, holds or transfers set, at a location other than the owning library. 3) Test conditions above. 3) Checkin with no issues or holds, but transfer already set * Should give 3 options - OK, Print or Cancel. * OK and print should not touch existing transfer. * Cancel should remove the exisiting transfer. * Print should open a window for printing, with correct information. * All three options should close the modal. TO TEST: 1) Check in an item following step 2 of either test above. 2) Check in item again, while a transfer exists. 3) Test conditions above. WRONG BRANCH 4) If AllowReturnToBranch is not set "to any library", and the item is not checked in at the appropriate branch, the wrong-branch-modal pops up: * Should give 1 option - OK. * Should not check anything in or initiate a transfer. * OK should close the modal. TO TEST: 1) Set AllowReturnToBranch to "only the library the item is from". You can test the other settings, as long as you pay attention to where you are checking the item in at. 2) Check in an item at a branch other than the owning library. 3) Test conditions above.
Created attachment 82049 [details] [review] Bug 21346: Reroute waiting hold from wrong branch To Test: 1) Place a hold on an item. 2) Check in the item to trigger the hold. Item is now listed as waiting. 3) Set branch to a different library. 4) Check in the item to trigger the hold. Notice that nothing but a local use is recorded. 5) Apply the patch. 6) Repeat steps 1-4. Notice that the hold is triggered around routed to its original pickup location. A transfer is set and the hold status is changed from waiting to correctly showing the item as in transit.
Finally. I think this was the best approach. Sorry for the number of changes. If someone thinks I need to create a test for the modification to C4/Circulation.pm, I can try to do that to.
*** Bug 18490 has been marked as a duplicate of this bug. ***
Created attachment 82189 [details] [review] Bug 21346: Streamline logic in holds and transfers 1) Replaced comparison with string to make testing branch easier. 2) Replaced useless 0 values with undef. Does not change any behavior, only simplifies code. Signed-off-by: Lisette <lisetteslatah@gmail.com>
Created attachment 82190 [details] [review] Bug 21346: Remove double dialog To Test: 1) Place a hold on an item for pickup at another branch. 2) Check in item to trigger hold and transfer. 3) Check in item again without changing location. Note modal AND old dialog behind modal. 4) Apply patch. 5) Check in item again without changing location. Note modal without the old dialog. Signed-off-by: Lisette <lisetteslatah@gmail.com>
Created attachment 82191 [details] [review] Bug 21346: Convert dialogs to modals. This addresses most of the transfer dialogs. There are some dialogs that I have not converted because I don't know what triggers them, therefore I cannot test them. The following scenarios have been addresses, and should be tested: FOR TRANSFERS 1) Checkin with no issue, hold or transfer; not at home (AutomaticItemReturn set to Don't) * Should give 3 options - Yes, Yes with print, or No. * Yes and Yes with print should trigger a transfer back home. * No should do nothing. * Print should open a window for printing, with correct information. * All three options should close the modal. TO TEST: 1) Set AutomaticItemREturn to Don't. 2) Check in an item with no issues, holds or transfers set, at a location other than the owning library. 3) Test conditions above. 2) Checkin with no issue, hold or transfer; not at home (AutomaticItemReturn set to Do) * Should give 2 options - Print or OK. * Should automatically set transfer. * Print should open a window for printing, with correct information. * Both buttons should close modal. TO TEST: 1) Set AutomaticItemReturn to Do. 2) Check in an item with no issues, holds or transfers set, at a location other than the owning library. 3) Test conditions above. 3) Checkin with no issues or holds, but transfer already set * Should give 3 options - OK, Print or Cancel. * OK and print should not touch existing transfer. * Cancel should remove the exisiting transfer. * Print should open a window for printing, with correct information. * All three options should close the modal. TO TEST: 1) Check in an item following step 2 of either test above. 2) Check in item again, while a transfer exists. 3) Test conditions above. WRONG BRANCH 4) If AllowReturnToBranch is not set "to any library", and the item is not checked in at the appropriate branch, the wrong-branch-modal pops up: * Should give 1 option - OK. * Should not check anything in or initiate a transfer. * OK should close the modal. TO TEST: 1) Set AllowReturnToBranch to "only the library the item is from". You can test the other settings, as long as you pay attention to where you are checking the item in at. 2) Check in an item at a branch other than the owning library. 3) Test conditions above. Signed-off-by: Lisette <lisetteslatah@gmail.com>
Created attachment 82192 [details] [review] Bug 21346: Reroute waiting hold from wrong branch To Test: 1) Place a hold on an item. 2) Check in the item to trigger the hold. Item is now listed as waiting. 3) Set branch to a different library. 4) Check in the item to trigger the hold. Notice that nothing but a local use is recorded. 5) Apply the patch. 6) Repeat steps 1-4. Notice that the hold is triggered around routed to its original pickup location. A transfer is set and the hold status is changed from waiting to correctly showing the item as in transit. Signed-off-by: Lisette <lisetteslatah@gmail.com>
Overall it looks good, just one thing - please don't use inline javascript (onclick="...") And could you please separate the fix for rerouting wating hold to its own bug report?
(In reply to Josef Moravec from comment #42) > > And could you please separate the fix for rerouting wating hold to its own > bug report? And it would be nice to have regression test here...
(In reply to Josef Moravec from comment #43) > (In reply to Josef Moravec from comment #42) > > > > And could you please separate the fix for rerouting wating hold to its own > > bug report? > > And it would be nice to have regression test here... I don't know what that is.
Ignore. Everyone calls it something different. Okay. The waiting patch is on bug 21944. I will add the test there. Since nothing else involves a pm here, I am setting this back to signed off.
(In reply to Josef Moravec from comment #42) > Overall it looks good, just one thing - please don't use inline javascript > (onclick="...") Please, fix this.
(In reply to Christopher Brannon from comment #45) > Ignore. Everyone calls it something different. Okay. The waiting patch is > on bug 21944. I will add the test there. Since nothing else involves a pm > here, I am setting this back to signed off. I'm not native speaker, so maybe I'm sometimes not using the right words, sorry ;) Good job
Created attachment 82891 [details] [review] Bug 21346: Remove inline onclicks per comment 42 To test: 1) Apply patch. 2) Check that there is no changed behavior with buttons or checkboxes.
(In reply to Josef Moravec from comment #46) > (In reply to Josef Moravec from comment #42) > > Overall it looks good, just one thing - please don't use inline javascript > > (onclick="...") > > > Please, fix this. Done. Waiting for sign off.
Lisette, when you get a chance, would you test again. Make sure there are no differences with buttons or checkboxes. Thanks! Christopher
Comment on attachment 82891 [details] [review] Bug 21346: Remove inline onclicks per comment 42 Review of attachment 82891 [details] [review]: ----------------------------------------------------------------- ::: koha-tmpl/intranet-tmpl/prog/en/modules/circ/returns.tt @@ +672,2 @@ > [% ELSE %] > + <input type="checkbox" id="return_date_override_remember" name="return_date_override_remember" /> While the code below actually fixes some of the inline javascript that you corrected, I don't see anything that is the equivalent of forcing the focus to barcode for this. I'll look at the full file to confirm if there is something already.
Mark, Does this qualify as a FQA for you? Cheers, Liz
Created attachment 87625 [details] [review] Bug 21346: Streamline logic in holds and transfers 1) Replaced comparison with string to make testing branch easier. 2) Replaced useless 0 values with undef. Does not change any behavior, only simplifies code. Signed-off-by: Lisette <lisetteslatah@gmail.com> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Created attachment 87626 [details] [review] Bug 21346: Remove double dialog To Test: 1) Place a hold on an item for pickup at another branch. 2) Check in item to trigger hold and transfer. 3) Check in item again without changing location. Note modal AND old dialog behind modal. 4) Apply patch. 5) Check in item again without changing location. Note modal without the old dialog. Signed-off-by: Lisette <lisetteslatah@gmail.com> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Created attachment 87627 [details] [review] Bug 21346: Convert dialogs to modals. This addresses most of the transfer dialogs. There are some dialogs that I have not converted because I don't know what triggers them, therefore I cannot test them. The following scenarios have been addresses, and should be tested: FOR TRANSFERS 1) Checkin with no issue, hold or transfer; not at home (AutomaticItemReturn set to Don't) * Should give 3 options - Yes, Yes with print, or No. * Yes and Yes with print should trigger a transfer back home. * No should do nothing. * Print should open a window for printing, with correct information. * All three options should close the modal. TO TEST: 1) Set AutomaticItemREturn to Don't. 2) Check in an item with no issues, holds or transfers set, at a location other than the owning library. 3) Test conditions above. 2) Checkin with no issue, hold or transfer; not at home (AutomaticItemReturn set to Do) * Should give 2 options - Print or OK. * Should automatically set transfer. * Print should open a window for printing, with correct information. * Both buttons should close modal. TO TEST: 1) Set AutomaticItemReturn to Do. 2) Check in an item with no issues, holds or transfers set, at a location other than the owning library. 3) Test conditions above. 3) Checkin with no issues or holds, but transfer already set * Should give 3 options - OK, Print or Cancel. * OK and print should not touch existing transfer. * Cancel should remove the exisiting transfer. * Print should open a window for printing, with correct information. * All three options should close the modal. TO TEST: 1) Check in an item following step 2 of either test above. 2) Check in item again, while a transfer exists. 3) Test conditions above. WRONG BRANCH 4) If AllowReturnToBranch is not set "to any library", and the item is not checked in at the appropriate branch, the wrong-branch-modal pops up: * Should give 1 option - OK. * Should not check anything in or initiate a transfer. * OK should close the modal. TO TEST: 1) Set AllowReturnToBranch to "only the library the item is from". You can test the other settings, as long as you pay attention to where you are checking the item in at. 2) Check in an item at a branch other than the owning library. 3) Test conditions above. Signed-off-by: Lisette <lisetteslatah@gmail.com> Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Created attachment 87628 [details] [review] Bug 21346: Remove inline onclicks per comment 42 To test: 1) Apply patch. 2) Check that there is no changed behavior with buttons or checkboxes. Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Created attachment 87894 [details] [review] Bug 21346: Streamline logic in holds and transfers 1) Replaced comparison with string to make testing branch easier. 2) Replaced useless 0 values with undef. Does not change any behavior, only simplifies code. Signed-off-by: Lisette <lisetteslatah@gmail.com> Signed-off-by: Liz Rea <wizzyrea@gmail.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 87895 [details] [review] Bug 21346: Remove double dialog To Test: 1) Place a hold on an item for pickup at another branch. 2) Check in item to trigger hold and transfer. 3) Check in item again without changing location. Note modal AND old dialog behind modal. 4) Apply patch. 5) Check in item again without changing location. Note modal without the old dialog. Signed-off-by: Lisette <lisetteslatah@gmail.com> Signed-off-by: Liz Rea <wizzyrea@gmail.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 87896 [details] [review] Bug 21346: Convert dialogs to modals. This addresses most of the transfer dialogs. There are some dialogs that I have not converted because I don't know what triggers them, therefore I cannot test them. The following scenarios have been addresses, and should be tested: FOR TRANSFERS 1) Checkin with no issue, hold or transfer; not at home (AutomaticItemReturn set to Don't) * Should give 3 options - Yes, Yes with print, or No. * Yes and Yes with print should trigger a transfer back home. * No should do nothing. * Print should open a window for printing, with correct information. * All three options should close the modal. TO TEST: 1) Set AutomaticItemREturn to Don't. 2) Check in an item with no issues, holds or transfers set, at a location other than the owning library. 3) Test conditions above. 2) Checkin with no issue, hold or transfer; not at home (AutomaticItemReturn set to Do) * Should give 2 options - Print or OK. * Should automatically set transfer. * Print should open a window for printing, with correct information. * Both buttons should close modal. TO TEST: 1) Set AutomaticItemReturn to Do. 2) Check in an item with no issues, holds or transfers set, at a location other than the owning library. 3) Test conditions above. 3) Checkin with no issues or holds, but transfer already set * Should give 3 options - OK, Print or Cancel. * OK and print should not touch existing transfer. * Cancel should remove the exisiting transfer. * Print should open a window for printing, with correct information. * All three options should close the modal. TO TEST: 1) Check in an item following step 2 of either test above. 2) Check in item again, while a transfer exists. 3) Test conditions above. WRONG BRANCH 4) If AllowReturnToBranch is not set "to any library", and the item is not checked in at the appropriate branch, the wrong-branch-modal pops up: * Should give 1 option - OK. * Should not check anything in or initiate a transfer. * OK should close the modal. TO TEST: 1) Set AllowReturnToBranch to "only the library the item is from". You can test the other settings, as long as you pay attention to where you are checking the item in at. 2) Check in an item at a branch other than the owning library. 3) Test conditions above. Signed-off-by: Lisette <lisetteslatah@gmail.com> Signed-off-by: Liz Rea <wizzyrea@gmail.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 87898 [details] [review] Bug 21346: Remove inline onclicks per comment 42 To test: 1) Apply patch. 2) Check that there is no changed behavior with buttons or checkboxes. Signed-off-by: Liz Rea <wizzyrea@gmail.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Awesome work all! Pushed to master for 19.05
Pushed to 18.11.x series for 18.11.05
backported to 18.05.x for 18.05.12
Does not apply on 17.11.x. But since its nearly end of life we may let it like that.
I have a library that objects rather strongly to some of the changes introduced here. The main problem is the message that says an item needs a transfer. They used to be able to keep on returning books even if that message appeared. Now their workflow is disrupted and they have to click the OK button to make the modal go away. Could we make it optional if the popup message is a modal or not? (On a separate bug, of course. Just commenting here to get the opinion of the people on this bug.)
PS. The library has AutomaticItemReturn = Do.
(In reply to Magnus Enger from comment #65) > Could we make it optional if the popup message is a modal or not? Agree 100%
(In reply to Magnus Enger from comment #65) > > Could we make it optional if the popup message is a modal or not? I also agree - whether or not the message is a modal or not should be tied to a system preference so that libraries that want the modal to interrupt staff workflow (like me) can have that and those that do not want the workflow to be interrupted can have that also. George
Sounds like a consensus to me.. could we open a new bug for this please :)