| Summary: | Prevent users from running the same report multiple times concurrently | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Kyle M Hall (khall) <kyle> |
| Component: | Reports | Assignee: | Kyle M Hall (khall) <kyle> |
| Status: | Needs Signoff --- | QA Contact: | Testopia <testopia> |
| Severity: | enhancement | ||
| Priority: | P5 - low | CC: | anneli.osterman, dcook, lisette, lmstrand |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| GIT URL: | Initiative type: | --- | |
| Sponsorship status: | --- | Comma delimited list of Sponsors: | |
| Crowdfunding goal: | 0 | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
| Bug Depends on: | |||
| Bug Blocks: | 41919 | ||
| Attachments: |
Bug 41918: Add method to see running report queries by user and id
Bug 41918: Prevent a given librarian from running the same report multiple times simultaneously Bug 41918: Add ability to disable or change limit via config xml |
||
|
Description
Kyle M Hall (khall)
2026-02-24 19:19:35 UTC
> We should allow any given report to only be run one execution at a time.
Do you mean per user or per all users?
I think we have reports that several users need to run simultaneously.
Maybe showing a spinner like in patron search or a textbox with spinner with text like "Running report, please wait..." that disables UI controls that disappears when the user moves away from the page with browser controls or when the report data is fetched would suffice? I tested this concept quickly and it seems decent to me. The browser's own tab spinner is quite unnoticeable and clearer indication that report data is still being fetched might help in this issue. The problem is that the spinner would need to be tied to result page pagination controls and tabs etc. since the whole report gets ran again by changing/pressing them (which could be an issue for another ticket). I also think there's no way we can tie database processes to what is seen in the UI and we definitely need to allow running the same report by different users simultaneously. Created attachment 193918 [details] [review] Bug 41918: Add method to see running report queries by user and id Patch from commit 516e7ec Created attachment 193919 [details] [review] Bug 41918: Prevent a given librarian from running the same report multiple times simultaneously Test Plan: 1) create a long running report such as: SELECT COUNT(*) FROM items i1 JOIN items i2 JOIN items i3 JOIN items i4 JOIN items i5 JOIN items i6 2) Run this report multiple times 3) Note the processes are running via SHOW FULL PROCESSLIST from koha-mysql 4) Kill those processes 5) Apply this patch 6) Restart all the things! 7) Try to run the report in two tabs, note the second tab opened says the report is already running! Created attachment 193920 [details] [review] Bug 41918: Add ability to disable or change limit via config xml This commit add the option duplicate_running_reports_per_user_limit to koha-conf.xml. If this option is empty or 0, the feature is disabled. If this option is enabled, Koha will limit the number of times a given report can be run of a single Koha user. Test Plan: 1) Apply this patch 2) Set duplicate_running_reports_per_user_limit to 1, verify previous behavior is maintained 2) Set duplicate_running_reports_per_user_limit to 0, verify the feature is disabled 3) Set duplicate_running_reports_per_user_limit to 2, verify Koha limits the number of duplicates of the report to the number specified in duplicate_running_reports_per_user_limit Seems to be working fine when trying to run two instances of the same report from the report view (/cgi-bin/koha/reports/guided_reports.pl?id=x&op=show) when limit is set to 1 in koha-conf.xml. Running a simultaneous report from list view(/cgi-bin/koha/reports/guided_reports.pl?op=list) before/after running one from report view does not block a second run. Should it? I'm not running my Koha with plack so page loads are quite slow but based on my repeated tests this works consistently from the op=show view at least. |