Since there is a separate “Comment” capability that unlocks access to a specific field in Entity, I assume we could have two additional capabilities (or one of them):
This would allow users with the lowest access levels to be more independent, for example, marking tasks as completed without the ability to change deadlines, and so on.
The workflow field is pretty much just a normal select field, and adding support for specific permissions for that field would be on a par with field-level permissions in general, which is something that is not on the radar, due to the complexity.
The backend does include the necessary framework for allowing ‘button press’ do be a capability distinct from update, and it is something that has been considered. The biggest issue is that when a button executes, it does so with the permissions of the person who pressed it, which means there could be some frustrating experiences. For example, if the button has been configured so as to update a specific field value when it is pressed, the user might have the capability to press the button, but not the capability for the button actions to be executed!
Yes, what I mean is that the capability to use buttons (automations) would grant the ability to act as an editor when doing so. I thought this might be possible since the Comment capability allows one to be an editor of the Comments field while the Entity itself remains read-only.
Under the hood, comments are stored as entities linked to the parent entity, so they don’t behave like a basic field (number, date, text, etc.) but are closer to being a collection field (one-to-many relation).
This means a user can have ‘editor’ access to comments in the comments ‘database’ that belong to this entity.
In other words, although it looks like a field-level capability, it’s a database/entity level capability.
This would imply a temporary extension of a user’s capabilities while the button is executing, and it’s not really feasible for a user to quickly gain and then lose capabilities.
For what it’s worth, I would love it as a feature myself, but I know from the inside that it’s not an easy thing to do.
I realised after writing, that what I wrote about the workflow field is somewhat misleading, since it too behaves like a database (it’s basically a many-to-one relation). I’m not saying that it makes implementing it any easier 
+1 specifically for adding access to button presses in access templates. The ideal would be able set which buttons they can press and which they don’t.
For example, I dont want them to be able edit the entity, but I do want them to be able to press “Approve”.
But the same entity might have another button for “Toggle send to client”. I don’t want them to be able to press that and remove their own access, for example.
Regarding the frustration with button access vs edit access, this is just up to the Architect to build properly. Those who are configuring custom access are already far into learning Fibery.
In this example, what is the Approve button doing?
I assume it is changing something (a field value perhaps)
In which case, the button presser needs the permissions not only to press the button but to execute the actions which the button is expected to carry out.
This is very unlikely, since it is basically field-level permissions, which is not on the horizon at all.
Yes and no. Its adding a relation of the person’s own entity (which they have edit access to) to the entity. This is possible to do without edit access (not sure if a bug or not, but possible)
Calling buttons a “Field” isn’t really true as to what they are though. You don’t have a different button value per entity, which is what you have in a field. I’m pretty sure (but correct me if im wrong) that you can’t query an entity and get the value of the buttons. Hence, while it gets a bit close to field level permissions, I don’t think its exactly what it is.
Linking entities requires edit rights for at least one end, so it might be possible for someone to click Approve on a Task they don’t have edit rights for if the action is to link the User entity to the Task.
But in general, a lot of the actions require edit access for the item on which the button lives.
Indeed, button’s don’t have values, so can’t be queried, but my point is, the idea of a capability called “Can Edit this entity” is something that can be applied to all entities in the workspace, no matter what fields the database has.
But the idea of a capability called “Can press the ‘Approve’ button” and a separate capability called “Can edit the ‘Toggle send to client’ button” implies that capabilities are not conceptually universal across all dbs, but are dependent upon which buttons exist in any given database.
In that sense, it would mean controlling permissions as a function of what buttons (= ‘fields’) a database has (aka field-level permissions).
