Build-and-test-development has been red on one Cypress assertion, and the assertion was wrong, not the client.
✖ derived-variables.cy.ts 5 tests, 4 passing, 1 failing
4 | a derived column is marked read-only, and opens no editor
AssertionError: expected '<th.dc-derived-header.darkTH>' to have class 'dc-derived-first'
What the grid actually does
Reproduced locally against a mock sasjs/server in desktop mode (RUN_TIMES=js, ng serve on :4200) and dumped the header row:
The marker is on LINE_VALUE, and that is right: the derived columns appear in MPE_DERIVED order, which for TESTDATA.DERIVED_DEMO is LINE_VALUE, REGION, REGION_LABEL. The spec's comment said "REGION is the first derived column, so it opens the computed block", and line 97 asserted that name.
The same dump against the unmodified release/7.19 client gives byte-identical output, so no client change was needed for this.
Change
The assertion now states the invariant instead of a column name:
cy.get('.ht_clone_top .htCore thead tr th').then(($ths)=>{constderived=[...$ths].filter((th)=>th.classList.contains('dc-derived-header'))expect(derived.length,'derived headers').to.be.greaterThan(0)expect(derived[0].classList.contains('dc-derived-first'),'the first derived header opens the block').to.be.truederived.slice(1).forEach((th)=>expect(th.classList.contains('dc-derived-first'),'only the first derived header carries the marker').to.be.false)})
It still fails if the marker is missing, if it lands on the wrong column, or if more than one column carries it - but it no longer depends on which variable the control table lists first.
Local mock estate: sasjs/server desktop mode, JS runtime, mocks deployed with sasjs cbd -t server-ci, app served by ng serve - the same shape as the pipeline step. No SAS changes.
`Build-and-test-development` has been red on one Cypress assertion, and the assertion was wrong, not the client.
```
✖ derived-variables.cy.ts 5 tests, 4 passing, 1 failing
4 | a derived column is marked read-only, and opens no editor
AssertionError: expected '<th.dc-derived-header.darkTH>' to have class 'dc-derived-first'
```
## What the grid actually does
Reproduced locally against a mock `sasjs/server` in desktop mode (`RUN_TIMES=js`, `ng serve` on :4200) and dumped the header row:
```
0 | | darkTH
1 | Delete? | firstColumnHeaderStyle darkTH
2 | ID | primaryKeyHeaderStyle darkTH
3 | STATE | darkTH
4 | QTY | darkTH
5 | PRICE | darkTH
6 | LINE_VALUE | dc-derived-header dc-derived-first darkTH
7 | REGION | dc-derived-header darkTH
8 | REGION_LABEL | dc-derived-header beforeHiddenColumn htLastVisibleHeader
```
The marker is on **LINE_VALUE**, and that is right: the derived columns appear in MPE_DERIVED order, which for `TESTDATA.DERIVED_DEMO` is LINE_VALUE, REGION, REGION_LABEL. The spec's comment said "REGION is the first derived column, so it opens the computed block", and line 97 asserted that name.
The same dump against the unmodified `release/7.19` client gives byte-identical output, so no client change was needed for this.
## Change
The assertion now states the invariant instead of a column name:
```ts
cy.get('.ht_clone_top .htCore thead tr th').then(($ths) => {
const derived = [...$ths].filter((th) => th.classList.contains('dc-derived-header'))
expect(derived.length, 'derived headers').to.be.greaterThan(0)
expect(derived[0].classList.contains('dc-derived-first'),
'the first derived header opens the block').to.be.true
derived.slice(1).forEach((th) =>
expect(th.classList.contains('dc-derived-first'),
'only the first derived header carries the marker').to.be.false)
})
```
It still fails if the marker is missing, if it lands on the wrong column, or if more than one column carries it - but it no longer depends on which variable the control table lists first.
## Verification
```
Running: derived-variables.cy.ts
5 passing (1m)
✔ All specs passed! 5 5 - - -
```
Local mock estate: `sasjs/server` desktop mode, JS runtime, mocks deployed with `sasjs cbd -t server-ci`, app served by `ng serve` - the same shape as the pipeline step. No SAS changes.
derived-variables.cy.ts:97 expected dc-derived-first on the REGION header,
because the comment assumed REGION opens the computed block. The grid follows
MPE_DERIVED order, and that order is LINE_VALUE, REGION, REGION_LABEL - so the
marker was on LINE_VALUE and correct. The spec asserted the wrong column, and
the development pipeline has been red on it since.
Dumping the header row on a local mock estate (sasjs/server desktop mode,
RUN_TIMES=js) shows:
6 | LINE_VALUE | dc-derived-header dc-derived-first
7 | REGION | dc-derived-header
8 | REGION_LABEL | dc-derived-header beforeHiddenColumn htLastVisibleHeader
and the same dump against the unmodified release/7.19 client, so this was never
a client defect.
The assertion now states the invariant instead: at least one derived header, the
first of them opens the block, and no other one carries the marker. That holds
whatever order the control table returns the variables in.
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.
Build-and-test-developmenthas been red on one Cypress assertion, and the assertion was wrong, not the client.What the grid actually does
Reproduced locally against a mock
sasjs/serverin desktop mode (RUN_TIMES=js,ng serveon :4200) and dumped the header row:The marker is on LINE_VALUE, and that is right: the derived columns appear in MPE_DERIVED order, which for
TESTDATA.DERIVED_DEMOis LINE_VALUE, REGION, REGION_LABEL. The spec's comment said "REGION is the first derived column, so it opens the computed block", and line 97 asserted that name.The same dump against the unmodified
release/7.19client gives byte-identical output, so no client change was needed for this.Change
The assertion now states the invariant instead of a column name:
It still fails if the marker is missing, if it lands on the wrong column, or if more than one column carries it - but it no longer depends on which variable the control table lists first.
Verification
Local mock estate:
sasjs/serverdesktop mode, JS runtime, mocks deployed withsasjs cbd -t server-ci, app served byng serve- the same shape as the pipeline step. No SAS changes.