- Used Zammad version: 184.108.40.206e46055a5.saas
- Used Zammad installation type: Cloud
- Operating system:
- Browser + version:
- in Report > Profile > -all- show the real number of created tickets within the selected period, i.e. current year 2023 and 10.075 tickets
- in Report > Profile > -all- the counter shows a maximum of 10.000
- the downloaded Excel file contains a maximum of 6.000 entries only
Steps to reproduce the behavior:
- Have more than 10.000 tickets that match the selected period (i.e. current year, 10.075 tickets)
- See the Download button counter: shows a maximum of 10.000, the downloaded Excel file has only 6.000 ticket entries.
- Does the counter in the download button have a fixed limit of 10.000?
- Is there a still a hardcoded limit of 6.000 for the tickets downloaded in the Excel file?
(Like mentioned in this support issue: Excel-Export in Reporting only exports 6000 entries · Issue #2433 · zammad/zammad · GitHub)
Is there a possibility to change these limits?
The hard limit is a hard limit for a good reason.
I’ve been testing this back then and noticed that raising that hard limit is not a solution because Zammad takes more time (due to more data) to process and thus export would die on even fast idleing machines with a lot of steam.
For this reason issue 2433 exists which suggest changes in the way this report is generated. Before that you shouldn’t touch / change anything of that. If you can use the per month export if it allows you to stay below the known limit.
Another possible solution could be to use Grafana or any other third party tool you prefer to hook up to Elasticsearch which doesn’t limit you.
See: Reporting Tools (Third party) — Zammad documentation
and Elasticsearch (SaaS) — Zammad documentation as you’re on SaaS.
Thank you for the detailed informations and the hints to Grafana. I will check that.
Regarding the hard limit of 6.000 entries in a download to an Excel file, I now understand the reason and will keep an eye on issue 2433.
Regarding the counter that is shown in the button, which seems to be limited to 10.000 entries: It would already help a lot if this counter wouldn’t be limited. Do you see any chance to just change the counter so that it shows the real number of entries?
Most likely an unpopular opinion: I’d say rather display the 6,000 counter and indicate the limit visually.
That’s much cleaner because -while you expect to have more data in that scope- you won’t search for the missing 4,000+ entries in your export file.
Not sure if that qualifies as bug to be honest. I also didn’t check if there’s a bug report aside of that already. If not, feel free to create one: Issues · zammad/zammad · GitHub
I’d say rather display the 6,000 counter and indicate the limit visually. That’s much cleaner because -while you expect to have more data in that scope- you won’t search for the missing 4,000+ entries in your export file.
I do agree.
Maybe an additional field for the total-counter, beside the download button, could be a transparent solution. Something like:
Button: [ Download nnnn entries ] :: of a total of mmmmm entries
And if the limit of 6.000 entires for the download is reached it could be noted below the button.
I’ll open a feature request for that.
Thank you again for your clarifications.