To reproduce: 1. Find or create an item that belongs to a branch other than the logged-in branch 2. Check in the item - this should trigger a Return to Home transfer 3. Click OK or Print Slip on the modal to confirm the transfer 4. Check in that item again ==> The Wrong Transfer modal should pop up at this point, but it doesn't!
Created attachment 175961 [details] [review] Bug 38789: Add block class to WrongTransfer modal To test: 1. Find or create an item belonging to a branch other than the logged-in branch 2. Check in the item and click OK in the "transfer to home" modal 3. Check the item in again --> The Wrong Transfer modal should appear, but it doesn't! 4. Apply patch 5. Cancel the transfer or find a different item 6. Check in the item and click OK in the "transfer to home" modal 7. Check the item in again --> The Wrong Transfer modal should appear 8. Click OK 9. Open the bib record for that item in a new tab --> The item should have a status of "In transit" 10. Change the system preference TransfersBlockCirc to don't block 11. Check the item in again --> The Wrong Transfer modal should still appear 12. Confirm that you can click outside the modal to dismiss it without choosing an option
I'm fairly certain this was a missed case or accidental change in the Bootstrap upgrade. Git bisect places it within a few commits of that, though I had trouble getting the staff interface to render correctly to test the exact commit.
Created attachment 175962 [details] [review] Bug 38789: Add block class to WrongTransfer modal To test: 1. Find or create an item belonging to a branch other than the logged-in branch 2. Check in the item and click OK in the "transfer to home" modal 3. Check the item in again --> The Wrong Transfer modal should appear, but it doesn't! 4. Apply patch 5. Cancel the transfer or find a different item 6. Check in the item and click OK in the "transfer to home" modal 7. Check the item in again --> The Wrong Transfer modal should appear 8. Click OK 9. Open the bib record for that item in a new tab --> The item should have a status of "In transit" 10. Change the system preference TransfersBlockCirc to don't block 11. Check the item in again --> The Wrong Transfer modal should still appear 12. Confirm that you can click outside the modal to dismiss it without choosing an option Signed-off-by: David Nind <david@davidnind.com>
Created attachment 175980 [details] [review] Bug 38789: Add block class to WrongTransfer modal To test: 1. Find or create an item belonging to a branch other than the logged-in branch 2. Check in the item and click OK in the "transfer to home" modal 3. Check the item in again --> The Wrong Transfer modal should appear, but it doesn't! 4. Apply patch 5. Cancel the transfer or find a different item 6. Check in the item and click OK in the "transfer to home" modal 7. Check the item in again --> The Wrong Transfer modal should appear 8. Click OK 9. Open the bib record for that item in a new tab --> The item should have a status of "In transit" 10. Change the system preference TransfersBlockCirc to don't block 11. Check the item in again --> The Wrong Transfer modal should still appear 12. Confirm that you can click outside the modal to dismiss it without choosing an option Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
> [... don't forget to have the item "In transit"] > 12. Confirm that you can click outside the modal to dismiss it without > choosing an option The modal I see is the "Wrong transfer detected" with a cancel button. If after dismissing it I check the item in again. I see the "Please return this item" modal without a cancel button. And the item is back to transit pending. (until clicking ok in the modal) Is that expected? It happens also in main so it's to know if I should also open a ticket for that. ===== Regardless, it's not related to this patch. So here is a 2nd signoff made with also Bug 38588 applied. So we are more certain there would be no issue with both in main as that should be quickly the case as opposed to having only this.
Created attachment 175982 [details] [review] Bug 38789: Add block class to WrongTransfer modal To test: 1. Find or create an item belonging to a branch other than the logged-in branch 2. Check in the item and click OK in the "transfer to home" modal 3. Check the item in again --> The Wrong Transfer modal should appear, but it doesn't! 4. Apply patch 5. Cancel the transfer or find a different item 6. Check in the item and click OK in the "transfer to home" modal 7. Check the item in again --> The Wrong Transfer modal should appear 8. Click OK 9. Open the bib record for that item in a new tab --> The item should have a status of "In transit" 10. Change the system preference TransfersBlockCirc to don't block 11. Check the item in again --> The Wrong Transfer modal should still appear 12. Confirm that you can click outside the modal to dismiss it without choosing an option Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net> Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
(In reply to Victor Grousset/tuxayo from comment #5) > > [... don't forget to have the item "In transit"] > > 12. Confirm that you can click outside the modal to dismiss it without > > choosing an option > > The modal I see is the "Wrong transfer detected" with a cancel button. > > If after dismissing it I check the item in again. I see the "Please return > this item" modal without a cancel button. > And the item is back to transit pending. (until clicking ok in the modal) > > Is that expected? > It happens also in main so it's to know if I should also open a ticket for > that. > > ===== > > Regardless, it's not related to this patch. So here is a 2nd signoff made > with also Bug 38588 applied. So we are more certain there would be no issue > with both in main as that should be quickly the case as opposed to having > only this. Please file a separate bug for the missing cancel button so we can investigate this more.
(In reply to Emily Lamancusa (emlam) from comment #2) > I'm fairly certain this was a missed case or accidental change in the > Bootstrap upgrade. Git bisect places it within a few commits of that, though > I had trouble getting the staff interface to render correctly to test the > exact commit. Thanks for the digging, Emily!
Pushed for 25.05! Well done everyone, thank you!
(In reply to Katrin Fischer from comment #7) > Please file a separate bug for the missing cancel button so we can > investigate this more. Bug 38806
Re-added version - removed by accident?
> Re-added version - removed by accident? Yes, thanks for spotting this. When having a ticket open and someone else makes a change, refreshing the page isn't enough. Because the browser keeps the values of what seems to be all fields. And that's how it's possible to rollback most things by accident :/