When a staff member clicks the run report button in the guided reports interface, we should disable the button, and display some indication an action is occurring (such as a spinner). Jake.
Created attachment 187044 [details] [review] Bug 40896: Disable run report buttons upon click This patch will disable the run report button found on both the list page, and the individual operation pages (e.g. run, edit, saved successfully). This will stop librarians from unintentionally crashing their Koha system, by pressing the run report button repeatedly when there is no need to re-request it. TO TEST: a) go to /cgi-bin/koha/reports/guided_reports.pl?op=list b) create three new sql test reports: *) Name: Test report #1, SQL: SELECT count(*) FROM biblio *) Name: Test report #2, SQL: SELECT count(*) FROM items *) Name: Test report #3, SQL: SELECT * FROM items WHERE items.dateaccessioned = <<Date accessioned|date>> c) run all of the above test reports, noticing how the run report button can be activated repeatedly APPLY PATCH d) redo step a e) run test report #1 from the table, notice how now the button can only be activated once before it is greyed out and the play button is replaced with a spinner f) return to the list, edit test report #2 from the table, click run report from the edit page, and notice how this run report button exhibits the same behaviour as the button in step e g) return to the list, run test report #3, select a date, click run report from this page, and notice again how the run report button exhibits the same behaviour as the buttons in steps e and f SIGN OFF
Created attachment 187193 [details] [review] Bug 40896: Disable run report buttons upon click This patch will disable the run report button found on both the list page, and the individual operation pages (e.g. run, edit, saved successfully). This will stop librarians from unintentionally crashing their Koha system, by pressing the run report button repeatedly when there is no need to re-request it. TO TEST: a) go to /cgi-bin/koha/reports/guided_reports.pl?op=list b) create three new sql test reports: *) Name: Test report #1, SQL: SELECT count(*) FROM biblio *) Name: Test report #2, SQL: SELECT count(*) FROM items *) Name: Test report #3, SQL: SELECT * FROM items WHERE items.dateaccessioned = <<Date accessioned|date>> c) run all of the above test reports, noticing how the run report button can be activated repeatedly APPLY PATCH d) redo step a e) run test report #1 from the table, notice how now the button can only be activated once before it is greyed out and the play button is replaced with a spinner f) return to the list, edit test report #2 from the table, click run report from the edit page, and notice how this run report button exhibits the same behaviour as the button in step e g) return to the list, run test report #3, select a date, click run report from this page, and notice again how the run report button exhibits the same behaviour as the buttons in steps e and f SIGN OFF Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
This is a great idea! If you have time for it, it'd be good to also do this on the "Update and run SQL" button on the edit screen.
Hi Jake, was looking to QA this. Could you make one change? Could you replace the match on i.fa-{spinner,play} with usage of ids or data attributes instead? Just to decouple the logic from the icon classes so that we don't have to touch it if we change icon libraries.
Created attachment 187512 [details] [review] Bug 40896: (follow-up) DO NOT PUSH
Hi Paul, Take a look at that patch. We're just looking for any FontAwesome class within the element targeted, now. There is still a line that will `replaceWith` the HTML after 120 seconds, but to be honest I can't think of another sane way of doing this, without any easily usable ID or data attribute on the FontAwesome icon itself? If it looks good, I'll merge it down into one patchfile for pushing. Ta, Jake