The engineer sees columns that accept edits on double-click, but the table has no single control that turns editing on or off when the user’s privileges change. In the configuration represented by FEATURE-14187, editability must be applied to every editable column and to any cell-level configuration that can override its column.
Where does an edit request travel?
Follow the edit path before changing scripts. The user double-clicks a cell in the Perspective client. The table evaluates the cell and column configuration, decides whether to expose an editor, and only then can the edited value enter the application’s update logic. If the editor never opens, the request stops in the component configuration. If it opens but the new value is rejected later, the fault lies downstream in validation, authorization, or write processing.
| Path stage | Decision | Diagnostic observation |
|---|---|---|
| User interaction | Was an editable cell activated by double-click? | No editor appears if editing is disabled at the effective cell configuration. |
| Cell configuration | Does the cell have a more-specific edit setting? | A cell-level setting can override the column’s editing mode. |
| Column configuration | Is the column marked editable? |
The column supplies the general editing state when no cell override takes precedence. |
| Application logic | Is the proposed value authorized and valid? | The editor may open even though downstream logic later rejects the operation. |
Layer one first in this context means starting at the user-facing component state: confirm that the table receives the double-click and inspect the effective configuration of the selected cell. Do not begin with database or tag-write diagnostics when the editor itself never appears.
Which privilege-control approaches are available?
Two approaches define the decision. A master table switch would provide one privilege-controlled state for the whole component, but that control was not present in the described Perspective table implementation. The operational approach is granular control: update each column’s editable property and also disable any editable cells.
| Approach | Control point | Cell override handling | Status for this case |
|---|---|---|---|
| Global table switch | One table-wide setting | Would need to override all lower-level settings | Not available; requested under FEATURE-14187
|
| Per-column and per-cell control | Each editable column and explicitly editable cell | Must process both levels | Available and required |
Use the per-column and per-cell approach. It matches the component’s specificity model and does not depend on a table-wide property that the implementation does not provide. Treat the feature ticket as an enhancement request, not as proof that a master switch exists in the deployed release.
Why is changing only the columns insufficient?
The table uses configuration specificity. A column defines the normal editing behavior for its cells, while a cell can carry a more-specific configuration. When a cell is explicitly editable, that setting can override the column’s editing mode. Setting every column’s editable property to false therefore does not establish a complete table lock if one or more cells retain an editable override.
| Column setting | Cell-specific setting | Effective decision |
|---|---|---|
| Editable | No override | Editing follows the column. |
| Not editable | No override | The editor remains closed. |
| Not editable | Editable override present | The more-specific cell configuration can permit editing. |
This hierarchy matters when privilege logic is executed as the view loads. The script must calculate one authorization result and apply it consistently to all edit entry points. Repeating privilege tests independently for each column increases the chance that different columns receive different states after a later modification.
How should the privilege-controlled configuration be applied?
Resolve the user’s privilege once, use the result as the desired editing state, and propagate that state across the complete edit surface. The evidence identifies view load as the practical execution point; applications that can change privileges during an active session also need to rerun the same synchronization when the relevant user context changes.
- Inventory every column that currently permits double-click editing. Record its
editableproperty and the intended privilege requirement. - Inspect the table data and configuration for cells with explicit editing settings. Add each such cell to the inventory because its greater specificity can bypass a column-only change.
- At view load, evaluate the current user privilege through the project’s existing identity and authorization mechanism. Store the result as one Boolean editing decision.
- Apply that Boolean to the
editableproperty of every controlled column. - Apply the same authorization decision to every cell-level editable configuration. When unauthorized users must never receive an editor, remove or disable any cell override that would evaluate as editable.
- Keep value validation and write authorization in the downstream update path. Component editability controls the user interface; it must not be the only barrier protecting a tag, database value, or command.
Centralize the column and cell inventory so a newly added editable field is visible during review. A column added outside that inventory can create a privilege-control gap even when the original script still runs without error.
How do you verify the edit lock?
Test both privilege branches against the same table data. A visual inspection is insufficient because the displayed table looks normal in both states; the decisive observation is whether the editor opens and whether an unauthorized write can pass downstream.
- Open the view as a user who has the required privilege.
- Double-click each intended editable column and every known cell override. Confirm that the editor opens and that the normal validation and update path still works.
- Open or reload the view as a user without the privilege.
- Repeat the same double-click sequence. Confirm that no editor opens for any controlled column or cell.
- Attempt the corresponding update through every other application path that can invoke it. Confirm that downstream authorization rejects an unauthorized operation even if a client-side state is stale or manipulated.
Which failure patterns recur?
| Symptom | Likely cause | Correction |
|---|---|---|
| Most cells are locked, but one still edits | A cell-level editable configuration overrides the column. | Inspect and synchronize explicit cell settings. |
| Editing remains enabled after a privilege change | The logic ran only when the view loaded. | Rerun the synchronization when user context changes, or reload the view through the application’s controlled workflow. |
| A newly added column ignores privilege control | The column was omitted from the configuration inventory. | Add it to the centralized list and repeat both privilege tests. |
| The editor is hidden, but a write still succeeds elsewhere | UI editability was treated as authorization. | Apply the same privilege rule in the server-side or downstream write path. |
| The editor opens for an authorized user but no update occurs | The component passed the edit into later validation or write logic, where it stopped. | Trace the proposed value after the table instead of changing editable. |
FAQ
Why does a Perspective table have no global edit disable switch?
The implementation represented by FEATURE-14187 has no master table edit control. Disable every editable column and any explicitly editable cells.
Why does one cell remain editable after I disable its column?
A cell-level setting has greater specificity and can override the column’s editing mode. Find that cell configuration and disable or remove its editable override.
Why should privilege logic run when the view loads?
View load provides a point to read the current user context and synchronize all column and cell edit settings before interaction. If privileges can change while the view remains open, run the same synchronization again when that context changes.
Why is the editable property not sufficient security?
editable controls whether the component exposes an editor; it does not replace authorization at the tag, database, command, or other update boundary. Reject unauthorized writes in the downstream path as well.
How do I verify Perspective table privilege editing?
Test every editable column and cell override first with the required privilege and then without it. Finish by attempting the same update through other application paths and verifying that downstream authorization rejects the unauthorized operation.