The core base module provides a res.config.settings model, providing the business logic behind option activation. The base_setup addon module uses it to provide the 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 some central management dashboard, so we need to extend it to add our own configuration settings.
If we are to 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 used two different ways to activate the features: one by enabling a security group, making the feature visible to the user, and the other by installing an addon module providing 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 addon 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 that 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 it at 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 containing a comma-separated list of XML IDs for the security groups to activate when it is enabled. The XML IDs must be in the complete form with module name dot identifier name.
We can also provide a group attribute to specify for which security groups the feature will be enabled. It will be for all the Employee-based groups if no groups are defined. Thus, they 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 the recipe adds the options to the General Settings form view, just before the Business documents group, having id="business_documents". It creates its own div with the module name as ID, which is good practice because then other modules extending my_module can easily add their own configuration items to this div.