Two changes to developer-guide/filter-pre-edit-hook.md, which merged in #16:
A "What it looks like" section with a before/after pair of the editor, so the page shows the outcome as well as the mechanism.
A correction to the re-read step (review finding on #16): the example now drops &drop_rk alongside the transaction and processing columns, and the note records that a bitemporal table also needs getdata's latest-record dedup. The previous wording claimed the step mirrored getdata while missing both.
How the images were produced
Captured from the mocked estate (the usual source for docs images), driving the streamed app with a throwaway Cypress spec:
a demo table (TESTDATA.DEMO_ORDERS) with an ORDER_DATE column and rows spanning two quarters;
a stored filter on ORDER_DATE (the user's own filter, one quarter);
for the "after" shot, the mock's editors/getdata reproducing the hook's effect - widen the date filter to the previous quarter, taking the reference date from the rows the filter returned, and return the widened FILTER_TEXT.
The JS mock cannot execute a SAS hook, so the mock emulates the hook's logic for the capture; the images illustrate the outcome, they are not a run of the SAS example. Both captures are 1920x900, no free-tier banner, and the Handsontable evaluation notice the stale mock build renders in its status bar was hidden for the shot (it is a mock-build artefact, not a Data Controller state).
Verification
mkdocs build --clean succeeds; both images resolve from /img/ and render on the page.
The before/after pair was read back from the captured PNGs: the info bar goes from (( ORDER_DATE >= "01JUL2026"d )) with 5 rows to (( ORDER_DATE >= "01JUL2026"d ) OR (ORDER_DATE between "01APR2026"d and "30JUN2026"d)) with 8 rows.
## What
Two changes to `developer-guide/filter-pre-edit-hook.md`, which merged in #16:
1. **A "What it looks like" section** with a before/after pair of the editor, so the page shows the outcome as well as the mechanism.
2. **A correction to the re-read step** (review finding on #16): the example now drops `&drop_rk` alongside the transaction and processing columns, and the note records that a bitemporal table also needs getdata's latest-record dedup. The previous wording claimed the step mirrored `getdata` while missing both.
## How the images were produced
Captured from the mocked estate (the usual source for docs images), driving the streamed app with a throwaway Cypress spec:
- a demo table (`TESTDATA.DEMO_ORDERS`) with an `ORDER_DATE` column and rows spanning two quarters;
- a stored filter on `ORDER_DATE` (the user's own filter, one quarter);
- for the "after" shot, the mock's `editors/getdata` reproducing the hook's effect - widen the date filter to the previous quarter, taking the reference date from the rows the filter returned, and return the widened `FILTER_TEXT`.
The JS mock cannot execute a SAS hook, so the mock emulates the hook's logic for the capture; the images illustrate the outcome, they are not a run of the SAS example. Both captures are 1920x900, no free-tier banner, and the Handsontable evaluation notice the stale mock build renders in its status bar was hidden for the shot (it is a mock-build artefact, not a Data Controller state).
## Verification
- `mkdocs build --clean` succeeds; both images resolve from `/img/` and render on the page.
- The before/after pair was read back from the captured PNGs: the info bar goes from `(( ORDER_DATE >= "01JUL2026"d ))` with 5 rows to `(( ORDER_DATE >= "01JUL2026"d ) OR (ORDER_DATE between "01APR2026"d and "30JUN2026"d))` with 8 rows.
- Adds a "What it looks like" section to the pre-edit hook page: the editor
before (the user's own filter, one quarter of rows) and after (the hook's
widened filter, both quarters), captured from the mocked estate.
- Corrects the re-read step: it now drops &drop_rk like getdata does, and the
accompanying note records that a bitemporal table also needs the latest-record
dedup, so the example no longer claims to mirror getdata exactly while missing
both (raised in review of #16).
The before/after pair added to the page:
**Before** - the user's own filter, 5 rows:
**After** - the hook's widened filter, 8 rows:
Reviewed the full diff (the filter-pre-edit-hook.md edits and both new PNGs); claims cross-checked against the getdata service source (sas/sasjs/services/editors/getdata.sas on dc/dc main) and the site built from the PR head.
docs/developer-guide/filter-pre-edit-hook.md:103 - the re-read step now copies getdata's drop list but not its sort. getdata runs proc sort data=work.out; by &sortpk; before the pre-edit hook and does not re-sort afterwards, so this step hands the editor rows in source order rather than the &sortpk order the user first saw. Add proc sort data=work.out; by &sortpk; run; after the re-read (&sortpk is declared %global in getdata and set before the hook runs, so it resolves in hook scope), or note the gap in the bullet at line 128 the same way the bitemporal dedup is noted.
.pre-commit-config.yaml (absent at the PR head) - the repo has no gitleaks pre-commit hook. Add one with the gitleaks hook pinned to an exact release tag (e.g. repo: https://github.com/gitleaks/gitleaks, rev: v8.30.1 at the time of writing, id: gitleaks), so staged content is scanned at commit time.
2 findings above for review.
Reviewed the full diff (the filter-pre-edit-hook.md edits and both new PNGs); claims cross-checked against the getdata service source (sas/sasjs/services/editors/getdata.sas on dc/dc main) and the site built from the PR head.
- docs/developer-guide/filter-pre-edit-hook.md:103 - the re-read step now copies getdata's drop list but not its sort. getdata runs `proc sort data=work.out; by &sortpk;` before the pre-edit hook and does not re-sort afterwards, so this step hands the editor rows in source order rather than the &sortpk order the user first saw. Add `proc sort data=work.out; by &sortpk; run;` after the re-read (`&sortpk` is declared %global in getdata and set before the hook runs, so it resolves in hook scope), or note the gap in the bullet at line 128 the same way the bitemporal dedup is noted.
- .pre-commit-config.yaml (absent at the PR head) - the repo has no gitleaks pre-commit hook. Add one with the gitleaks hook pinned to an exact release tag (e.g. `repo: https://github.com/gitleaks/gitleaks`, `rev: v8.30.1` at the time of writing, `id: gitleaks`), so staged content is scanned at commit time.
2 findings above for review.
- The re-read step now sorts work.out by &sortpk after rebuilding it, matching
getdata (which sorts before the hook runs and does not sort again), so the
grid keeps the order the user first saw. The bullet records why.
- Adds a .pre-commit-config.yaml with the gitleaks hook pinned to v8.30.1, so
staged content is scanned at commit time.
The re-read step now sorts work.out by &sortpk after rebuilding it, matching getdata (which sorts before the hook runs and does not sort again afterwards), so the grid keeps the order the user first saw. The bullet at :128 records why.
.pre-commit-config.yaml added at the repo root, with the gitleaks hook pinned to v8.30.1.
mkdocs build --clean is clean and the built page carries both changes.
Both findings addressed in 9d48240.
- The re-read step now sorts `work.out` by `&sortpk` after rebuilding it, matching getdata (which sorts before the hook runs and does not sort again afterwards), so the grid keeps the order the user first saw. The bullet at :128 records why.
- `.pre-commit-config.yaml` added at the repo root, with the gitleaks hook pinned to `v8.30.1`.
`mkdocs build --clean` is clean and the built page carries both changes.
allan
merged commit cc2441fd2d into main2026-10-15 17:57:19 +00:00
allan
deleted branch docs/pre-edit-hook-images2026-10-15 17:57:20 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
hermes
What
Two changes to
developer-guide/filter-pre-edit-hook.md, which merged in #16:&drop_rkalongside the transaction and processing columns, and the note records that a bitemporal table also needs getdata's latest-record dedup. The previous wording claimed the step mirroredgetdatawhile missing both.How the images were produced
Captured from the mocked estate (the usual source for docs images), driving the streamed app with a throwaway Cypress spec:
TESTDATA.DEMO_ORDERS) with anORDER_DATEcolumn and rows spanning two quarters;ORDER_DATE(the user's own filter, one quarter);editors/getdatareproducing the hook's effect - widen the date filter to the previous quarter, taking the reference date from the rows the filter returned, and return the widenedFILTER_TEXT.The JS mock cannot execute a SAS hook, so the mock emulates the hook's logic for the capture; the images illustrate the outcome, they are not a run of the SAS example. Both captures are 1920x900, no free-tier banner, and the Handsontable evaluation notice the stale mock build renders in its status bar was hidden for the shot (it is a mock-build artefact, not a Data Controller state).
Verification
mkdocs build --cleansucceeds; both images resolve from/img/and render on the page.(( ORDER_DATE >= "01JUL2026"d ))with 5 rows to(( ORDER_DATE >= "01JUL2026"d ) OR (ORDER_DATE between "01APR2026"d and "30JUN2026"d))with 8 rows.The before/after pair added to the page:
Before - the user's own filter, 5 rows:
After - the hook's widened filter, 8 rows:
Reviewed the full diff (the filter-pre-edit-hook.md edits and both new PNGs); claims cross-checked against the getdata service source (sas/sasjs/services/editors/getdata.sas on dc/dc main) and the site built from the PR head.
proc sort data=work.out; by &sortpk;before the pre-edit hook and does not re-sort afterwards, so this step hands the editor rows in source order rather than the &sortpk order the user first saw. Addproc sort data=work.out; by &sortpk; run;after the re-read (&sortpkis declared %global in getdata and set before the hook runs, so it resolves in hook scope), or note the gap in the bullet at line 128 the same way the bitemporal dedup is noted.repo: https://github.com/gitleaks/gitleaks,rev: v8.30.1at the time of writing,id: gitleaks), so staged content is scanned at commit time.2 findings above for review.
Both findings addressed in
9d48240.work.outby&sortpkafter rebuilding it, matching getdata (which sorts before the hook runs and does not sort again afterwards), so the grid keeps the order the user first saw. The bullet at :128 records why..pre-commit-config.yamladded at the repo root, with the gitleaks hook pinned tov8.30.1.mkdocs build --cleanis clean and the built page carries both changes.