The core base module provides the res.config.settings model, providing the business logic behind the option activation option. The base_setup add-on module uses the res.config.settings model to provide several basic configuration options to make available in a new database. It also makes the Settings|General Settings menu available.

The base_setup module adapts res.config.settings to a central management dashboard, so we need to extend it to add our own configuration settings.

If we decide to create a specific settings form for the Library app, we can still inherit from the res.config.settings model with a different _name, and then for the new model, provide the menu option and form view for just those settings. We already saw this method in the Adding your own settings options recipe of Chapter 9, Advanced Server-Side Development Techniques.

We used two different methods to activate the features: one by enabling a security group and making the feature visible to the user, and the other by installing an add-on module that provides the feature. The logic to handle both these cases is provided by the base res.config.settings model.

The first recipe step adds the base_setup add-on module to the dependencies, since it provides extensions to the res.config.settings model we want to use. It also adds an additional XML data file that we will need to add the new options to the General Settings form.

In the second step, we create a new security group, Library: release date feature. The feature to activate should be visible only for that group so it will be hidden until the group is enabled.

In our example, we want the book release date to be available only when the corresponding configuration option is enabled. To achieve this, we use the groups attribute on the field so that it is made available only for this security group. We did this at the model level so that it is automatically applied to all the UI views where the field is used.

Finally, we extend the res.config.settings model to add the new options. Each option is a Boolean field, and its name must begin either by group_ or module_, according to what we want it to do.

The group_ option field should have an implied_group attribute and should be a string that contains a comma-separated list of XML IDs for the security groups to activate when it is enabled. The XML IDs must be in a form that is complete, with the module name, dot, and identifier name, such as module_name.identifier.

We can also provide a group attribute to specify for which security groups the feature will be enabled. It will be enabled for all the Employee-based groups if no groups are defined. Thus, the related groups won't apply to portal security groups, since these don't inherit on the Employee base security group, like the other regular security groups.

The mechanism behind the activation is quite simple: it adds the security group in the group attribute to the implied_group, thus making the related feature visible to the corresponding users.

The module_ option field does not require any additional attributes. The remaining part of the field name identifies the module to be installed when activating the option. In our example, module_note will install the note module.

The last step of this recipe adds the to the General Settings form view, just before the Business documents group, which has id="business_documents". We used this id for the view inheritance. It creates its own div with the module name as the ID, which is good practice because then other modules that extend my_library can easily add their own configuration items to this div.