Hi,

we have templates in folders like this:

in test.template, I use the localize function:

{{localize "test" "./translations"}}

The following request to /api/report succeeds on jsreport 3.0.1:

{     
      "template": { "name" : "/testfolder/test.template" },
      "data" : { "test": "bar" },
      "options": {
          "localization": {
              "language": "en"
          }
      }
}

However, on jsreport 3.1.1 it fails with this error:

{
    "message": "Error when evaluating engine handlebars for template /testfolder//testfolder/test.template\nlocalize helper couldn't find asset with data at translations/en.json",
    "stack": "Error: localize helper couldn't find asset with data at translations/en.json\n    at Object.localize (/app/node_modules/@jsreport/jsreport-localization/lib/worker.js:42:17)"
}

Am I doing something wrong? Apparently, the localize helper can't resolve the relative folder reference any more. Thanks in advance!

(see attached export file sorry, I can't seem to upload non-image files)

Thanks for your update!

there is no global jsreport-cli because we thought it isn't common to call it inside the container.

Frankly, I don't know whether it is common, I just need an image to run it on, and the jsreport image seemed like the obvious choice (we run all build steps in docker containers in our gitlab pipelines).

So we'll wait for the next release, thanks.

I've found that in the jsreport:3.1.1 image, jsreport-cli is installed but not on the path, however, I'm still getting the same error with that:

/app # /app/node_modules/@jsreport/jsreport-cli/cli.js --version
jsreport version: 3.1.1
cli version: 3.0.0
/app # /app/node_modules/@jsreport/jsreport-cli/cli.js export export.jsrexport 
A critical error occurred while trying to execute the export command: An error has occurred when trying to initialize jsreport (2). function Format(options = {}) {
    this.options = options;
  } could not be cloned. (1). 
caused by error (2):
-> meta = {"code":25}
-> stack
Error:
    at /app/node_modules/@jsreport/jsreport-cli/lib/instanceHandler.js:31:29
    at async exports.handler (/app/node_modules/@jsreport/jsreport-import-export/cli/export.js:155:5)
    at async Commander.executeCommand (/app/node_modules/@jsreport/jsreport-cli/lib/commander.js:244:22)
caused by error (1):
-> stack
DataCloneError: function Format(options = {}) {
    this.options = options;
  } could not be cloned.
    at new Worker (node:internal/worker:235:17)
    at createWorker (/app/node_modules/@jsreport/advanced-workers/lib/workersManager.js:14:20)
    at createWorker (/app/node_modules/@jsreport/advanced-workers/lib/workersManager.js:33:29)
    at /app/node_modules/@jsreport/advanced-workers/lib/pool.js:15:26
    at /app/node_modules/@jsreport/advanced-workers/lib/pool.js:20:52
    at Array.map (<anonymous>)
    at Object.init (/app/node_modules/@jsreport/advanced-workers/lib/pool.js:20:42)
    at Object.init (/app/node_modules/@jsreport/advanced-workers/lib/workersManager.js:37:24)
    at MainReporter.init (/app/node_modules/@jsreport/jsreport-core/lib/main/reporter.js:256:34)
    at async exports.handler (/app/node_modules/@jsreport/jsreport-import-export/cli/export.js:155:5)

I upgraded my jsreport image to 3.1.1, however, the latest version of jsreport-cli is still 2.2.5 as far as I can tell, and it still has the same problem.

/ # npm install -g @jsreport/jsreport-cli
[...]
/ # npm view jsreport-cli version
2.2.5

There does not seem to be a preinstalled jsreport-cli tool on the image? Or is there a way to do this from the container shell without installing/using jsreport-cli?

Hi, I'm trying to create an export file as suggested in https://jsreport.net/learn/fs-store#deployment

I want to do this in my build pipeline, and my approach is to take the latest jsreport docker image (3.0.1) and install jsreport-cli in it, copy my template files to the /app/data directory, and then run the export from the /app directory; however, I'm getting this error no matter what I try:

/app # jsreport export /tmp/export-full.jsrexport
A critical error occurred while trying to execute the export command: An error has occurred when trying to initialize jsreport (2). function Format(options = {}) {
    this.options = options;
  } could not be cloned. (1). 
caused by error (2):
-> meta = {"code":25}
-> stack
Error:
    at /app/node_modules/@jsreport/jsreport-cli/lib/instanceHandler.js:31:29
    at async exports.handler (/app/node_modules/@jsreport/jsreport-import-export/cli/export.js:155:5)
    at async Commander.executeCommand (/app/node_modules/@jsreport/jsreport-cli/lib/commander.js:244:22)
caused by error (1):
-> stack
DataCloneError: function Format(options = {}) {
    this.options = options;
  } could not be cloned.
    at new Worker (node:internal/worker:235:17)
    at createWorker (/app/node_modules/@jsreport/advanced-workers/lib/workersManager.js:14:20)
    at createWorker (/app/node_modules/@jsreport/advanced-workers/lib/workersManager.js:33:29)
    at /app/node_modules/@jsreport/advanced-workers/lib/pool.js:15:26
    at /app/node_modules/@jsreport/advanced-workers/lib/pool.js:20:52
    at Array.map (<anonymous>)
    at Object.init (/app/node_modules/@jsreport/advanced-workers/lib/pool.js:20:42)
    at Object.init (/app/node_modules/@jsreport/advanced-workers/lib/workersManager.js:37:24)
    at MainReporter.init (/app/node_modules/@jsreport/jsreport-core/lib/main/reporter.js:255:34)
    at async exports.handler (/app/node_modules/@jsreport/jsreport-import-export/cli/export.js:155:5)
    at async Commander.executeCommand (/app/node_modules/@jsreport/jsreport-cli/lib/commander.js:244:22)

I also tried initializing a separate directory using jsreport init and installing and exporting the templates from there, with the same result.

What am I doing wrong? Thanks in advance!

Hi,

here: https://jsreport.net/learn/import-export the documentation says "Important - make sure the multipart key for uploaded zip is import.zip"

The jsreport studio UI appears to be using "import.jsrexport" as key.

We're importing stuff via the import API from a java client, and it appears that the key actually doesn't matter at all. Anything works.

Can you clarify this? I'm using jsreport 3.0.1. Thanks in advance!

FYI, it works for me now, thanks.

OK, thanks for the update!

Great, thanks. Do you have an issue number so I can track it? Or will you update here?

Hi, I am creating a folder with an asset using a java client generated from jsreport's odata metadata. I am currently using jsreport 3.0.0 beta2. I am running into a problem where the asset is visible in the jsreport UI, but it can not be found when I try to access it in javascript, namely using the new localization API; I am creating a "translations" folder with an asset "en.json" in it. If I do this in the UI, everything works normaly. If I create it using the API, it looks the same in the UI, but when I call localize("key", "translations"), I get the error: "localize helper couldn't find asset with data at translations/en.json".

Debugging this issue, I found the following, and I am not sure whether this is a bug in jsreport or maybe in my client.

To create the asset, I first create a folder, then get the shortid of the created folder, and then create the asset with a folderRef with that shortid. The generated client sends the FolderRef like this:

"folder":{"@odata.type":"jsreport.FolderRefType","shortid":"Cry5U0_"}

So when I get the asset via the odata api, the whole object looks like this:

{
  "name": "en.json",
  "content": "eyJsYW5ndWFnZSI6IkVuZ2xpc2gifQ==",
  "folder": {
    "@odata.type": "jsreport.FolderRefType",
    "shortid": "Cry5U0_"
  },
  "creationDate": "2021-09-07T04:37:24.470Z",
  "modificationDate": "2021-09-07T04:37:24.470Z",
  "shortid": "kJi37GJ",
  "inheritedReadPermissions": [],
  "inheritedEditPermissions": [],
  "_id": "S9Pd9yn3R6Gy97Mi"
}

However, if I create the same asset with the same content in the UI, it looks almost all the same, just that the folder does not have the "@odata.type" property - and then it works. Seeing that, I modified my generated client code so that it does not send the folder.@odata.type property, and indeed, then it works. Looking ad the odata spec, I think the @odata.type property should actually be included, and I would expect it to work.

What do you think / am I doing something wrong? Thanks in advance!