[Bug 43623] New: Pagination of JSON Report Exports
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 Bug ID: 43623 Summary: Pagination of JSON Report Exports Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs@lists.koha-community.org Reporter: mathsabypro@gmail.com QA Contact: testopia@bugs.koha-community.org CC: lisette@bywatersolutions.com Target Milestone: --- To avoid the risk of downloading too many rows when exporting a report as JSON, I wanted to try paginating the results by adding a limit and a variable offset (a parameter passed in the URL) to the report. But OFFSET doesn’t seem to be supported in SQL, which surprises me because it isn’t listed among the filtered keywords specified in the community wiki (create, update, etc.). Example: select itemnumber from items LIMIT 50 OFFSET 100 gives me : You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'LIMIT 0, 50' at line 2 Is it a bug ? a missing feature? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 --- Comment #1 from Jonathan Druart <jonathan.druart@gmail.com> --- Created attachment 206812 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206812&action=edit Bug 43623: Fix negative LIMIT when report offset is greater than its limit execute_query added the offset of the user supplied LIMIT to the pagination offset before comparing it with the user supplied count. With "LIMIT 100, 50" the computed limit was 50 - 100 = -50, resulting in a SQL syntax error. The pagination offset is relative to the user supplied offset, so compare it with the user supplied count first and add the user offset afterwards. Test plan: 1. Create a SQL report: SELECT itemnumber FROM items LIMIT 100, 50 2. Run it => SQL syntax error near '-50' 3. Apply this patch 4. Run the report again => 50 items are displayed, and the following pages stop at the 50th item 5. prove t/db_dependent/Reports/Guided.t Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 --- Comment #2 from Jonathan Druart <jonathan.druart@gmail.com> --- Created attachment 206813 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206813&action=edit Bug 43623: Support LIMIT ... OFFSET ... syntax in SQL reports strip_limit only recognized "LIMIT count" and "LIMIT offset, count". A report using "LIMIT count OFFSET offset" kept its OFFSET clause, and execute_query then appended "LIMIT ?, ?" to it, resulting in a SQL syntax error. Test plan: 1. Create a SQL report: SELECT itemnumber FROM items LIMIT 50 OFFSET 100 2. Run it => SQL syntax error near 'LIMIT 0, 50' 3. Apply this patch 4. Run the report again => 50 items are displayed, the same as in the database console 5. prove t/db_dependent/Reports/Guided.t Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Pagination of JSON Report |LIMIT OFFSET syntax not |Exports |correctly handled in | |reports CC| |jonathan.druart@gmail.com Assignee|koha-bugs@lists.koha-commun |jonathan.druart@gmail.com |ity.org | -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 OpenFifth Sandboxes <sandboxes@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #206813|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 --- Comment #3 from OpenFifth Sandboxes <sandboxes@openfifth.co.uk> --- Created attachment 206884 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206884&action=edit Bug 43623: Support LIMIT ... OFFSET ... syntax in SQL reports strip_limit only recognized "LIMIT count" and "LIMIT offset, count". A report using "LIMIT count OFFSET offset" kept its OFFSET clause, and execute_query then appended "LIMIT ?, ?" to it, resulting in a SQL syntax error. Test plan: 1. Create a SQL report: SELECT itemnumber FROM items LIMIT 50 OFFSET 100 2. Run it => SQL syntax error near 'LIMIT 0, 50' 3. Apply this patch 4. Run the report again => 50 items are displayed, the same as in the database console 5. prove t/db_dependent/Reports/Guided.t Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Mathieu Saby <mathsabypro@gmail.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 OpenFifth Sandboxes <sandboxes@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #206812|0 |1 is obsolete| | Attachment #206884|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 --- Comment #4 from OpenFifth Sandboxes <sandboxes@openfifth.co.uk> --- Created attachment 206885 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206885&action=edit Bug 43623: Fix negative LIMIT when report offset is greater than its limit execute_query added the offset of the user supplied LIMIT to the pagination offset before comparing it with the user supplied count. With "LIMIT 100, 50" the computed limit was 50 - 100 = -50, resulting in a SQL syntax error. The pagination offset is relative to the user supplied offset, so compare it with the user supplied count first and add the user offset afterwards. Test plan: 1. Create a SQL report: SELECT itemnumber FROM items LIMIT 100, 50 2. Run it => SQL syntax error near '-50' 3. Apply this patch 4. Run the report again => 50 items are displayed, and the following pages stop at the 50th item 5. prove t/db_dependent/Reports/Guided.t Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Mathieu Saby <mathsabypro@gmail.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 --- Comment #5 from OpenFifth Sandboxes <sandboxes@openfifth.co.uk> --- Created attachment 206886 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206886&action=edit Bug 43623: Support LIMIT ... OFFSET ... syntax in SQL reports strip_limit only recognized "LIMIT count" and "LIMIT offset, count". A report using "LIMIT count OFFSET offset" kept its OFFSET clause, and execute_query then appended "LIMIT ?, ?" to it, resulting in a SQL syntax error. Test plan: 1. Create a SQL report: SELECT itemnumber FROM items LIMIT 50 OFFSET 100 2. Run it => SQL syntax error near 'LIMIT 0, 50' 3. Apply this patch 4. Run the report again => 50 items are displayed, the same as in the database console 5. prove t/db_dependent/Reports/Guided.t Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Mathieu Saby <mathsabypro@gmail.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 Mathieu Saby <mathsabypro@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off --- Comment #6 from Mathieu Saby <mathsabypro@gmail.com> --- Thank you for the patch! I tested on an sandbox, it works as expected. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |blawlor@clamsnet.org |y.org | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 Brendan Lawlor <blawlor@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA Patch complexity|--- |Small patch -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 Brendan Lawlor <blawlor@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #206885|0 |1 is obsolete| | Attachment #206886|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 --- Comment #7 from Brendan Lawlor <blawlor@clamsnet.org> --- Created attachment 207669 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207669&action=edit Bug 43623: Fix negative LIMIT when report offset is greater than its limit execute_query added the offset of the user supplied LIMIT to the pagination offset before comparing it with the user supplied count. With "LIMIT 100, 50" the computed limit was 50 - 100 = -50, resulting in a SQL syntax error. The pagination offset is relative to the user supplied offset, so compare it with the user supplied count first and add the user offset afterwards. Test plan: 1. Create a SQL report: SELECT itemnumber FROM items LIMIT 100, 50 2. Run it => SQL syntax error near '-50' 3. Apply this patch 4. Run the report again => 50 items are displayed, and the following pages stop at the 50th item 5. prove t/db_dependent/Reports/Guided.t Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Mathieu Saby <mathsabypro@gmail.com> Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 --- Comment #8 from Brendan Lawlor <blawlor@clamsnet.org> --- Created attachment 207670 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207670&action=edit Bug 43623: Support LIMIT ... OFFSET ... syntax in SQL reports strip_limit only recognized "LIMIT count" and "LIMIT offset, count". A report using "LIMIT count OFFSET offset" kept its OFFSET clause, and execute_query then appended "LIMIT ?, ?" to it, resulting in a SQL syntax error. Test plan: 1. Create a SQL report: SELECT itemnumber FROM items LIMIT 50 OFFSET 100 2. Run it => SQL syntax error near 'LIMIT 0, 50' 3. Apply this patch 4. Run the report again => 50 items are displayed, the same as in the database console 5. prove t/db_dependent/Reports/Guided.t Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Mathieu Saby <mathsabypro@gmail.com> Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 --- Comment #9 from Brendan Lawlor <blawlor@clamsnet.org> --- Created attachment 207671 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207671&action=edit Bug 43623: (QA follow-up) Respect rows per page when the report has a LIMIT On the first page of results, execute_query raised the page size to the report's own LIMIT whenever the page size was smaller. A report with LIMIT 50 always showed 50 rows on the first page, whatever was selected in "Rows per page", and the next pages repeated rows from it. The previous patch made this happen for "LIMIT offset, count" and "LIMIT count OFFSET offset" reports too, because the report's offset is now added after the check. This patch removes that branch. The check above it already stops each page at the report's LIMIT. Test plan: 1. Create a SQL report: SELECT itemnumber00 2. Run it and set "Rows per page" to 20 3. Note the first page still shows 50 row 4. Apply this patch and restart_all 5. Run the report again with 20 rows per 6. Note the first page shows 20 rows, and pages 2 and 3 show the next 20 and 10 without repeating any rows 7. Repeat with SELECT itemnumber FROM items LIMIT 50 and note the same 8. prove t/db_dependent/Reports/Guided.t Sponsored-by: CLAMS Co-Authored-By: Claude Opus 5.5 <noreply@ Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 --- Comment #10 from Brendan Lawlor <blawlor@clamsnet.org> --- Created attachment 207672 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207672&action=edit Bug 43623: (QA follow-up) Add POD for internal subs After the last patch the QA script failed for missing POD coverage. This patch adds POD for _get_columns, _build_query, _get_display_value Sponsored-by: CLAMS Co-Authored-By: Claude Opus 5.5 <noreply@ Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 Brendan Lawlor <blawlor@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #207669|0 |1 is obsolete| | Attachment #207670|0 |1 is obsolete| | Attachment #207671|0 |1 is obsolete| | Attachment #207672|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 --- Comment #11 from Brendan Lawlor <blawlor@clamsnet.org> --- Created attachment 207673 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207673&action=edit Bug 43623: Fix negative LIMIT when report offset is greater than its limit execute_query added the offset of the user supplied LIMIT to the pagination offset before comparing it with the user supplied count. With "LIMIT 100, 50" the computed limit was 50 - 100 = -50, resulting in a SQL syntax error. The pagination offset is relative to the user supplied offset, so compare it with the user supplied count first and add the user offset afterwards. Test plan: 1. Create a SQL report: SELECT itemnumber FROM items LIMIT 100, 50 2. Run it => SQL syntax error near '-50' 3. Apply this patch 4. Run the report again => 50 items are displayed, and the following pages stop at the 50th item 5. prove t/db_dependent/Reports/Guided.t Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Mathieu Saby <mathsabypro@gmail.com> Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 --- Comment #12 from Brendan Lawlor <blawlor@clamsnet.org> --- Created attachment 207674 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207674&action=edit Bug 43623: Support LIMIT ... OFFSET ... syntax in SQL reports strip_limit only recognized "LIMIT count" and "LIMIT offset, count". A report using "LIMIT count OFFSET offset" kept its OFFSET clause, and execute_query then appended "LIMIT ?, ?" to it, resulting in a SQL syntax error. Test plan: 1. Create a SQL report: SELECT itemnumber FROM items LIMIT 50 OFFSET 100 2. Run it => SQL syntax error near 'LIMIT 0, 50' 3. Apply this patch 4. Run the report again => 50 items are displayed, the same as in the database console 5. prove t/db_dependent/Reports/Guided.t Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Mathieu Saby <mathsabypro@gmail.com> Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 --- Comment #13 from Brendan Lawlor <blawlor@clamsnet.org> --- Created attachment 207675 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207675&action=edit Bug 43623: (QA follow-up) Respect rows per page when the report has a LIMIT On the first page of results, execute_query raised the page size to the report's own LIMIT whenever the page size was smaller. A report with LIMIT 50 always showed 50 rows on the first page, whatever was selected in "Rows per page", and the next pages repeated rows from it. The previous patch made this happen for "LIMIT offset, count" and "LIMIT count OFFSET offset" reports too, because the report's offset is now added after the check. This patch removes that branch. The check above it already stops each page at the report's LIMIT. Test plan: 1. Create a SQL report: SELECT itemnumber FROM items LIMIT 50 OFFSET 100 2. Run it and set "Rows per page" to 20 3. Note the first page still shows 50 rows 4. Apply this patch and restart_all 5. Run the report again with 20 rows per page 6. Note the first page shows 20 rows, and pages 2 and 3 show the next 20 and 10 without repeating any rows 7. Repeat with SELECT itemnumber FROM items LIMIT 50 and note the same 8. prove t/db_dependent/Reports/Guided.t Sponsored-by: CLAMS Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 --- Comment #14 from Brendan Lawlor <blawlor@clamsnet.org> --- Created attachment 207676 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207676&action=edit Bug 43623: (QA follow-up) Add POD for internal subs The QA script checks POD coverage of changed files, and these internal subs have never had POD. This patch adds POD for _get_columns, _build_query, _get_display_value. To test: Run qa or podchecker C4/Reports/Guided.pm Sponsored-by: CLAMS Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 --- Comment #15 from Brendan Lawlor <blawlor@clamsnet.org> --- When testing I noticed that adding a LIMIT to a report broke the Rows per page selection in the table, so I added a follow up patch to address that issue. Jonathan's test plan says Run the report again => 50 items are displayed, and the following pages stop at the 50th item With the follow up applied, page 1 now shows the default 20 rows per page, and all 50 appear across the pages. Changing Rows per page to 10 works as expected. If I am misinterpreting the issue and that's not right the follow ups can be obsoleted. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 Brendan Lawlor <blawlor@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Failed QA --- Comment #16 from Brendan Lawlor <blawlor@clamsnet.org> --- Sorry, I meant to set this as Failed QA to ask about the issue with the rows per page control on the table and the attached follow up. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Passed QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #207675|0 |1 is obsolete| | Attachment #207676|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 --- Comment #17 from Jonathan Druart <jonathan.druart@gmail.com> --- Created attachment 207825 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207825&action=edit Bug 43623: (QA follow-up) Respect rows per page when the report has a LIMIT On the first page of results, execute_query raised the page size to the report's own LIMIT whenever the page size was smaller. A report with LIMIT 50 always showed 50 rows on the first page, whatever was selected in "Rows per page", and the next pages repeated rows from it. The previous patch made this happen for "LIMIT offset, count" and "LIMIT count OFFSET offset" reports too, because the report's offset is now added after the check. This patch removes that branch. The check above it already stops each page at the report's LIMIT. Test plan: 1. Create a SQL report: SELECT itemnumber FROM items LIMIT 50 OFFSET 100 2. Run it and set "Rows per page" to 20 3. Note the first page still shows 50 rows 4. Apply this patch and restart_all 5. Run the report again with 20 rows per page 6. Note the first page shows 20 rows, and pages 2 and 3 show the next 20 and 10 without repeating any rows 7. Repeat with SELECT itemnumber FROM items LIMIT 50 and note the same 8. prove t/db_dependent/Reports/Guided.t Sponsored-by: CLAMS Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 --- Comment #18 from Jonathan Druart <jonathan.druart@gmail.com> --- Created attachment 207826 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207826&action=edit Bug 43623: (QA follow-up) Add POD for internal subs The QA script checks POD coverage of changed files, and these internal subs have never had POD. This patch adds POD for _get_columns, _build_query, _get_display_value. To test: Run qa or podchecker C4/Reports/Guided.pm Sponsored-by: CLAMS Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 --- Comment #19 from Jonathan Druart <jonathan.druart@gmail.com> --- (In reply to Brendan Lawlor from comment #16)
Sorry, I meant to set this as Failed QA to ask about the issue with the rows per page control on the table and the attached follow up.
Yes, looks good. Thanks! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)| |26.11.00 released in| | --- Comment #20 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Pushed to main for 26.11 with consent from Pedro whilst he's on annual leave -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to main -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org