But, read only fields can not be updated by automations.
Use case:
Have a historical exchange rate field on a Project. Set that field from a Currency table when the project is Activated. (I’m just using currency as a simple example, it could be the gold price from a table or a price from a pricing table, etc. etc.)
Right now it can be done, but then any user with access to the project can edit that field.
Allowing automations to set readonly fields, solves it.
Technically, automations run with the same permissions as the user, if it’s a button press, or as the Fibery ghost (= admin) if it’s a rule.
Automations can never do anything that a user cannot do, so if a field is read-only, for users, it’s read-only for automations.
However, for any editable field, you can choose to create a ‘shadow’ field which is read-only by simply referencing the original field in a formula. Then you can choose which fields are visible on the UI, so that the editable field (which the automation can update) is hidden, but the read-only field is shown to the user.
It doesn’t stop someone with creator permissions from making edits, or creating a new view with the hidden field shown, but it prevents an editor user from doing much*
*Technically, they could still make changes via the API
Since we don’t plan to introduce field-level permissions, I don’t see a nice solution in the near future which is completely bullet-proof, unless you make an extra DB to hold the data which is to be read-only for users, and then link 1-to-1 with the database which should be accessible.