Posts made by admin

Have you tried to disable the charts animations?

Yes, jsreport needs to be restarted after every configuration change.

Please check the following
https://jsreport.net/learn/reports#cleanup

I'm not sure if I understand the question.
However, if you mean you want to specify in the rendering request the full path of the template, then yes, you can do it like this.

{
  "template": { 
      "name": "/folderA/subfolder1/subfolder2/subfolder3/template1" 
  },
  "data": {}
}

This is the right config,
express.enabled: true, studio.enabled: false
However, in v2 there is still login screen wired, you would need to update jsreport.

Or you can overwrite the route in your server.js file

const jsreport = require('jsreport')()

if (process.env.JSREPORT_CLI) {
  // export jsreport instance to make it possible to use jsreport-cli
  module.exports = jsreport
} else {
  jsreport.init().then(() => {
    reporter.on('after-express-static-configure', (app) => {    
      app.get('/', (req, res) => {
        res.status(404).send('Not Found')
      })
    })
    // running
  }).catch((e) => {
    // error during startup
    console.error(e.stack)
    process.exit(1)
  })
}

It gets applied for me.
I can set marginTop in script and also in the studio.

It seems like your stored data got a bit corrupted, maybe with some custom ODATA calls?

There should be no @odata stored in the db, that is likely causing the issue.
Can you please try to find which odata call adds that attribute to the entities?
Thank you

That script triggering the print with window.JSREPORT_READY_TO_START would need to be in that stock-market page. This means your template will just wait until it times out.

You can try waiting for the network instead

Thank you.
I confirm this is a bug. I apologize for the inconvenience.

We make sure this is fixed in the next update. Not having the date, though.
Here is the gh ticket to track
https://github.com/jsreport/jsreport/issues/1257

Please share a link to a onedrive, dropbox, googledrive...

I see. Would you please share a minimal playground demo replicating the issue?
https://playground.jsreport.net/

Handlebars doesn't have an eq helper, but you may easily add it.

I apologize for the delay. It looks like we will do the change and start calculating the reportTimeout after the worker starts processing. It will be the most likely part of the 4.11.0 (your license will work with that)

The reportTimeout is based on when the request arrived. This was designed a couple of years ago and still works the same with no complaints so far. However, I understand this doesn't play so well with async requests.

We will reconsider this and come back shortly.
Thank you for the ideas.

The 4.10.1 including pdf utils fixes has been released
https://github.com/jsreport/jsreport/releases/tag/4.10.1

Great, thank you. I can replicate the problem.
Chrome has again changed how it is structuring the output PDF. We will need to adapt some parts.
Expecting to release hotfix 4.10.1 with the fix tomorrow.
I apologize for the inconvenience.

Feel free to post the details here or create a new post.

I've tried the exact steps from here
https://jsreport.net/learn/ubuntu
In a fresh Azure VM with Ubuntu 22.04 and I see no issues.

Could you isolate what you have different?

You may experience a wrong footer alignment issue when updating to jsreport 4.10.0 in case you use the CSS code from our samples or the studio pdf utils quick action to add header/footer. You will notice this visually when the footer is at the top and not at the bottom.

The reason for this is not the jsreport itself but the Chromium 138 dependency update, which changed the CSS flexbox engine calculation. This caused the CSS used in our demos to position the footer to the bottom to stop working.

Fortunately, the fix is easy.
Find the template you merge as the header/footer and locate the following CSS

.main {
     ....
  height: 100%;
}

And change the 100% to 100vh

.main {
     ....
  height: 100vh;
}

Could you share an example when the index gets broken in 4.10.0?
I don't see this problem in our samples.