Odoo Changelog — 2024-10-31

Thursday, October 31, 2024

3 changes

Security(3)

Security fixes and vulnerability patches

[ADD] auth_signup_recaptcha

Core18.0auth_signupauth_signup_recaptchaSecurity

Signup and password reset requests are now protected by captcha checks. This helps prevent automated abuse that can trigger large volumes of emails and cause service or client issues.

Original PR description

Before this commit captcha was not enabled on signup and reset password requests. This meant that a lot of emails could be sent by automated means, causing issues for clients.

Task-3626220


16.0: https://github.com/odoo/odoo/pull/185073
17.0: https://github.com/odoo/odoo/pull/185097
18.0: https://github.com/odoo/odoo/pull/185653 <--
master: https://github.com/odoo/odoo/pull/185648

#captcha#signup#password reset#spam prevention

[FIX] l10n_cl_edi: improve security for field l10n_cl_dte_file

PR #73089

Enterprise18.0l10n_cl_ediSecurity

This update prevents regular users from changing sensitive Chilean electronic invoice files. It helps protect official tax document data from unauthorized edits and reduces compliance and fraud risks.

Original PR description

This PR ensures that the l10n_cl_dte_file can be edited only by the technical features group, not allowing users to change the content.
The same for field l10n_cl_sii_send_file

#security#chilean-localization#electronic-invoicing#access-control

[IMP] documents: restrict document access for portal user

PR #71106

Enterprise18.0documentsdocuments_accountdocuments_productdocuments_projectdocuments_spreadsheetwebsite_documentsSecurity

Portal users now only see and change document options that they are allowed to use, reducing confusing errors and preventing unintended edits. The update also fixes an access issue when shared document links are generated across companies.

Original PR description

WIP Currently, it integrate the PR odoo/enterprise#71358 as this PR limit what the portal user can do in the interface so that when testing we don't get access error. It also integrate…

As some document fields are used to determine right access to it (ex: access_internal) and other are not meant to be read/modified by portal users (ex.: requestee_partner_id), we restrict the fields that can be read and written for portal user:
- either by excluding them completely using groups on field definition
- or by excluding them from a writable whitelist of field for portal user. Note that we have chosen to list the writable fields rather than listing the readonly fields to avoid error of giving too much write access to the portal user.

We enforce that in the create, write and action_update_access_rights methods.

We also try to limit the fields that portal user can read on document by overriding:
- _determine_fields_to_fetch
- fields_get
- check_field_access_rights

The main benefits is that those fields doesn't appear in the interface but unfortunately, it doesn't prevent most of the time that the fields are read by portal user because there are a lot of compute sudo field or field computed using SQL queries. For example, alias mixin uses inheritance by delegation and all the fields of the related model are added using compute sudo.

The code is mostly copied from project where a similar behavior is implemented.

Solutions discarded:
- we haven't used "groups" attribute on fields as we had no control on the inherited fields at least in stable.
- we haven't dynamically modified the field definition (adding group dynamically) because it can only be done in the init function that is only executed during upgrade.

Task-4221258

Before this commit captcha was not enabled on signup and reset password requests. This meant that a lot of emails could be sent by automated means, causing issues for clients. Task-3626220 16.0: https://github.com/odoo/odoo/pull/185073 17.0: https://github.com/odoo/odoo/pull/185097 18.0: https://github.com/odoo/odoo/pull/185653 <-- master: https://github.com/odoo/odoo/pull/185648

WIP Currently, it integrate the PR odoo/enterprise#71358 as this PR limit what the portal user can do in the interface so that when testing we don't get access error. It also integrate odoo/enterprise#71655 to also avoid a bug when testing (access to company when building access_url). As some document fields are used to determine right access to it (ex: access_internal) and other are not meant to be read/modified by portal users (ex.: requestee_partner_id), we restrict the fields that can be read and written for portal user: - either by excluding them completely using groups on field definition - or by excluding them from a writable whitelist of field for portal user. Note that we have chosen to list the writable fields rather than listing the readonly fields to avoid error of giving too much write access to the portal user. We enforce that in the create, write and action_update_access_rights methods. We also try to limit the fields that portal user can read on document by overriding: - _determine_fields_to_fetch - fields_get - check_field_access_rights The main benefits is that those fields doesn't appear in the interface but unfortunately, it doesn't prevent most of the time that the fields are read by portal user because there are a lot of compute sudo field or field computed using SQL queries. For example, alias mixin uses inheritance by delegation and all the fields of the related model are added using compute sudo. The code is mostly copied from project where a similar behavior is implemented. Solutions discarded: - we haven't used "groups" attribute on fields as we had no control on the inherited fields at least in stable. - we haven't dynamically modified the field definition (adding group dynamically) because it can only be done in the init function that is only executed during upgrade. Task-4221258