A more in-depth overview of both versions is available here.

The “Project Type” module makes this functionality possible. It is a very simple module that introduces the Type​ field in the Project and Task models. Each Project or Task can belong only to one Project Type. Once the projects are categorized they can be grouped using the Group By: Type​ option.

The different project types can be set up in the Project > Configuration > Project Types​. Each Project Type can have multiple Subtypes. The available fields for each Project Type are:

• Name
• Code
• Parent Type
• Description
• Can be applied for Projects
• Can be applied for Tasks

The last two listed options are used to configure the Project Type where to be shown in Projects and/or Tasks. In the tab "Subtypes" can be found all the related Subtypes. Additionally, can be created new directly from there.

The Project Manager group has full access rights to the Project Types, while every user in the system can see them in the projects and tasks.

One possible improvement for the module can be when a certain type is selected in a project, on creation of a related task the same Type to be selected as the default value, with option to be edited if needed. Because from a business perspective, it can be expected that the project's related tasks would have the same Project Type. To provide more flexibility this option can be customizable per Project Type.

The module is maintained by Odoo Community Association (OCA) and the latest available version is 17.0.1.0.0.

standard_price = fields.Float(
    string='Cost',
    company_dependent=True,
)

The list of all company-dependent values can be found at Settings > Technical > Parameters > Company Properties​, developer mode needs to be activated in order to see the Technical menu.

In this review, we will go through the options that the “Audit Log” module offers.

The latest available version of the module at the moment of writing is 17.0.1.0.0. Once the addon is installed in the system the related sub-menus can be found in the “Technical” menu.

There are five available sub-menus:

• Rules
• Logs
• Log Lines
• User Sessions
• HTTPS Requests

Only the content in the first sub-menu, “Rules”, is customizable. While the rest of them are read-only list views that contain the different types of logs. The type of logs that each of them contains is closely related to their names.

For the module to start logging data, it is required to create a rule. Each rule is defined per model, which means that every model in the system will need a separate rule in order to log data. Except for the model name that needs to be selected, a rule has the following additional fields:

• Name: The name of the rule, for example, if the logging is for sale.order​ model the name can be "Sales Order"
• Type: Two available options “Full Log” which compares the data before and after the operation and logs both states, in this case, data from computed fields is logged as well, but because of the complexity of the operation, it can be a bit slower. On the other side the second option “Fast Log” logs only the new values for the changes made during the create​ and write​ operations, since this is much simpler it is also faster.
• Capture Record: If selected, when the record is deleted the full info of the record will be added to the log, otherwise a simple log without any details for the record will be added. This option is possible only if the type “Full Log” is selected.
• Action: This field is visible in debug mode, but even it is possible to edit it, on “Subscribe” action will be overridden by the “View Logs” action created for the rule.
• Users to Exclude: Can be specified multiple users that need to be excluded from the logs
• Fields to Exclude: Can be specified list of fields that need to be excluded from the logs
• Log Reads: If selected, every time a user sees the model’s data a log will be created, by default is not selected
• Log Writes: If selected, every time a user updates a record related to the model a log will be created
• Log Deletes: If selected, when a user deletes a record related to the model a log will be created
• Log Creates: If selected, when a user creates a new record related to the model a log will be created

The last three options are by default selected on the creation of a new rule.

After creating the rule, the next step is subscribing to it by using the "Subscribe" button. Once that is done, the system will start logging data according to the rule configuration.
The rule is editable only in the “Draft” state so in case if anything needs to be changed needs to be moved back to “Draft” using the “Unsubscribe” button.

From a security perspective, the module has two groups:

• Auditlog User
• Auditlog Manager

The first one allows users to see the logs from the record using the action “View Log”, which can be found in the record’s action menu. The users with this group have only read access to the logs.

The “Auditlog Manager” group adds full access rights to the related audit log models, however, a user can have access to the Audit log menus only if they have the “Administration Settings” group.

The logs are by default kept in the system for 6 months, but it is possible to change that in the "Auto-vacuum audit logs” scheduled action that can be found in Settings > Technical > Automation > Scheduled Actions​.

The number 180​​ in the method model.autovacum(180)​​ is number of days that the logs need to be kept, by updating this number the period that the logs are kept in the system will be changed. 
Also, as a second parameter to this method, it is possible to add the number of logs that can be deleted per run, for each of the related models where the logs are stored. This parameter can be helpful in cases when there are too many logs that need to be removed at once. Because of this, Odoo can fail the task and not remove any of them. As a result of that the system can accumulate a large amount of logs, which can increase the size of the database and also slow down the system.
Therefore our recommendation is to ensure that the scheduled action is successfully running and it is set to remove a limited number of logs per run in shorter intervals. Finally should be tested manually if the action is working as expected once the settings are completed.
The "Auto-vacuum audit logs” is not enabled by default, therefore once the module is installed it needs to be enabled.

This module is a great addition to systems that require such functionality. Also, it is regularly maintained by the Odoo Community Association (OCA) which can assure that from a technical perspective is well build module with appropriate quality assurance checks.