Add-on modules are organized in to functional areas, or major applications, such as Accounting and Finance, Sales, or Human Resources. These are defined by the category key in the manifest file.

If a category name does not exist yet, it will be automatically created. For convenience, a base.module_category_<category_name_in_manifest> XML ID will also be generated for the new category name in lowercase letters, replacing the spaces with underscores. This is useful to relate security groups with application categories.

In our example, we used the Library category name, and it generated a base.module_category_library XML identifier.

By convention, data files that contain security-related elements should be placed inside a security subdirectory.

You also need to register security files in a manifest file. The order in which files are declared in the data key of the module manifest is important, since you can't use a reference of security groups in other views or ACL files before the group has been defined. It's best to place the security data file at the top of the list before the ACL files and the other user interface data files.

In our example, we created groups with the <record> tag, which will create a record of the res.groups model. The most important columns of the res.group model are as follows:

• name: This is the group's display name.
• category_id: This is a reference to the application category and is used to organize the groups in the user's form.
• implied_ids: These are other groups to inherit permissions from.
• users: This is the list of users that belong to this group. In new add-on modules, we usually want the admin user to belong to the application's manager group.

The first security group uses implied_ids as the base.group_user group. This is the Employee user group, and is the basic security group all the backend users are expected to share.

The second security group sets a value on the users field to assign it to the administrator user, which has the base.user_admin XML ID.

Users that belong to a security group will automatically belong to its implied groups. If you assign a Librarians group to any user, that user will also be included in the User group because the Librarians group has the User group in its implied_ids column.

Also, access permissions granted by security groups are cumulative. A user has permission if any of the groups they belong to (directly or implied) grants that permission.

Some security groups are shown in the user form as a selection box instead of individual check boxes. This happens when the involved groups are in the same application category and are linearly interrelated through implied_ids. For example, Group A has implied Group B, and Group B has implied Group C. If a group is not related with any other groups through implied_ids, instead of a selection box, you will see a checkbox.

Note that the relations defined in the preceding fields also have reverse relations that can be edited in the related models, such as security groups and users.

Setting values on reference fields, such as category_id and implied_ids, is done using the related records' XML IDs and some special syntax. This syntax is explained in detail in Chapter 7, Module Data.