I know this feature is in beta and I know I discussed with Dmitry regarding how I wouldn’t want my team to edit formulas and he showed me to Deny SchemaEdit. I was wondering, if in the future, can there be a category called “Custom” under Schema and we select specifically what they are allowed to change/not allowed to change?
For example, I don’t want my team members to be editing formulas, but I want them to to be able to rearrange fields in card widgets. We found out that they weren’t able to rearrange fields because of Deny SchemaEdit.
Another example that has happened with our team, is that we have been using Choice column for our client’s email so that way we can see if it’s a unique entry or not (aka if the email shows up red, that means it’s completely new, if it’s not red then that means the record already exists). My coworkers informed me that they can no longer add those emails as choices so I would have to go in and add it in myself.
- There is probably a better way to do this, but this was a quick solution for my team at the very least.
If there is a way to write the condition on any of the above, please let me know! 
2 Likes
That’s a great idea, Diana!
Just thinking outloud… 
What about protecting specific columns, such as formula columns and other very sensitive data columns, from update and schema edits, similar to protected ranges in Sheets or Excel?
2 Likes
I think there’s definitely a case for special handling of permissions to change formulas. If we did that, then we could allow nuanced control over the right to modify properties of individual tables and columns. And for your case, you could then forbid formula editing globally while allowing liberal changes to other column properties.
Someone who can change a formula could rewrite it to access parts of the document they are not supposed to have access to. And the formula of a column is part of its “schema” as far as Grist is concerned. That’s why we currently only allow “SchemaEdit” to be set at the document level, to reduce misunderstandings. But I like the idea of separating out formula permissions and then being more nuanced with the rest.
2 Likes
Yes, something like this would be nice!
Currently right now, I have my conditions as this (if a screenshot helps).
Which allows my team to update and create throughout our pages (cause I have a ton of formulas and references floating around on our document
).
Before adding this condition (which again, thanks Dmitry!), all my references/formulas always got replaced because my team wasn’t familiar of formulas/references so I would have to go and dig for those references and formulas again. With the condition, it has been a great help because no one’s adjusting or editing those specific columns anymore or it doesn’t allow them. It’s just the moments where I have to do a daily check of, “oh ,this wasn’t able to be added to the Choice column” or “I want to move this column above this column”.
I’m getting steps closer of reviewing the zoom meeting with Dmitry the other week in order to set user restricted permissions for our larger team. So when I actually hit that point, I might have more feedback regarding that.
1 Like
Hi!
I saw this topic from 2 years ago, but there is no further answer.
I was wondering if it would be possible to have a parameter to a column, similar to the other parameters (cell format, header style, etc,) which prevents anyone by the owner to update/delete that column. This would be very useful as otherwise, I wind up with team members typing in a value in cell and erasing a formula. 
.
Michel
This is me again, in between, I found the way to protect columns with access rules, among other things.
No problem!
1 Like
