dc
fb38309e98
Three defects behind staging's "Invalid parent" and the picker that could not list a subfolder. Found by running the real mpe_dirlist on sas.4gl.io, not by reading it. 1. The browser host answers SYSSCPL "browser". The client looked for the first letter of a unix token (L/H/A/S) and fell through to the Windows default for anything else, so the deploy screen pre-filled C:\DataController on a POSIX runtime, which the server then refused as an invalid parent. Windows is now recognised by its own tokens (WIN, DNTHOST); anything else, including a value the list has never seen, gets the POSIX path. 2. mpe_dirlist emitted a non-blank parent's children at LEVEL 0, because mp_dirlist numbers a folder's contents with the folder's own level. The picker keeps LEVEL>0 for a non-root listing, so every row was discarded and a subfolder could never be browsed. The children are shifted to start at 1; a blank parent still lists the platform roots at 0. Verified on the estate: /tmp at DEPTH=1 returns levels [1], a blank parent returns [0, 1] (the root, then its children). 3. The mock's write probe generated one name and wrote it, truncating a file that was already called that; mpe_writecheck tries up to ten names with fileexist()=0 first. The mock now does the same and reports 'No free name for the write probe' when all ten are taken. The mock's DIRLIST now matches the estate's shape too: children at LEVEL 1, roots at 0 followed by their children, and the cap stops the walk at MAXOBS rather than slicing afterwards. Tests: 35 pass across the five mock suites (makedata-actions 15, two of them new: the probe collision and a folder that cannot be written to), sasjs lint clean, client spec 8/8 with the new platform cases and 2 failing without the fix.
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).