demo D108
Permissions
Column-level visibility and edit rights against a user context
permissions · context
The configuration
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@toclocoinc/lattice-grid@1.13.0/lattice-grid.min.css">
<script src="https://cdn.jsdelivr.net/npm/@toclocoinc/lattice-grid@1.13.0/lattice-grid.min.js"></script>
<div id="grid" style="height: 540px"></div>
<script>
const grid = LatticeGrid.createGrid(document.getElementById('grid'), {
rowKey: 'id',
selection: 'multiple',
edit: true,
// Permissions are evaluated against this, and grid.permissions.setContext()
// re-evaluates every column when the user changes.
context: { role: 'on-call engineer' },
// A usability control, not a security boundary. Hidden data is still resident
// in the store and reachable from the console, so the same policy has to be
// enforced by whatever serves the rows.
permissions: {
default: 'read',
columns: {
// The two an on-call engineer is expected to correct.
state: 'write',
notes: 'write',
// Present and editable, never shown, never exported, never copied.
onCall: 'writeOnly',
},
resolve(column, params) {
const finance = params?.context?.role === 'finance';
if (column.id === 'monthlyCost' || column.id === 'budget') {
return finance ? 'read' : 'hidden';
}
return undefined;
},
},
columns: [
{ field: 'service', title: 'Service', layout: { pin: 'start', width: 160 } },
{ field: 'team', title: 'Team', filter: { type: 'set' } },
{ field: 'state', title: 'State', cell: { decoration: 'dot', variant: { map: { healthy: 'success', degraded: 'warning', failing: 'danger', unknown: 'neutral' } } } },
{ field: 'region', title: 'Region', filter: { type: 'set' } },
{ field: 'onCall', title: 'On call' },
{ field: 'openIncidents', title: 'Incidents', type: 'number' },
{ field: 'monthlyCost', title: 'Monthly cost', type: 'number', format: { style: 'currency', currency: 'USD' } },
{ field: 'budget', title: 'Budget', type: 'number', format: { style: 'currency', currency: 'USD' } },
{ field: 'notes', title: 'Notes', layout: { flex: 1, min: 200 } },
],
rows, // service records
});
</script>Column-level permissions: controlling visibility and edit rights per user
Permissions decide, per column and per cell, whether a given user can see a value at all and whether they can change it once they can. A developer reaches for this wherever one grid serves several roles from the same configuration: a finance view where a manager edits approved budgets but an analyst only reads them, or a support console where agents see a customer record but not the fields a compliance team reserves for itself. Lattice Grid resolves this through permissions evaluated against a context object describing the current user, so the same column definition can hide a “Salary” column from most viewers, show it read-only to a second group and leave it editable for a third, all from one rule set rather than three separate grids. Because the check runs against the user context already held in memory rather than a round trip per cell, applying permissions to a column-level visibility and edit-rights model built as a JavaScript data grid adds no measurable cost to scrolling or rendering at scale. The cell context menu reads the same rules, so an item that writes to a cell is never offered where that cell cannot be written, keeping the interaction consistent with the underlying access control rather than trusting the UI to enforce it separately.
How do I restrict which columns a user can see or edit in a data grid?
Define a permissions function that Lattice Grid evaluates against a context describing the current user, returning visibility and edit rights per column or per cell. The grid hides columns the context does not permit, marks permitted-but-read-only columns as non-editable, and keeps menus and keyboard editing in step with the same rules, so access control is declared once rather than checked separately in each interaction path.