Both images on the embed page were still captured from a local sandbox with the
editor as the top-level document, so neither showed the report around it.
- va-parmap-filtered.png: the report viewer, prompt DROPDOWN_TAB1 (relabelled on
the report, not matching any column) and SOME_DATE, with
FILTER : ( ( SOME_DROPDOWN = 'Option 1' AND SOME_DATE = '01JUL1960'd ) ) over
21 rows - the mapped parameter filtering a column that is not its name
- va-parmap-banner.png: the same object with a malformed entry
(va_parmap=SOME_DATE, no hyphen), showing the warning banner over a populated,
filtered grid
The caption for the mapping now says the date parameter beside it is
name-matched, which is what the picture shows.
va-parmap-transform.png is removed rather than replaced: the deployment used for
these captures predates the ADD/RANGE work, so there is no honest in-report
picture of a date anchor to take, and a sandbox capture would be the one image on
the page without the report around it. The section keeps the syntax, the anchors
and the examples table.
Captured from the report viewer at 1920x1100: two prompts (a value list and a
date), 21 rows returned by
FILTER : ( ( SOME_DROPDOWN = 'Option 1' AND SOME_DATE = '01JUL1960'd ) ).
- drops the header/FILTER crop, which had no VA chrome, and the sentence it
illustrated
- drops the "single row it matches" wording, which no longer describes the
picture
- documents the date clause as a code block instead of a second image
Replaces the three-parameter screenshot with a two-parameter one - a value
list and a date - and adds a zoomed crop of the DC header and FILTER line.
The date parameter arrives as a display date and is rendered as a SAS date
literal ('12FEB1960'd), the same as a date filter built inside Data
Controller. That is worth showing because VA's own prompt containers in the
report header show only the parameter label: the FILTER line is where the
selected values are legible.
Adds the two screenshots the embed page was missing, both captured from a
Viya deployment with Data Controller embedded as a data-driven content
object:
- three report parameters (SOME_CHAR, SOME_DROPDOWN, SOME_NUM) reaching one
object, with the combined FILTER line and the single matching row in the
editor
- the object's Options pane, showing the URL as a Web Content property
rather than a data source
Also documents two things that make an embedded object look broken when the
deployment is fine: the URL is an object property and the object needs no
data assigned, and an unlicensed / not yet accepted deployment shows its
licensing screen inside the object. The debugging section now says the
parameter label in the postMessage payload is the key va_parmap matches.
The route is hyphenated like the other multi-word docs paths (dcc-*, pre-edit-hook).
The page has not been published under /visualanalytics/, so only the embed-va
redirect map needs to point at the final path.
- rename docs/embed-va.md -> docs/visualanalytics.md, so the page is served
at /visualanalytics/
- redirect the old /embed-va/ path to the new one
- point the three inbound links (index, filter, deploy-viya) at the new path
- fill in og_title and og_image so link previews carry the page title and a
card image instead of the site defaults
- the object's author often has elevated permissions, not usually an admin
- the link to va-messaging.service.ts opened with a backtick and closed with a
quote, so it rendered as broken text
- the URL example was a plain URL wrapped in backticks inside a fenced block,
which shows the backticks; it is a text fence with the bare URL now
- restored the space the "updated- all from inside the same report" sentence lost
- closed the sentence about brush columns, and spelled out "primary key columns"
- two causes the banner reports were missing from the table: an entry with no
parameter before the "-", and a parameter mapped to two columns (the first
entry wins). Both come from parseVaParmap, so the table now covers every
message the banner can carry.
Checked against the merged code on release/7.20 (00df87f): the embed values and
their effects, the split at the last hyphen, the case-insensitive label match,
the plain-SAS-name rule, the anchor and period names, and the banner wording.
Tables are consistent, fences balanced, page is ASCII only, and both cross-links
(/filter/ and /developer-guide/browser-variables/) resolve.
Found by testing a report against a freshly configured instance: the DC
object showed its login card inside the report because the viewer's SAS
identity was not registered yet, which reads as a broken embed rather than
a permissions problem.
Replaces the two-sentence section with the steps a report author needs:
where the URL goes, that the parameter has to be bound into the object's
query or VA never sends it, and how to tell a working mapping from a broken
one when the report runs. Also drops the note about intnx argument names,
which was explaining a decision rather than the behaviour.
Screenshots taken against the demo estate with a licence key installed, so
no evaluation banner appears. The banner section now tabulates every cause
the editor reports, because the reader is the report author looking at the
Data Controller object and the URL is the only thing they can edit.
The SAS Visual Analytics Embed page now covers mapping report parameters to
DC columns from the URL, which the name-based match cannot do for two report
objects filtering the same column from differently-named parameters.
- new "Mapping parameters to columns" section: the `va_parmap` grammar, the
lower-case example, what overrides what, and the rules that matter to a
report author (last-hyphen split, label-then-name key matching, one parameter
to one column, no fallback to the name match)
- the warning banner is documented next to it, including that a parameter is
ignored rather than filtered on the wrong column
- the `?embed=` table now shows the Filter button per mode, so it is explicit
that `embed=true` keeps Data Controller's own filter builder while `embed=va`
hands filtering to the report
The publish job installed cloudron-surfer 6.4.1 and uploaded with a token; the
current major takes a Cloudron username plus an app password instead. Pin
@cloudron/surfer 7.2.0, user allan, password from SURFER_PASSWORD.
`deploy` rather than `put`: it swaps the site atomically, so a failed upload
leaves the current site serving, and it records the ref and commit in the site's
deploy history. The docs are a named site (`docs`) on its own alias domain, so
both are passed.
Also adds workflow_dispatch, so a deploy can be run by hand.
The 1920x900 captures left two thirds of each image as empty grid canvas, and
shrank the UI to about a third of its CSS size once the page rendered them at
content width - unreadable on a tablet. Re-taken at 1024 CSS px and captured at
2x device pixels, so they stay crisp on a retina screen, and clipped to just
below the data rows, so the image is mostly table.
The configuration still stays in the viewer: the EDIT screen adds a
current-version filter bar whose text is a macro expression.
The screenshots were taken on the mocked estate, before setvars began marking
computed columns with an fx badge, a tinted header and a left edge where the
derived block starts. They are re-taken against a real SAS backend, so the
images show what ships, and the page describes the marking.
The draft banner comes off both pages, the (draft) suffix off both nav entries,
and the roadmap gains its Delivered Features entry - all held until the release
lands.
Review 431: dc-overview.md still said "Up to 500 rows can be edited (in the web
editor) at one time" - the wrong number (DC_MAXOBS_WEBEDIT ships at 250) and, once
dc/dc#352 lands, the wrong behaviour (an over-limit selection is served truncated
with a warning, not refused or capped at a count). It now names both limits,
whichever binds first, and links to the options that set them.
Sweeping for the same stale figure turned up dcu-tableviewer.md, which says 500
twice and uses 500 in its worked example of the row count above the grid.
DC_MAXOBS_WEBVIEW has been 2000 since 20261003_row_and_cell_limits.sas (the
migration records 500 -> 2000), and mpe_makedata seeds 2000, so those three
places were two releases out of date. Fixed here, and flagged in the PR reply as
VIEW rather than EDIT in case it belongs in its own change.
Checked: no "500 rows" or stale abort wording left in docs/, and the two anchors
the overview now links to (dc_maxobs_webedit, dc_maxcells_webedit) exist on the
published options page.
browser_info and browser_url_vars were only described inside the troubleshooting
page, under Support Diagnostics. That is the right place to find them if you
already know they exist and are looking for a log line; it is not where anyone
looks when writing a hook, which is what they are mostly for.
The new Developer Guide page carries the whole subject: which services receive
the two tables, the column lists, the debug values per platform and the MPEINIT
log lines, reading them from a hook with the exist() guard, and the reminder that
they are client-supplied and so diagnostics rather than a security boundary.
Troubleshooting keeps three stub headings - browser_info, browser_url_vars,
reading-them-from-a-hook - pointing at the page, so the anchors that are already
published keep resolving, and the detail is not maintained twice.
Linked from the three places a hook author actually starts: the HOOK Scripts
section of the MPE_TABLES page, the pre-edit hook guide (where the editor's
inputs are listed), the two-rule-sets guide (post-edit hook), and the VA embed
page, where embed=va is exactly the kind of thing a hook wants to branch on.
VAR_LABEL is free text in any script and the quotes are escaped when the
statement is built, but it is a column label: control characters, line breaks and
over 256 characters are refused, the last of those because the engine would cut
the value down silently.
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.
The truncation is whichever of DC_MAXOBS_WEBEDIT and DC_MAXCELLS_WEBEDIT
binds first, and for a wide table it is the cell cap - floor(cells/columns)
rows, potentially far below the row limit. The hook page named only the row
cap and quoted its 250 default, so a hook author would check the row count
alone. Same correction in the two-rule-sets page.
getdata no longer refuses a selection over DC_MAXOBS_WEBEDIT or
DC_MAXCELLS_WEBEDIT - it serves the rows within the limit and flags the
truncation against the table name. Update the option reference and the two
developer-guide pages that claimed the edit screen stops with "Table is too
big". The hook page also carried the old 500 row default.
TX_FROM, TX_TO and PROCESSED_DTTM are the default names of the metadata
columns rather than reserved names - they are physical columns, refused by the
collision check whatever MPE_TABLES calls them. The only name refused outright
is the delete marker. The code now matches: the hard-coded list is gone.
There is no earlier: dependencies are declared in VAR_DEPS and checked in both
directions, so the rejection is an undeclared reference. Both sentences now say
so.
A warning banner on both pages, and '(draft)' in the navigation title, so a
reader is not surprised when the feature is not in their installed version.
Remove both when the release carrying derived variables goes out.
mkdocs build passes; the banner and all four images render.
The screenshots now show the whole page rather than a cropped viewport, and the
configuration table is included so the three variables in the grid can be
traced to the three rows that define them.
Three screenshots from the EDIT screen: the derived columns in the grid, a
filter on a character derived column, and a filter on a numeric one. Plus a
short 'how it works' explaining that the statements go into a DATA step view
because a WHERE cannot see a variable created in the same step.
Each row lists every input the expression uses, physical columns and derived
variables alike. No sequence number to maintain; statements are emitted in
dependency order and a cycle is rejected.
allan
dc