Thank you for the topic. I've tried to replicate the issue, but I can't reproduce it so far.
Some questions to help me isolate the problem...
Do you have authentication enabled?
Do you reproduce the same with the local mongo single node replica?
Could you upload somewhere an export with "many child entities" so we test on the same?
The Chromium pdf printing evolves in time. The later versions add accessibility, image masking, and other implementation changes that may increase the final PDF size. We update Chromium every time when releasing jsreport, that's the reason why v2 and v4 pdf outputs differ.
There are 3 visible images in the flight ticket showcase, but every image also has an alpha mask. That's why you see 6 images in the PDF source.
You can try to enable the pdf compression feature
We have fixed the performance regression issue for v2-based templates where there are no handlebars tags present in the xlsx file. In other words, for templates that use just xlsxAdd, xlsxMerge... transformations.
The fix is currently in the master branch waiting for the next release, however you can already test it in the docker nightly build
docker run -p 5488:5488 jsreport/jsreport:nightly
I can imagine that the Chromium update included in v4.8.0 is causing the issue. That Chromium, for some reason, like insufficient resources, fails. While it was working fine with the older Chromium from v4.7.0.
Any chance you would be able to email me a working workspace/demo that I can use and try to replicate the issue?
Automated audit tools can be useful, but they often report false positives. In large, dependency-heavy projects like jsreport, these reports frequently flag issues that are not exploitable in practice and therefore don’t always provide meaningful, actionable security value.
For this reason, we won’t be releasing jsreport hotfixes on a more frequent schedule.
We take security seriously and run multiple audit scans as part of every release, working to satisfy their requirements. This process already requires significant time and effort, and we don’t plan to extend it beyond our current scope.
This is likely because you have updated the nodejs.
You have several options.
node --no-deprecation server.js or env NODE_NO_WARNINGS=1Unfortunately, there is 60s hard limit in jsreportonline
https://jsreport.net/learn/online-limits
If you want to render big reports with longer execution, you will need to switch to the onprem deployment.
Hi, the jsreport 4.12.0 includes the change.
Hi @Ish-Modi
It will be part of the next release 4.12.0 which should be live within two weeks.