The docs only explain how to check access on objects rather than properties.
I'll explain the decisions I make when choosing between voters or ACL. Next I'll explain how you can use (Hierachy) voters to achieve your goal.
When users simply have or don't have access to a object based on a role, access can be performed using the firewall and is the simplest solution.
However when access depends on a per object basis under certain rules a Voter should be used. An example, Users can only edit a post when they created it. But moderators should always be ably to edit a post.
The most difficult of access control is when a user can be granted access by an other user. For example, an admin can assign users to a post and grant them edit permissions. This is a solution where access can't be decided based purely on the role of the user. The access/permissions need to be stored per user for an object. This is what ACL does. It stores permissions on objects in the database per user.
As for your problem.
Mostly these kind of uses are handled in the code itself. I've seen a lot of different forms for an entity. UserPostFormType, ModeratorPostFormType and AdminPostFormType. This isn't very dry as you can see. And checking the type of user in the code
Consider defining roles and manage them using hierarchy.
Define separate roles per property per action.
Thus define the following roles.
ROLE_ID_VIEW
ROLE_ID_EDIT
ROLE_TITLE_VIEW
ROLE_TITLE_EDIT
...
You can then assign these roles to the correct user role.
security:
role_hierarchy:
ROLE_USER: [ROLE_TITLE_VIEW, ROLE_CONTENT_VIEW, ROLE_CONTENT_EDIT]
ROLE_MODERATOR: [ROLE_USER, ROLE_TITLE_EDIT]
ROLE_ADMIN: [ROLE_MODERATOR, ROLE_ID_EDIT, ROLE_ID_VIEW]
You can now use the Hierarchy Voter to check if a user can modify or view a certain property.
The cleanest solution would be to create a Listener on you form which adds fields on your forms based the permissions the current user has.
