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.
A derived variable can now be built on one with a lower VARIABLE_ORDER, so
the pages describe the order column, the ordered rule (replacing the
self-contained one) and a chained example.
Review follow-up: /dc-userguide/#editor (the heading is 'Editor'), the
reserved names include VAR_TXFROM/VAR_TXTO/VAR_PROCESSED, and derived
columns are not shown in VIEW or downloads though a saved filter on one
still applies there.
New Configuration page explaining derived (computed) variables: what they
are, how to configure them in MPE_DERIVED, how filtering works, the rules
and limits (expressions only, self-contained, read-only, not stored), and
the data-exposure and performance notes.
New MPE_DERIVED table page, registered in the Table Guide nav.
The clause shown above the grid is the resolved WHERE clause, so a date,
datetime or time filter reads as a SAS literal rather than the internal day or
second count. Note it on the filter page and on the MPE_FILTERSOURCE RAW_VALUE
column, which is where the value is stored.
The pre-edit hook example re-added _____DELETE__THIS__RECORD_____="No" when
it re-read the table, mirroring the data step getdata.sas used to run. That
column is created by the editor itself (it is the Delete? column) and is
never part of the dataset, so the example no longer adds it - and a response
that carries the name is refused by the editor, which the "What the hook
does" bullet now states.
Also notes the reserved name on the MPE_TABLES page, and says in the user
guide that the Delete? column is created by Data Controller rather than
being part of the table.
dc
allan