Wednesday, April 9, 2025
8 changes · 17.0
Resolved issues and error corrections
When the partner on an accounting entry line is changed, the related analytic reporting line now updates to match. This keeps reporting accurate for finance and timesheet-related analysis after corrections are made.
Original PR description
Analytic lines partner is not computed when changing the partner of the related move line. To solve this, we add the `move_line_id.partner_id` in the `depends` of the compute. To reproduce: - Create a journal entry - Set an analytic account on one of a line - Confirm journal entry - From the account move line list view, select the lines from the previous entry - Change the partner - Go to analytic reporting -> The partner on the analytic line has not been changed Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4626366) opw-4626366
This fixes an issue where updating an Odoo module could fail after a custom model with tracked fields was removed. The mail tracking cleanup now avoids trying to log field-deletion messages for models that no longer exist, helping module updates complete reliably.
Original PR description
Fixes ``` File "/home/odoo/src/odoo/odoo/addons/base/models/ir_model.py", line 2647, in _process_end self._process_end_unlink_record(record) File…
Fixes
```
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_model.py", line 2647, in _process_end
self._process_end_unlink_record(record)
File "/home/odoo/src/odoo/addons/website/models/ir_model_data.py", line 35, in _process_end_unlink_record
return super()._process_end_unlink_record(record)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_model.py", line 2576, in _process_end_unlink_record
record.unlink()
File "/home/odoo/src/odoo/addons/mail/models/ir_model_fields.py", line 52, in unlink
'sequence': self.env[field.model_id.model]._mail_track_get_field_sequence(field.name),
~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/api.py", line 612, in __getitem__
return self.registry[model_name](self, (), ())
~~~~~~~~~~~~~^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/modules/registry.py", line 240, in __getitem__
return self.models[model_name]
~~~~~~~~~~~^^^^^^^^^^^^
KeyError: 'my.custom.model'
```
To reproduce:
* add a model with a tracked field to a module
* create a record and update field value to create a tracking message
* remove the model from the module and update the module
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prRegular users can now open the debit note wizard from a credit note without encountering an access error. This removes an unnecessary blocker in accounting workflows and helps users process debit notes smoothly.
Original PR description
Steps to reproduce: - Log in with User without Administration Rights - Open a Credit note - Actions > Debit note Issue: Access Error will raise opw-4659611
An internal test for Knowledge article permissions now uses the correct type of member record. This improves the reliability of permission checks and helps prevent future issues, with no expected change for users.
Original PR description
This commit changes a test that checks that we cannot remove a specific member from an article. The issue was that the parameter provided didn't respect the function's signature by giving a `res.users` instead of a `knowledge.article.member`. By chance, it always worked as those model share the field partner_id that represent the same data. But it is updated so that it better represents the correct use of the method.
Code cleanup and technical improvements
The calendar code was reorganized so default all-day event dates are handled in one reusable function. This makes it easier for other Odoo modules to adjust those dates when needed, with no expected change for everyday users.
Original PR description
[REF] web: move default dates to a function - getAllDayDates function was added to be able to inherit it in other modules and change default dates if needed. task-4164485 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Description of the issue/feature this PR addresses: IOT crashes parsing a response from https://www.odoo.com/odoo-enterprise/iot/x509 not containing 'data' Current behavior before PR: Crash Desired behavior after PR is merged: - Related internal PR: https://github.com/odoo/internal/pull/3480 opw-4711613 Forward-Port-Of: odoo/odoo#205168
Original PR description
Description of the issue/feature this PR addresses: IOT crashes parsing a response from https://www.odoo.com/odoo-enterprise/iot/x509 not containing 'data' Current behavior before PR: Crash Desired behavior after PR is merged: - Related internal PR: https://github.com/odoo/internal/pull/3480 opw-4711613 Forward-Port-Of: odoo/odoo#205168
Because #203874 needed to manipulate Odoo imports, it had to be able to import Odoo. Turns out there are setups where the root of the community repository is on `sys.path` but not in `PYTHONPATH` which can lead the pylint invocation to be confused and not have `odoo` be reachable from the `PYTHONPATH`, thus crashing the plugins' loading. Thus to run pylint we need not the `PYTHONPATH` but the `sys.path`. Which is not ideal because that'll contain the paths to the site and standard library of
Original PR description
Because #203874 needed to manipulate Odoo imports, it had to be able to import Odoo. Turns out there are setups where the root of the community repository is on `sys.path` but not in `PYTHONPATH` which can lead the pylint invocation to be confused and not have `odoo` be reachable from the `PYTHONPATH`, thus crashing the plugins' loading. Thus to run pylint we need not the `PYTHONPATH` but the `sys.path`. Which is not ideal because that'll contain the paths to the site and standard library of the python running the test, which might be different than the python running pylint. To limit the risks of contamination, strip out any path starting with one of the `sys.$CATEGORY_prefix` entries. Forward-Port-Of: odoo/odoo#205194
Before this commit: Multi-package delivery validation for the carrier 'loomis' results in an error. Rate is calcuated in the first request for all the packages. Response of the second request is code 201 but with a warning message of rate already calcuated for the whole shippment. Which reults in invalid operation error. After this commit: Added a check for 'LoomisExpress' to avoid the rate error from blocking validation. Multi-package delivery is validated correctly. opw-4650347
Original PR description
Before this commit: Multi-package delivery validation for the carrier 'loomis' results in an error. Rate is calcuated in the first request for all the packages. Response of the second request is code 201 but with a warning message of rate already calcuated for the whole shippment. Which reults in invalid operation error. After this commit: Added a check for 'LoomisExpress' to avoid the rate error from blocking validation. Multi-package delivery is validated correctly. opw-4650347 Forward-Port-Of: odoo/enterprise#82682