To reproduce: 1. Go to Biblio Record 2. Place Hold (request.pl) - either the Hold above the Bib or the Hold on the left, it does the same thing. 3. Note that the cursor does not go to Patron Name (for whom to place the hold for), it goes to the Top Search bar under Checkout. In 19.05, the cursor does go to the Patron Name during this process and that makes sense from a workflow standpoint.
Created attachment 97887 [details] [review] Bug 24510: Add focus to Patron/club input TEST PLAN: 1. Go to Biblio Record 2. Place Hold (request.pl) - either the Hold above the Bib or the Hold on the left, it does the same thing. 3. Note that the cursor does not go to Patron Name (for whom to place the hold for), it goes to the Top Search bar under Checkout. 4. Apply patch and reload the page. 5. The focus should now be correctly set. 6. Toggle between 'Patrons' and 'Club' tabs. 7. Focus should stay set.
Created attachment 97922 [details] [review] Bug 24510: Add focus to Patron/club input Signed-off-by: Kelly McElligott <kelly@bywatersolutions.com>
What is the purpose of the test? if ( $(".focus").is(":visible") ) I do not understand your patch, neither why it works. I have the feeling that it is not the correct way to do what you want. We already have .focus in this DOM (the header search), and the same .focus() applied on them (in staff-global.js).
CCing Owen, maybe he will know what's going on here.
Created attachment 99658 [details] [review] Bug 24510: [Alternate] When Placing a Hold, cursor doesn't focus on Patron Name This alternate patch tries to implement a fix in a more "correct" way by tying the cursor focus to the initialization of the jQueryUI tabs. By configuring both the "create" and "activate" events we can make sure the correct input field is focused. I think the only advantage of this patch over the other one is that tying the focus to the tabs activation makes it a little more obvious where in the DOM loading sequence the focus is being set. To test, follow the original patch's test plan: TEST PLAN: 1. Go to Biblio Record 2. Place Hold (request.pl) - either the Hold above the Bib or the Hold on the left, it does the same thing. 3. Note that the cursor does not go to Patron Name (for whom to place the hold for), it goes to the Top Search bar under Checkout. 4. Apply patch and reload the page. 5. The focus should now be correctly set. 6. Toggle between 'Patrons' and 'Club' tabs. 7. Focus should stay set.
Created attachment 99659 [details] [review] Bug 24510: [Alternate] When Placing a Hold, cursor doesn't focus on Patron Name This alternate patch tries to implement a fix in a more "correct" way by tying the cursor focus to the initialization of the jQueryUI tabs. By configuring both the "create" and "activate" events we can make sure the correct input field is focused. I think the only advantage of this patch over the other one is that tying the focus to the tabs activation makes it a little more obvious where in the DOM loading sequence the focus is being set. To test, follow the original patch's test plan: TEST PLAN: 1. Go to Biblio Record 2. Place Hold (request.pl) - either the Hold above the Bib or the Hold on the left, it does the same thing. 3. Note that the cursor does not go to Patron Name (for whom to place the hold for), it goes to the Top Search bar under Checkout. 4. Apply patch and reload the page. 5. The focus should now be correctly set. 6. Toggle between 'Patrons' and 'Club' tabs. 7. Focus should stay set. Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Created attachment 99660 [details] [review] Bug 24510: [Alternate] When Placing a Hold, cursor doesn't focus on Patron Name This alternate patch tries to implement a fix in a more "correct" way by tying the cursor focus to the initialization of the jQueryUI tabs. By configuring both the "create" and "activate" events we can make sure the correct input field is focused. I think the only advantage of this patch over the other one is that tying the focus to the tabs activation makes it a little more obvious where in the DOM loading sequence the focus is being set. To test, follow the original patch's test plan: TEST PLAN: 1. Go to Biblio Record 2. Place Hold (request.pl) - either the Hold above the Bib or the Hold on the left, it does the same thing. 3. Note that the cursor does not go to Patron Name (for whom to place the hold for), it goes to the Top Search bar under Checkout. 4. Apply patch and reload the page. 5. The focus should now be correctly set. 6. Toggle between 'Patrons' and 'Club' tabs. 7. Focus should stay set. Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Created attachment 99661 [details] [review] Bug 24510: Add focus to Patron/club input Signed-off-by: Kelly McElligott <kelly@bywatersolutions.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Created attachment 99662 [details] [review] Bug 24510: When Placing a Hold, cursor doesn't focus on Patron Name This alternate patch tries to implement a fix in a more "correct" way by tying the cursor focus to the initialization of the jQueryUI tabs. By configuring both the "create" and "activate" events we can make sure the correct input field is focused. I think the only advantage of this patch over the other one is that tying the focus to the tabs activation makes it a little more obvious where in the DOM loading sequence the focus is being set. To test, follow the original patch's test plan: TEST PLAN: 1. Go to Biblio Record 2. Place Hold (request.pl) - either the Hold above the Bib or the Hold on the left, it does the same thing. 3. Note that the cursor does not go to Patron Name (for whom to place the hold for), it goes to the Top Search bar under Checkout. 4. Apply patch and reload the page. 5. The focus should now be correctly set. 6. Toggle between 'Patrons' and 'Club' tabs. 7. Focus should stay set. Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Created attachment 99663 [details] [review] Bug 24510: Code cleaning Additional test plan: Create 3 clubs: abc adf axy place a hold for on of those club, search for a club 'a' you will get the focus on the "Clubs" tab Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Created attachment 99665 [details] [review] Bug 24510: When Placing a Hold, cursor doesn't focus on Patron Name This alternate patch tries to implement a fix in a more "correct" way by tying the cursor focus to the initialization of the jQueryUI tabs. By configuring both the "create" and "activate" events we can make sure the correct input field is focused. I think the only advantage of this patch over the other one is that tying the focus to the tabs activation makes it a little more obvious where in the DOM loading sequence the focus is being set. To test, follow the original patch's test plan: TEST PLAN: 1. Go to Biblio Record 2. Place Hold (request.pl) - either the Hold above the Bib or the Hold on the left, it does the same thing. 3. Note that the cursor does not go to Patron Name (for whom to place the hold for), it goes to the Top Search bar under Checkout. 4. Apply patch and reload the page. 5. The focus should now be correctly set. 6. Toggle between 'Patrons' and 'Club' tabs. 7. Focus should stay set. Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Created attachment 99666 [details] [review] Bug 24510: Code cleaning Additional test plan: Create 3 clubs: abc adf axy place a hold for on of those club, search for a club 'a' you will get the focus on the "Clubs" tab Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Lucas, I re-added your signoff to Owen's patch!
I am getting a QA test tool fail here, please check: FAIL koha-tmpl/intranet-tmpl/prog/en/modules/reserve/request.tt FAIL filters missing_filter at line 982 ( active: [% active %],)
Created attachment 100733 [details] [review] Bug 24510: Add missing filter
Created attachment 100827 [details] [review] Bug 24510: Add focus to Patron/club input Signed-off-by: Kelly McElligott <kelly@bywatersolutions.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 100828 [details] [review] Bug 24510: When Placing a Hold, cursor doesn't focus on Patron Name This alternate patch tries to implement a fix in a more "correct" way by tying the cursor focus to the initialization of the jQueryUI tabs. By configuring both the "create" and "activate" events we can make sure the correct input field is focused. I think the only advantage of this patch over the other one is that tying the focus to the tabs activation makes it a little more obvious where in the DOM loading sequence the focus is being set. To test, follow the original patch's test plan: TEST PLAN: 1. Go to Biblio Record 2. Place Hold (request.pl) - either the Hold above the Bib or the Hold on the left, it does the same thing. 3. Note that the cursor does not go to Patron Name (for whom to place the hold for), it goes to the Top Search bar under Checkout. 4. Apply patch and reload the page. 5. The focus should now be correctly set. 6. Toggle between 'Patrons' and 'Club' tabs. 7. Focus should stay set. Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 100829 [details] [review] Bug 24510: Code cleaning Additional test plan: Create 3 clubs: abc adf axy place a hold for on of those club, search for a club 'a' you will get the focus on the "Clubs" tab Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 100830 [details] [review] Bug 24510: Add missing filter Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Nice work everyone! Pushed to master for 20.05
backported to 19.11.x branch for 19.11.05