Quasar Selector Broken on tools/Entity/DataExport Screen

[acetousk]

Steps to Reproduce:

1. clone moqui-framework commit 722b9f2
2. get the following components: hivemind pm, hivemind admin, popc erp, my account, system, and tools
3. build and run with java -jar moqui.war
4. go to http://localhost:8080/qapps/tools/Entity/DataExport

What Happened

The selectors at the bottom of the page are all filled, and cannot be changed.

What Should Have Happened

In the vapps path: http://localhost:8080/vapps/tools/Entity/DataExport, the selectors only have one spot toggled. This should be what happens in the qapps path too.

[jonesde]

Thanks for reporting this. Here are some notes on my findings so far, don't have an answer yet so these are partially notes for myself (or others who might look into this).

The Entity/DataExport screen has a bit of a different sort of form in that when submitted it can result in a download (for Out to Browser) or server side for the other two Output options. That makes a difference for client rendered HTML with Quasar which is designed for client side processing and programmatic interaction with the server rather than the simple HTML form submit.

Most of the macros for the qvt render mode have variations in them for client side forms with data going to a JavaScript object (plain JS object, ie a map) with a m-form or m-form-link Vue component wrapper around them to handle the submit (for data submission or navigation), but in this case it generates a plain HTML form element with no Vue component wrapper. That's a problem because the Quasar q-radio Vue component does generate a input with type="radio" but does not maintain state in the DOM, it only maintains state via JavaScript (using Vue form functionality with v-model, etc) so a plain browser form submit won't work as it won't pick up those values. That is an issue in addition to it not maintaining state for the user to see, which is the symptom that is described here.

It might be possible to handle the download in JavaScript without relying on how browsers handle form submits using either a hidden iframe or createObjectURL() as described here:

https://stackoverflow.com/questions/3749231/download-file-using-javascript-jquery

This is a bit more of a pain for this particular form because the client doesn't know if it is a file to download or a response that tells the client to navigate to a screen (the same screen in this case). That might be possible with the hidden iframe approach but would be easier with the createObjectURL() approach. The downside to createObjectURL() is that it pulls the data into memory and might not work for large files (client memory limits). The hidden iframe would trigger the normal browser streaming download if the response is for a download, and for a JSON response telling the client to navigate it might work to look at the contents of the iframe after the data is downloaded to see if it contains such JSON.