dc
c4eef498b2
Where a column carries a CASE=UPCASE or CASE=LOWCASE rule in
MPE_VALIDATIONS, the EDIT grid treated it as validation only: a value in
the other case was flagged after typing, so the user had to retype it or
accept a red cell and fix it later.
The pending value is now converted before it commits, driven by the rule
that already exists rather than a hard-coded column list:
- DcValidator.getCaseTransform(col) maps a CASE rule on the column to
'upper'/'lower' (the two rule values dq-validation.ts acts on).
- The existing beforeChange hook applies it alongside ROUND, so an edit, a
paste range and a fill-down all take the same path, the cursor and
selection stay put, and undo keeps its history.
- applyCaseTransform / isCaseTransformSkipped live in a small pure module
so the conversion and the source exclusions are testable directly.
Values are not converted when they are not user entry: loadData (the grid
re-sending its dataset on every updateSettings({data})), UndoRedo.undo /
redo, and the Revert menu item. Converting those would rewrite values the
service supplied, or hand back something other than the value the user
asked to restore, and would leave untouched rows looking modified.
A CASE-bearing column is marked in the header ('Aa' marker plus a tooltip)
so the user can tell the conversion came from the grid.
The CASE validation itself is unchanged: values from an API, staged data
or an Excel import are still validated as before.
Data Controller for SAS
Control your manual data modifications!
Alternatives to Data Controller include:
- 💾 Developing / testing / deploying / scheduling overnight batch jobs to load files from shared drives
- 🔒 Opening (and locking) datasets in Enterprise Guide or SAS® Table Viewer to perform direct updates
- ❓ Asking a #DBA to run validated code after a change management process
- 🌐 Building & maintaining your own custom web application
- 🏃 Running #SAS or #SQL updates in production
Problems with the above include:
- Legacy 'black box' solutions with little to no testing, documentation or support
- End users requiring direct write access to critical data sources in production
- Upload routines that must be manually modified when the data model changes
- Breaches due to unnecessary parties having access to the data
- Inability to trace who made a change, when, and why
- Reliance on key individuals to perform updates
- Building bespoke ETL for every new data source
- High risk of manual error / data corruption
Data Controller for SAS® solves all these issues in a simple-to-install, user-friendly, secure, documented, battle-tested web application. Available on Viya, SAS 9 EBI, and SASjs Server.
An individual Viya deploy can be done in just 2 lines of #SAS code!
filename dc url "https://git.datacontroller.io/dc/dc/releases/download/latest/viya.sas";
%inc dc;
For a multi-user deploy, using a shared system account, please see deploy docs.
For further information:
- Main site: https://datacontroller.io
- Docs: https://docs.datacontroller.io
- Code: https://code.datacontroller.io
For support, contact support@4gl.io or reach out on Matrix!
Development
Lighthouse CI
This project includes automated Lighthouse performance and accessibility checks that run on pull requests. The checks ensure:
- Accessibility Score: Minimum 1.0 (100%) median score across all tested pages
The Lighthouse CI workflow:
- Sets up the development environment with SASjs server and mocked services
- Builds and serves the Angular frontend
- Installs Chrome and runs
lhci autorun(Lighthouse CI) against key pages - Uploads results as artifacts for review
To run Lighthouse checks locally:
cd client
npm install
npm run lighthouse
Configuration is in client/lighthouserc.js (URL list, desktop preset, Chrome flags, assertions).