Saturday, May 31, 2025
4 changes · saas-18.3
Miscellaneous changes
Versions -------- - 17.0+ Steps ----- 1. Create a new internal user with some administrator rights; 2. set notification preference to "Handle in Odoo"; 3. save changes; 4. switch user type to portal. Issue ----- Validation Error: The user cannot have more than one user types. Cause ----- In the write method of `UsersImplied`, a check happens on whether a user was demoted, by saving the internal users before `super().write`, and comparing it to the internal users after `super(
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a new internal user with some administrator rights; 2. set notification preference to "Handle in Odoo"; 3. save changes; 4. switch user type to portal.…
Versions -------- - 17.0+ Steps ----- 1. Create a new internal user with some administrator rights; 2. set notification preference to "Handle in Odoo"; 3. save changes; 4. switch user type to portal. Issue ----- Validation Error: The user cannot have more than one user types. Cause ----- In the write method of `UsersImplied`, a check happens on whether a user was demoted, by saving the internal users before `super().write`, and comparing it to the internal users after `super().write`[^1]. [^1]: https://github.com/odoo/odoo/blob/6ba1106aecf71886b7df3b7943089fa72a6c506c/odoo/addons/base/models/res_users.py#L1455-L1457 This was working fine until commit 141852dc6613c introduced the `_inverse_notification_type` method[^4]. It adds or removes the `mail.group_mail_notification_type_inbox` group from users when the `notification_type` gets changed. [^4]: https://github.com/odoo/odoo/blob/6ba1106aecf71886b7df3b7943089fa72a6c506c/addons/mail/models/res_users.py#L54-L58 In our first call to `UsersImplied.write`, we store the user as an internal user and call `super().write`. This unlinks `base.group_user`, links `base.group_portal` and sets `notification_type` to `email`. Before returning from `super().write`, the `_inverse_notification_type` method gets triggered to unlink the inbox group, which will lead to a recursive call to `UsersImplied.write`. The recursive call no longer registers the user as internal or being demoted, hence it will re-add `base.group_user` as an implied group[^2] of its still present administrator group, leading to the `api.constrains` violation in `_check_one_user_type`[^3], as we already have the `base.group_portal` group. [^2]: https://github.com/odoo/odoo/blob/6ba1106aecf71886b7df3b7943089fa72a6c506c/odoo/addons/base/models/res_users.py#L1466-L1469 [^3]: https://github.com/odoo/odoo/blob/6ba1106aecf71886b7df3b7943089fa72a6c506c/odoo/addons/base/models/res_users.py#L589-L599 Solution -------- Add a context value when calling `super().write`. If this value is present in the current call, this indicates we are in a recursive write, and can return without adding/removing implied groups, as these will get handled later by the base call. opw-4676929 Forward-Port-Of: odoo/odoo#212359 Forward-Port-Of: odoo/odoo#207961
- Update accounting entries to reflect the new commercial_partner_id: * Ensures consistency across account.move.line and partner_id fields. * Changes are restricted to users in the Accountant group. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212456 Forward-Port-Of: odoo/odoo#211939
Original PR description
- Update accounting entries to reflect the new commercial_partner_id: * Ensures consistency across account.move.line and partner_id fields. * Changes are restricted to users in the Accountant group. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212456 Forward-Port-Of: odoo/odoo#211939
When submitting the EC Sales List via Intrastat, redundant partner entries with the same VAT number (but different commercial entities) may lead to inaccurate reporting and validation issues. - Detecting partners with duplicate VAT numbers. - Displaying a warning banner at the top of the report when duplicates are present. - Highlighting duplicated partners in the report with a yellow background. - Adding a "Set as main" button to duplicated rows, allowing users to set a partner as the com
Original PR description
When submitting the EC Sales List via Intrastat, redundant partner entries with the same VAT number (but different commercial entities) may lead to inaccurate reporting and validation issues. - Detecting partners with duplicate VAT numbers. - Displaying a warning banner at the top of the report when duplicates are present. - Highlighting duplicated partners in the report with a yellow background. - Adding a "Set as main" button to duplicated rows, allowing users to set a partner as the commercial partner for all others sharing the same VAT. task-4707491 Forward-Port-Of: odoo/enterprise#86733 Forward-Port-Of: odoo/enterprise#83433
Added `special_economic_zone` to the list of GST treatments considered for `B2B` supply validations in the HSN (Table 12) section to align with the GSTN reporting requirements. Forward-Port-Of: odoo/enterprise#86728 Forward-Port-Of: odoo/enterprise#86683
Original PR description
Added `special_economic_zone` to the list of GST treatments considered for `B2B` supply validations in the HSN (Table 12) section to align with the GSTN reporting requirements. Forward-Port-Of: odoo/enterprise#86728 Forward-Port-Of: odoo/enterprise#86683