search

gristlabs / grist-core

Grist is the evolution of spreadsheets.
https://www.getgrist.com/
Apache License 2.0
7.11k stars 317 forks source link

Add protect option to formula column with readonly access to prevent errors from owners #1257

Open tristanrobert opened 5 days ago

tristanrobert commented 5 days ago

Describe the problem to be solved

Owners have access to edit formula but when they edit data in a row with formula, they could erase formula. A discussion here : https://community.getgrist.com/t/make-formula-columns-write-protected/6345

Describe the solution you would like

Add a toggle/check in column formula options in order to able/disable formula editing.

formula_column_protected

tristanrobert commented 5 days ago

There is already a prop in UI model: https://github.com/gristlabs/grist-core/blob/e43bb670a0fa03b2e8b1b3ca153621290e992bdd/app/client/models/entities/ColumnRec.ts#L73

dsagal commented 1 day ago

Thanks for the feature request! Let me attempt to categorize the various things that are possible that maybe shouldn't always be possible. For terminology, I'll say "data column" to mean "column that's not a formula column".

  1. Editing values in a data column. (Can already be made read-only in access rules.)
  2. Editing formula in a formula column.
  3. Converting a data column to a formula column.
  4. Converting a formula column to a data column. (This is what happens when one erases a formula and sets a value.)

The last 3 can be blocked by denying "edit structure" permission in the "Special rules" section of access rules. But this would apply to the whole document, not per column.

I see several related but slightly different options for what we could do:

  1. When using access rules to deny "Update" permission on a column, disallow not only (1), but all changes to the column. You could then decide who has this permission denied and who doesn't. Note that this would apply as a secure way to block changes -- not only through UI, but through API as well.
  2. As in 1, plus add a "read-only" or "editable" checkbox (like you proposed) for a column, which is equivalent to an access rule that prevents everyone from making any changes to the column. Owners can uncheck the checkbox to remove this rule.
  3. Add a "read-only" or "editable" checkbox like you proposed, but which only locks the column in the UI, and does NOT create access rules. It does not affect API access. The lock in the UI applies to everyone. Anyone with "edit structure" permission can toggle it (by default that's all editors). So it's more to prevent mistakes than to lock the column securely.

Perhaps there is a better combination than these. Of the ones here, I'd lean towards 2.

It's also possible that would could additionally create some UI where you could keep the column read-only, and allow owners to "bypass protection temporarily", i.e. rather than remove the rule (which would create a window where others could make a change), the bypass would create an extra permission just for this owner's current session. I could see that being useful at other levels of granularity too, e.g. to lock down a whole table or document for everyone, and still allow owners to bypass the lock to make changes.