Two gaps found reviewing the pages against the code that is shipping:
- A derived variable cannot be named by an active row level security rule of
any scope - mpe_derived_postedit.sas rejects it, because rules are validated
against the physical table where a derived column does not exist. Neither the
derived variables page nor row-level-security.md said so.
- The startup failure modal's Show log button (#356, in this release) was not
documented anywhere. Added to troubleshooting, with why the browser request
is what gets the log on Viya.
On SAS 9 and Viya the app is reached through the platform's job URL, so
work.browser_url_vars carries the platform's parameters (_FILE, _program,
_debug, _webout) alongside DC's. Say so, so a hook author does not read
_FILE as a Data Controller parameter.
The adapter sends _debug=128 (not 131) on the Viya web JES path when
runAsTask is enabled, which is what the frontend uses there. Document
that value alongside 131, and note that editors/loadfile is reached
through the multipart file upload, which carries no input tables.
The support diagnostics are now sent only where they can be used: the
startup service and the services that execute customer-provided code
(hook scripts, dynamic cell dropdown programs) - not with every service
call. The page's URL parameters arrive as a new browser_url_vars table,
one row per parameter, so a SAS developer reads a parameter by name
rather than parsing the url string.
Every service call carries a single-row browser_info input table, readable
by any service or hook script as work.browser_info and dumped to the job log
when debug is on. Document its columns and how to see it, so a support ticket
can be answered from the log without follow-up questions.
dc
allan