dc/docs.datacontroller.io
6
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(troubleshooting): scope the diagnostics tables to their services, add browser_url_vars

Browse Source 
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.
This commit is contained in:
dc
2026-09-25 00:21:56 +00:00
parent 2a65664a51
commit 7770737963
1 changed files with 23 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/dci-troubleshooting.md
+23 -6
View File
@@ -144,13 +144,17 @@ You can also determine the app version (and SASjs Version, and build time) by op
## Support Diagnostics
Every service call the frontend makes carries a single-row `browser_info` input table, available to the service (and to any [hook script](macros.md)) as `work.browser_info`. It records where the request came from, so a support ticket can be diagnosed from the job log without asking the user follow-up questions, and a hook can adapt to its context.
The frontend sends two input tables with the startup service and with the services that execute customer-provided code - the [hook scripts](macros.md) (pre/post edit and approve hooks) and the dynamic cell dropdown programs. They are available in those services as `work.browser_info` and `work.browser_url_vars`, so a support ticket can be diagnosed from the job log without asking the user follow-up questions, and a hook can adapt to its context. Other services do not receive them.
The table has these columns:
The services that receive the tables are: `public/startupservice`, `editors/getdata`, `editors/getdynamiccolvals`, `editors/stagedata`, `editors/loadfile`, `editors/restore` and `auditors/postdata`.
### browser_info
A single-row table with these columns:
| Column | Description |
|---|---|
| `url` | The URL of the Data Controller page itself (the iframe), not the document embedding it. When the editor is embedded in a report, any parameters the report author added to the embed URL are visible here. |
| `url` | The URL of the Data Controller page itself (the iframe), not the document embedding it. When the editor is embedded in a report, the embedding URL is visible here. |
| `referrer` | The embedding document, from `document.referrer`. For an embedded report this is the report URL, so the embedding report can be told apart from the editor URL. |
| `timezone` | The browser's IANA timezone name, e.g. `Europe/Berlin`. |
| `tz_offset` | The browser's UTC offset in minutes, as `Date.getTimezoneOffset()` returns it (positive west of UTC, so `Europe/Berlin` in summer is -120). |
@@ -162,15 +166,28 @@ The table has these columns:
| `platform` | The operating system, parsed from the user agent. |
| `user_agent` | The raw `navigator.userAgent` string. |
The values are supplied by the client, so treat them as diagnostics hints rather than a security boundary.
### browser_url_vars
To see the table, run any request with debug on (for example add `&_debug=131` to the service URL). The session initialisation then writes the row to the job log:
The page URL parameters as one row per parameter, so a SAS program can read a parameter by name rather than parse the `url` string:
| Column | Description |
|---|---|
| `name` | The URL parameter name. |
| `value` | The URL parameter value. |
Parameters from both the search string and the hash query string (Angular routes carry them after the `#`) are included; on a name collision the hash value wins. The table is sent only when the page URL has at least one parameter.
The values in both tables are supplied by the client, so treat them as diagnostics hints rather than a security boundary.
To see the tables, run any of the services above with debug on (for example add `&_debug=131` to the service URL). The session initialisation then writes them to the job log:
```
NOTE: MPEINIT: work.browser_url_vars:
name=embed value=va
NOTE: MPEINIT: work.browser_info:
url=... referrer=... timezone=Europe/Berlin tz_offset=-120 locale=en-GB
dc_version=7.15.0 adapter_version=4.19.0 browser=Chrome browser_version=120.0
platform=Linux user_agent=...
```
The table is sent by newer clients only. A service called directly (for instance from a URL, or by a script), or by an older frontend, has no `work.browser_info` - the log then records that fact instead.
A service called directly (for instance from a URL, or by a script), or by an older frontend, has no `work.browser_info` - the log then records that fact instead.