Security and Governance: Section Access, Data Reduction, Connection Security, Governance of Published Data
Section access reduces data, it does not merely hide it
SECTION ACCESS is a control statement issued in its own LOAD (or SQL SELECT) statement and is normally placed at the very start of the script. It reads a table with uppercase field names: ACCESS (ADMIN or USER), an identification field (USERID/PASSWORD for local logins, NTNAME or GROUP for domain/SSO), and optional reduction fields. At least one ADMIN entry must retain full access, otherwise the app becomes unmanageable.
Reduction works by matching: the section access table joins to the data model on identically named fields, and each user sees only rows whose values match. * acts as a wildcard. If the reduction key is missing from the model or spelled differently, reduction silently fails - the user sees everything or nothing. OMIT FieldName hides columns for all users at once and cannot be varied per user. SECTION APPLICATION supports sharing a section access table across apps.
Expected traps: values are matched literally against the model, so inconsistent casing in the data causes empty or over-broad access (normalise with Upper() on both sides); a user absent from the table cannot open the app; and changes to section access require a reload and republish to take effect for consumers. Also govern the connection layer - data connections hold stored credentials that a section access consumer must never be able to view or reuse.
Rule of thumb: always verify section access by logging in as a real restricted user; opening the app as admin proves nothing.
Worked example: a row of USER, jdoe, 'SE' in a table with columns ACCESS, USERID, COUNTRY restricts jdoe to Swedish rows once COUNTRY exists in the model.