GRID FEATURE

Cell access control

Cell read and edit policies restrict visible and editable values according to user roles. Hiding a column is different from enforcing data access.

How it works and when to use it

Provide pure, synchronous callbacks to canReadCell and canEditCell. Load permissions first and evaluate known permissions in callbacks instead of making server requests.

In the code, grid is the Grid element prepared in the installation chapter. Check each example's data and settings, and implement the app functions and server endpoints for your project.

Example 1. Restrict sensitive-column reads

canSeePrice is a boolean obtained from the app's authentication result.

javascript
grid.canReadCell = params => params.field !== 'price' || canSeePrice;

Verify the result: Check that read restrictions apply consistently across the table, tooltips, copying, export, and other value-exposure paths.

Example 2. Restrict editing completed orders

Determine editability from the business state.

javascript
grid.canEditCell = params => params.data?.status !== 'Complete';

Verify the result: The policy restricts editing completed orders even when the column is editable. Combine it with app role rules.

Example 3. Update views after permission changes

When a role changes, assign new policy functions and check that open menus, editors, and detail views do not retain confidential values.

Verify the result: The server must recheck every read and update request independently of browser policies. UI restrictions cannot safely retract secrets already sent to the browser.

Combining features and troubleshooting

Do not return an asynchronous Promise where a boolean policy is expected. Use a restrictive policy until permission loading completes.

Also inspect surrounding code so unauthorized values do not appear in app consoles, logs, or event panels.

Related reading