Limitations
One could specify that a Sales User should have access to Sales Orders having only specific Territories listed for a User. However, it allowed for only a single condition, i.e. either a role can have records filtered by Territory permissions or Company permissions; it could not accommodate for the situation where, a Sales User should have access to Sales Orders having only specific Territories listed for a User, for a specific Company "Wind Power LLC".The previous version used Field Names as reference when applying user specific permissions. This led to a drawback that, though Sales Orders could be filtered by Territories, there was no easy way to limit access to "Territory" records themselves.
Rethinking
In version 4, we rethought the way Role-based permissions and User-specific permissions are applied, without losing the features offered by version 3.In ERPNext, relations between documents are maintained through "Link Fields". Instead of using Field Names, we used the relations established by these Link Fields between DocTypes.
User Permissions can be defined for a list of users, which enlists a set of documents a user can access, if User Permissions need to be applied. (This, in contrast to specifying a combination of Field Name and Value, is much more intuitive.)
On the other end, when Role Permissions are specified, instead of specifying conditions, there is a check-box "Apply User Permissions". If checked, it will filter records based on all User Permissions specified for that user.
This takes care of the requirement: a Sales User should have access to Sales Orders having only specific Territories listed for a User, for a specific Company "Wind Power LLC", just by clicking a check-box.
Gotcha
However, it begs another question. What do you do, when your requirement is: a Sales User should have access to Sales Orders having only specific Territories listed for a User. You don't want to use "Company" as a criterion, even though it could be in the list of User Permissions.Version 3 allowed for this, because it was designed to filter based on only a single condition which had to be specified by the System Manager. In version 4, conditions were implicitly built using Link Fields, which originally, didn't allow for such a scenario. This drawback of version 4 was reported by two of our Open Source users: Mayur and Olawale.
To fix this, we made the User Permission conditions selectable, using "Select Document Types". Only those Document Types selected here would be used to build User Permission filters.
Thanks to this, Permissions in version 4 have all the features of version 3, without its drawbacks.