The clause shown above the grid is the resolved WHERE clause that was applied, so a date, datetime or time filter reads as a SAS literal (eg SOME_DATE = '20APR2042'd) rather than the internal day or second count.
docs/filter.md - a note on the filter page, where the clause is described.
docs/tables/mpe_filtersource.md - the RAW_VALUE column entry, since that is where the value is stored.
Both are wording only; no behaviour is documented that the product does not already do.
Documents dc/dc #288.
The clause shown above the grid is the resolved `WHERE` clause that was applied, so a date, datetime or time filter reads as a SAS literal (eg `SOME_DATE = '20APR2042'd`) rather than the internal day or second count.
- `docs/filter.md` - a note on the filter page, where the clause is described.
- `docs/tables/mpe_filtersource.md` - the `RAW_VALUE` column entry, since that is where the value is stored.
Both are wording only; no behaviour is documented that the product does not already do.
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.
Reviewed the full diff at bef7a44 (docs/filter.md:12 and docs/tables/mpe_filtersource.md:20) against the companion client change in dc/dc #344.
docs/tables/mpe_filtersource.md:20 - the new RAW_VALUE description ("A date, datetime or time is stored as a SAS literal") documents MPE_FILTERSOURCE table state that dc/dc #344 writes client-side; as reviewed there, the pinned %mp_filtercheck behind public/validatefilter and public/getcolvals still rejects date literals, so until #344's backend half lands (or the client stores the internal number), the documented save aborts on real SAS. Merge this with, or after, a backend-capable revision of #344 rather than ahead of it.
1 finding above for review.
Reviewed the full diff at bef7a44 (docs/filter.md:12 and docs/tables/mpe_filtersource.md:20) against the companion client change in dc/dc #344.
- docs/tables/mpe_filtersource.md:20 - the new RAW_VALUE description ("A date, datetime or time is stored as a SAS literal") documents MPE_FILTERSOURCE table state that dc/dc #344 writes client-side; as reviewed there, the pinned %mp_filtercheck behind public/validatefilter and public/getcolvals still rejects date literals, so until #344's backend half lands (or the client stores the internal number), the documented save aborts on real SAS. Merge this with, or after, a backend-capable revision of #344 rather than ahead of it.
1 finding above for review.
allan
merged commit b7794cef47 into main2026-10-18 09:58:08 +00:00
allan
deleted branch docs/filter-date-literals2026-10-18 09:58:08 +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
Documents dc/dc #288.
The clause shown above the grid is the resolved
WHEREclause that was applied, so a date, datetime or time filter reads as a SAS literal (egSOME_DATE = '20APR2042'd) rather than the internal day or second count.docs/filter.md- a note on the filter page, where the clause is described.docs/tables/mpe_filtersource.md- theRAW_VALUEcolumn entry, since that is where the value is stored.Both are wording only; no behaviour is documented that the product does not already do.
Reviewed the full diff at
bef7a44(docs/filter.md:12 and docs/tables/mpe_filtersource.md:20) against the companion client change in dc/dc #344.1 finding above for review.