Hi Jakub,
It will work, but it will slow down your application tremendously using an xpath over so many associations.
You can opt for associations to 'AccountCountryAssignment' and make sure to automate the logic that if you add/delete a record related to the Country level, you add/delete the related association records. You could end up with a very large set of records in the AccountCountryAssignment table, which would impact performance as well. Alternatively, in stead of using the Information Entity, you can use a *-* association, but make sure to use ownership only on 1 side (on Client/Department/etc), but keep the Entity between account and country to control the overall access. Again, you will need to create logic to set/remove the other associations.
More in general, you can also review what level of security are required. For instance: If there is no page that potentially displays the entire list of Clients, but they are only accessible trough a detail page of a Department, it might be sufficient to limit access on Department level, because there would be no other way in the application to access the client records.
Hi Micha
Your last remark was most insightful - indeed, all entities from lower levels in hierarchy are only available to users via their parents. And the lowest level a user can reach without the context of a parent is SubUnit. So I created a separate Entity for User, generalized to Account, put an N-N association between User and Country (following your former advice), and N-1 between SubUnit and Country. The association for SubUnit and Country is set upon creation, based on the parent Unit's association.
So now the contraint when reading SubUnits is much shorter:
[MyModule.SubUnit_Country/MyModule.Country/MyModule.MyUser_Country='[%CurrentUser%]']
Thanks again, you helped me a lot