The information in https://jsreport.net/learn/centos is kinda dated (some of the URLs no longer work).
For RHEL8/9 or Alma8/9 I've found it better just to add the official chrome repo as documented at https://www.tecmint.com/install-google-chrome-in-linux/ and then just use yum to install it. This seems to pull in all the dependencies correctly and I don't think you need the special "chrome" launch options anymore as I didn't add them and it seems to work fine.
Thank you - seems to work well and was easy!
We are generating some PDF bills and would like to see all the ones that are greater than two pages long (i.e. will not fit on front and back of a single sheet). In searching the web, I saw several older mentions that this was returned in the headers when you call the API, but in debugging (either in jsreport studio or in my own code) I don't see that being returned. Is this possible and if so, how? Using v3.11.3 at the moment if that helps.
Thanks for the example and reply. Turns out, we were still using 3.6.2 and while it had the component feature in the UI, i think it was maybe buggy. As soon as I updated to 3.11.3, passing parameters works as documented. Posting this just in case anyone else runs into it. Should have known to upgrade to latest before trying a new feature!
Maybe both 1 and 2 could be accomplished by just using vscode directly on the data folder via ssh or something, but I suspect it would need some configuring to make all that work?
All that said - I love jsreports for its simplicity, flexibility, and robustness. Looking forward to what's in store for the next version!
I updated all the packages including jsreport by doing "npm install package@latest" for each one and things appear to be working correctly now in the production instance. Should have tried that first I guess. Thanks for your help!
FWIW, i did just install latest version of jsreport-cli globally as per on-prem instructions, and recreate an the app on the production server on a different port and in a different folder in the production environment, and xlsx works correctly, so I will stare and compare the configs - must be something didn't get added when we upgraded from version 2 to 3 maybe... If I figure it out i will post - thanks for the suggestion.
Here is the package.json:
{
"name": "jsreport-server",
"main": "server.js",
"scripts": {
"start": "node server",
"jsreport": "jsreport"
},
"jsreport": {
"entryPoint": "server.js"
},
"dependencies": {
"@jsreport/jsreport-unoconv": "^3.0.0",
"axios": "^0.24.0",
"cheerio-page-eval": "^1.0.0",
"dayjs": "^1.10.7",
"jsreport": "^3.2.0",
"mssql": "^7.3.0",
"pg": "^8.7.1"
}
}
I work with tincanium - here are the logs - our production server is Alma Linux 8 FWIW - I installed unoconv and restarted because i noticed the playground had that and ours did not but that didn't seem to fix it - i notice playground also has "office password" extension but can't think that is required? This is our first time trying the xlsx recipe - but pdf and html-to-xlsx are working fine in production so I'm not sure what the problem is.
2022-06-01T21:26:49.956Z - info: Initializing jsreport (version: 3.4.1, configuration file: jsreport.config.json, nodejs: 16.11.1)
2022-06-01T21:26:49.959Z - info: Searching for available extensions in /redacted/
2022-06-01T21:26:49.966Z - info: Extensions location cache contains up to date information, skipping crawling in /redacted/
2022-06-01T21:26:50.008Z - info: Found 36 extension(s)
2022-06-01T21:26:50.036Z - debug: Writing extension locations cache to /tmp/jsreport/core/locations.json
2022-06-01T21:26:50.037Z - debug: Discovered 36 extensions
2022-06-01T21:26:50.092Z - info: Using extension authentication@3.2.0
2022-06-01T21:26:50.230Z - debug: Extension authentication@3.2.0 was disabled
2022-06-01T21:26:50.231Z - info: Using extension base@3.0.0
2022-06-01T21:26:50.235Z - info: Using extension child-templates@3.0.1
2022-06-01T21:26:50.236Z - info: Using extension cli@3.1.0
2022-06-01T21:26:50.239Z - info: Using extension components@3.2.0
2022-06-01T21:26:50.240Z - info: Using extension data@3.0.1
2022-06-01T21:26:50.241Z - info: Using extension express@3.3.1
2022-06-01T21:26:50.462Z - info: Using extension freeze@3.0.1
2022-06-01T21:26:50.464Z - info: Using extension fs-store@3.1.0
2022-06-01T21:26:50.536Z - info: Using extension handlebars@3.0.0
2022-06-01T21:26:50.538Z - info: Using extension import-export@3.1.1
2022-06-01T21:26:50.547Z - info: Using extension jsrender@3.0.0
2022-06-01T21:26:50.548Z - info: Using extension licensing@3.0.2
2022-06-01T21:26:50.565Z - info: Using extension localization@3.2.0
2022-06-01T21:26:50.565Z - info: Using extension npm@3.1.1
2022-06-01T21:26:50.569Z - info: Using extension pdf-utils@3.3.0
2022-06-01T21:26:50.570Z - info: Using extension reports@3.0.3
2022-06-01T21:26:50.573Z - info: Using extension tags@3.1.0
2022-06-01T21:26:50.576Z - info: Using extension text@3.0.0
2022-06-01T21:26:50.577Z - debug: Extension version-control@3.1.0 is disabled, skipping
2022-06-01T21:26:50.577Z - info: Using extension assets@3.3.0
2022-06-01T21:26:50.605Z - info: Using extension authorization@3.2.0
2022-06-01T21:26:50.611Z - debug: Extension authorization@3.2.0 was disabled
2022-06-01T21:26:50.612Z - info: Using extension browser-client@3.1.0
2022-06-01T21:26:50.616Z - info: Using extension chrome-pdf@3.1.0
2022-06-01T21:26:50.620Z - debug: Chrome strategy is chrome-pool, numberOfWorkers: 1
2022-06-01T21:26:50.620Z - info: Using extension docx@3.2.0
2022-06-01T21:26:50.623Z - info: Using extension html-to-xlsx@3.2.0
2022-06-01T21:26:50.872Z - info: html-to-xlsx detected chrome as available html engine
2022-06-01T21:26:50.873Z - info: html-to-xlsx detected cheerio as available html engine
2022-06-01T21:26:50.873Z - info: Using extension pptx@3.1.0
2022-06-01T21:26:50.875Z - info: Using extension scheduling@3.0.1
2022-06-01T21:26:50.912Z - info: Using extension scripts@3.2.0
2022-06-01T21:26:50.913Z - info: Using extension static-pdf@3.0.0
2022-06-01T21:26:50.913Z - info: Using extension studio@3.4.0
2022-06-01T21:26:50.979Z - info: Using extension xlsx@3.1.0
2022-06-01T21:26:50.999Z - info: Using extension public-templates@3.0.0
2022-06-01T21:26:51.000Z - debug: Extension public-templates@3.0.0 was disabled
2022-06-01T21:26:51.000Z - info: Using extension sample-template@3.1.0
2022-06-01T21:26:51.002Z - info: Using extension studio-theme-dark@3.0.1
2022-06-01T21:26:51.003Z - info: Using extension unoconv@3.0.0
2022-06-01T21:26:51.005Z - info: Using general timeout for rendering (reportTimeout: 600000)
2022-06-01T21:26:51.005Z - info: Using fs provider for template store.
2022-06-01T21:26:51.013Z - info: fs store is persisting using fs for /redacted/data
2022-06-01T21:26:51.024Z - info: fs store is loading data
2022-06-01T21:26:52.937Z - info: fs store is initialized successfully
2022-06-01T21:26:52.945Z - debug: studio default theme is: light
2022-06-01T21:26:52.969Z - info: Creating default express app.
2022-06-01T21:26:52.986Z - debug: Reading ssl certificate from /redacted/fullchain.cer
2022-06-01T21:26:52.998Z - info: jsreport server successfully started on https port: 5489
2022-06-01T21:26:53.005Z - info: Verifying license key free
2022-06-01T21:26:53.006Z - info: License key being verified and license key stored in /redacted/jsreport.license.json doesn't match, proce>
(node:2387678) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certifi>
(Use node --trace-warnings ... to show where the warning was created)
2022-06-01T21:26:53.599Z - info: License key verified as yearly subscription
2022-06-01T21:26:53.600Z - info: Storing license verification information to /redacted/jsreport.license.json
2022-06-01T21:26:53.603Z - debug: Creating samples is disabled
2022-06-01T21:26:53.604Z - info: Initializing worker threads
2022-06-01T21:26:53.604Z - debug: Extensions in workers: base, child-templates, components, data, express, handlebars, jsrender, localization, npm, pdf-utils, repo>
2022-06-01T21:26:53.819Z - info: 2 worker threads initialized in 215ms
2022-06-01T21:26:53.819Z - info: Starting temp files cleanup with 600000ms threshold
2022-06-01T21:26:53.820Z - info: reporter initialized
Actually i jumped the gun here in blaming it on jsreport. I turned the old server on and compared the results of:
https://oldserver:5489/odata/templates('WREPnPpjt5FaVlAu')
vs
https://newserver:5489/odata/templates('WREPnPpjt5FaVlAu')
and the old one is also malformed. Both return something like:
{
"0": {
"shortid": "Ssh0qJ_M1t",
"name": "Multiple Data Sources to XLSX",
"recipe": "html-to-xlsx",
"engine": "handlebars",
"chrome": { "printBackground": true },
"htmlToXlsx": { "htmlEngine": "chrome" },
"creationDate": "2021-02-12T22:16:32.865Z",
"modificationDate": "2022-03-21T21:02:06.922Z",
"_id": "WREPnPpjt5FaVlAu",
"data": { "shortid": "alzfT9oXW" },
"scripts": [ { "shortid": "YV1W9PMikJ" } ],
"content": "...",
"helpers": "...",
"folder": { "shortid": "sYpZKHs" }
},
"@odata.context": "https://192.168.7.198:5489/odata/$metadata#templates/$entity",
"value": [
{
"shortid": "Ssh0qJ_M1t",
"name": "Multiple Data Sources to XLSX",
"recipe": "html-to-xlsx",
"engine": "handlebars",
"chrome": { "printBackground": true },
"htmlToXlsx": { "htmlEngine": "chrome" },
"creationDate": "2021-02-12T22:16:32.865Z",
"modificationDate": "2022-03-21T21:02:06.922Z",
"_id": "WREPnPpjt5FaVlAu",
"data": { "shortid": "alzfT9oXW" },
"scripts": [ { "shortid": "YV1W9PMikJ" } ],
"content": "...",
"helpers": "...",
"folder": { "shortid": "sYpZKHs" }
}
]
}
I believe the corrrect odata response for a "by key" URL would be just:
{
"@odata.context": "https://192.168.7.198:5489/odata/$metadata#templates/$entity",
"shortid": "Ssh0qJ_M1t",
"name": "Multiple Data Sources to XLSX",
"recipe": "html-to-xlsx",
"engine": "handlebars",
"chrome": { "printBackground": true },
"htmlToXlsx": { "htmlEngine": "chrome" },
"creationDate": "2021-02-12T22:16:32.865Z",
"modificationDate": "2022-03-21T21:02:06.922Z",
"_id": "WREPnPpjt5FaVlAu",
"data": { "shortid": "alzfT9oXW" },
"scripts": [ { "shortid": "YV1W9PMikJ" } ],
"content": "...",
"helpers": "...",
"folder": { "shortid": "sYpZKHs" }
}
Turns out we also upgraded our server code from .net 3.1 to .net 6 and switched from newtonsoft the the microsoft json stuff, and something with that is causing the problem which i will track down. Sorry for the false alarm in my first post.
At some point it would be nice if jsreport returned valid odata responses for "by key" type queries but we can work around it for now.