I have a table that should behave as a fixed single-row settings table: no new rows should ever be addable, and the existing row should never be deletable. I set the table-level “Are updates allowed?” setting to disallow Adds and Deletes, expecting this to fully block those operations regardless of how they are attempted (UI, actions, or otherwise).
In practice, this table-level setting did not reliably prevent the behavior I was trying to block. The only thing that reliably worked was setting the “Only if this condition is true” field on the Add and Delete actions themselves to a plain false expression, which blocks the UI buttons directly, but that is a different, narrower mechanism than the table-level permission and does not give the same guarantee (it only hides the action, it doesn’t enforce a table-level rule).
Expected: the table-level “Are updates allowed?” setting should be a reliable, enforced constraint on the table itself, independent of whether individual actions also have their own visibility conditions.
Repro steps:
- Create a table intended to hold exactly one fixed row (a settings-style table).
- Set “Are updates allowed?” to disallow Adds and Deletes for that table.
- Attempt to add or delete a row through the normal Add/Delete actions.
- Observe that the table-level setting alone does not reliably block this, and that a separate, action-level “Only if this condition is true = false” is needed to actually prevent it through the UI.