On the SDN5-forum, Kerry Bellerose posted an extremely usefull reply where he explains what the difference is between Field Security and Security. He also explains why they have chosen to implement it that way:
The difference in setting field security from item security reflects the fact that field security is actually different from item security.
In general, users who are given read/write access to an item, automatically have read/write access to all the fields in that item.
This covers the great majority of items and fields, so it’s nice that things work this way.
On the other hand, when business rules suggest that only a limited set of people who have read/write access to an item should also have read/write access to a given field, Sitecore’s approach is designed to limit the number of security configuration changes required.
For example, lets say we have a field called Foo that Authors should not even see (even if they have read/write access to an item), the Sales People should see, but should not be change, and that Managers should be able to see and change.
When we define the field Foo, the field inherits the Read / Write access rights assigned to the user, be it Author, Sales Person, or Manager.
When we begin assigning field security to Foo for any role, however, this breaks the inheritance of access rights from item to field. In other words, as soon as we assign field security to Foo for any given users or roles, read and write access defaults to denied for all other users and roles.
This may seem complex until you understand it, but you do understand it you can see that the following is true:
- Generally you can ignore field security and focus on item security (assuming that having access to an item also gives the same access to fields).
- When a limited group of users/roles should have access to a specific field, you only need to grant access to those users/roles, you never need to deny read/write access to a field (because as soon as you explicitly Allow access for anyone, everyone else defaults to Denied access).
So in our example above, to meet our business requirements, we would do the following:
- Allow Read access on Foo for Sales People
- Allow Read and Write access on Foo to Managers
This would implicitly deny read and write access to authors and deny write access to Sales People.
I hope this clears things up!
Thank you Kerry! For the full thread take a look here.