demo D108
Permissions in Angular
Column-level visibility and edit rights against a user context
permissions · context
This decides per column and per cell whether a given user can see a value and whether they can change it, against a user context. It lets one grid configuration serve several roles safely, so a finance column or an edit right appears only for the people entitled to it.
This is the Angular version. A standalone component takes the whole configuration through one config input, surfaces grid events as outputs, and exposes the live grid on a getter for anything the inputs do not cover.
The configuration
import { Component } from '@angular/core';
import { bootstrapApplication } from '@angular/platform-browser';
import { createGrid } from '@toclocoinc/lattice-grid';
import '@toclocoinc/lattice-grid/css';
import { LatticeGridComponent, provideLattice } from '@toclocoinc/lattice-grid/angular';
@Component({
selector: 'app-root',
standalone: true,
imports: [LatticeGridComponent],
template: '<lattice-grid [config]="grid" style="display:block;height:540px"></lattice-grid>',
})
export class AppComponent {
grid = {
rowKey: 'id',
selection: 'multiple',
edit: true,
context: { role: 'on-call engineer' },
permissions: {
default: 'read',
columns: { state: 'write', notes: 'write', onCall: 'writeOnly' },
resolve(column: any, params: any) {
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 */],
};
}
bootstrapApplication(AppComponent, {
providers: [provideLattice({ createGrid })],
});
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.