Hi Lee,

Please file a report for this with the WRC. That's a bug in the range validation. Both the

<path>.CURRENTMEMBER
<path>.CURRENTMEMBER.LAG(x)

should be identified as a member identifier.

Hello,

For your embedding question, there are a number of URL parameters (eg: EMBED=1) that controls what the user can do in the User Portal. The EMBED parameter is the most complete where users are not allowed to modify any dashboard definitions and none of the navigation is available, designed precisely for your use case. You can test this directly when you are looking at the DashboardViewer to get the settings you like best. 
The complete list of those parameters is here:
https://docs.intersystems.com/iris20211/csp/docbook/DocBook.UI.Page.cls?KEY=D2IMP_ch_dashboards

Delegated authentication would be part of the overall security login configuration. The key here is that whatever role gets assigned will need %DeepSee_Portal to e able to use the DashboardViewer. The overview of delegated authentication is here:
https://docs.intersystems.com/iris20211/csp/docbook/DocBook.UI.Page.cls?KEY=GAUTHN_delegated

Depending on your particular security model it might be worth contacting the WRC to confirm you have the login set up correctly.

Hello Lee, The error you are seeing here is actually coming from failed evaluation of the CURRENTMEMBER, which is probably having trouble finding the correct context imposed by the NOW-x in the background.

What version was this in?

As mentioned previously, there was a known issue in the handoff to background processing that has been corrected which might be the solution to your situation. I would recommend filing this with the WRC in order to investigate your options in more detail. Generically speaking, everything you are quoting regarding the NOW syntax specifically should be supported, including references with or without the ampersand and the use of LAG/LEAD/PREVMEMBER/etc functions hung off the NOW references.

Hi Megumi,

The worst-case scenario during the cube build would be the fact that the update to the source needs exclusive lock to perform the update, and the cube build will be taking out a read lock. This is a pretty standard SQL concurrency consideration. Your question also mentions listings, which wouldn't have any effect on the cube build since those are only run by the user when querying.

The bigger question is whether or not a DataConnector is actually needed. It takes a bit of extra work to make DataConnectors work with listings, most notably the use of <sql> is not sufficient to make listings work. The full instructions for creating ataConnectors that support listings can be found here:
http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=D2IMP_ch_connector#D2IMP_connector_callback

If the goal is to use a restricted view of the a single source table, adding a Build Restriction to the cube is far preferable to using a DataConnector. Implmenting the %OnProcessFact callback in the cube is also a good option.
http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=D2MODADV_ch_advanced#D2MODADV_advanced_restricting_records
If these can accomplish the task, they should be used. DataConnectors are only truly necessary when tables are JOINed or UNIONed to manufacture a logical dataset that is not a subset of a single existing source table.

Hi Jeff,

The component you are referring to is the %ZEN.ComponentEx.svgImageProvider. This is extended for printing in DeepSee by the %DeepSee.Component.deepseeSvgImageProvider. The latter adds some DeepSee-specific tools for converting certain HTML tables to SVG documents for printing the pivotTable component and ZEN chart legends.

The %ZEN version is the utility that handles the creation of an XSL-FO file containing the SVG gathered from the browser's DOM, and then invokes the FOP engine on the server to convert that XSL-FO to a PDF.

In it's most basic usage, you can print the SVG content of the chart from DeepSee's Basic Dashboard demo using this sample code in the Developer Tools console:

util = zenPage.getComponentById("svgUtil")
inFile = util.makeSVGFileName("infile.xsl")
parms = {}
parms.fileName = inFile
util.saveToXSLFile('$widget_2/svgFrame',parms)
outFile = util.makeSVGFileName("outfile.pdf")
util.ConvertXSLToPDF(inFile,outFile)

The parms object can be used to insert arbitrary svg content before and after the target content from the DOM using 

parms.svgIntro
parms.svgCoda

Simlarly, arbitrary fo can be inserted before and after the complete SVG content (svgIntro + userContent + svgCoda) using 

foIntro
foCoda

It is worth noting that this component does not allow for placement of temp files anywhere other than the install's <installDir>/mgr/Temp directory. The output pdf file is considered a temporary file that should be opened and saved by the user using any client capable of handling the file. For the DeepSee example, "printing" means performing an elaborate version of the above sample script and then openeing that temporary pdf to the user in the browser, where the user may save it to any location. The .xsl and .pdf files are deleted from <installDir>/mgr/Temp once the page successfully loads in the browser.

Regards,
Dan