The following points provide information on some advance tricks that are used to tweak the behavior of view inheritance:

• For inheriting views, a very useful and not very well-known field is groups_id. This field causes the inheritance to take place only if the user requesting the parent view is a member of one of the groups mentioned there. This can save you a lot of work when adapting the user interface for different levels of access, because with inheritance, you can have more complex operations than just showing or not showing the elements based on group membership, as is possible with the groups attribute on form elements.
• You can, for example, remove elements if the user is a member of a group (which is the inverse of what the groups attribute does). You can also carry out some elaborate tricks, such as adding attributes based on group membership; think about simple things such as making a field read-only for certain groups, or more interesting concepts such as using different widgets for different groups.

• What was described in this recipe has the mode field of the original view set to primary, while the inheriting views have mode extension, which is the default. We'll look into the case that the mode of an inheriting view is set to primary later, where the rules are slightly different.