Lattice Grid Buy a licence

demo D108

Permissions in React

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.

Building…
Loading a live grid…

This is the React version. The grid mounts through the createLatticeGrid adapter, which takes its configuration as ordinary props and hands back the live grid through a ref. The grid below is the same one every other tab runs.

The configuration

<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@toclocoinc/lattice-grid@1.71.0/lattice-grid.min.css">

<div id="grid"></div>

<script type="module">
  import React from 'https://esm.sh/react@18';
  import { createRoot } from 'https://esm.sh/react-dom@18/client';
  import { createGrid } from 'https://cdn.jsdelivr.net/npm/@toclocoinc/lattice-grid@1.71.0/lattice-grid.esm.min.js';
  import createLatticeGrid from 'https://cdn.jsdelivr.net/npm/@toclocoinc/lattice-grid@1.71.0/modules/react.esm.min.js';

  const LatticeGrid = createLatticeGrid({ React, createGrid });

  // 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.
  const permissions = {
    default: 'read',
    columns: {
      state: 'write',
      notes: 'write',
      onCall: 'writeOnly',
    },
    resolve(column, params) {
      const finance = params?.context?.role === 'finance';
      if (column.id === 'monthlyCost' || column.id === 'budget') return finance ? 'read' : 'hidden';
      return undefined;
    },
  };
  const 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 } },
  ];
  const rows = [/* service records */];

  function App() {
    return (
      // Permissions are evaluated against this context; grid.permissions.setContext()
      // (via a ref) re-evaluates every column when the user changes.
      <LatticeGrid rowKey="id" selection="multiple" edit context={{ role: 'on-call engineer' }} permissions={permissions} columns={columns} rows={rows} style={{ height: '540px' }} />
    );
  }

  createRoot(document.getElementById('grid')).render(<App />);
</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.

Related demos