Sunday, August 3, 2025
5 changes
1 change
Resolved issues and error corrections
Confirming a sales order for a service product could fail when its project template had no company set but the customer did. The fix automatically aligns the generated project with the customer's company, preventing the error and allowing sales orders to be confirmed smoothly.
Original PR description
Currently, a user error occurs when confirming a Sales Order (SO). **Steps to reproduce:** 1) Install sale_project 2) Create a service product that generates a project and a task. 3) Add a project…
Currently, a user error occurs when confirming a Sales Order (SO). **Steps to reproduce:** 1) Install sale_project 2) Create a service product that generates a project and a task. 3) Add a project template by creating one from the product form view. 4) Create an SO by creating a customer with a company 5) Add the above-created service product and confirm the SO. **Error:** A user exception will be triggered ``` The project and the associated partner must be linked to the same company. ``` **Cause:** - When a project template is created from the product view, both the customer and the company_id default to empty. - Later, when confirming a SO with a customer that belongs to a company, the new project's company_id is taken from the project template, which is empty. https://github.com/odoo/odoo/blob/876e9d5e9ba87fa69188b2da098eec78f77040f5/addons/sale_project/models/sale_order.py#L140-L141 - However, the project’s partner_id (the customer) does have a company_id, (since the customer value for the project will be set through SO's customer). - This leads to a mismatch between the project’s company_id(which is empty) and its partner’s company_id. So a user exception will be triggered from the below lines https://github.com/odoo/odoo/blob/876e9d5e9ba87fa69188b2da098eec78f77040f5/addons/project/models/project_project.py#L257-L258 **Solution:** - If the project template has no company_id, and the customer of the project has one, set the project’s company_id to match that of the customer. opw-4900741,4880495 Forward-Port-Of: odoo/odoo#216582
2 changes
Resolved issues and error corrections
The mail activity counter in the top navigation now updates when activities are changed, not only when they are created, deleted, or reassigned. This keeps users' activity counts accurate after actions like archiving activities or changing due dates, including bulk updates.
Original PR description
Currently the systray counter is only updated at: - create - unlink - write, but only if the user changes We want to detect changes such as activities being archived or due dates being updated to properly reflect the changes as the user applies them. We now do a separate check for activity count per user before and after a write call that modifies these fields. Additionally since we now have a count we provide that as part of the bus notification so that it can be updated accurately when modifying/creation/deleting activities in batch. Common activity test utils are updated to avoid false negatives. task-4862215 Forward-Port-Of: odoo/odoo#220523 Forward-Port-Of: odoo/odoo#215880
2 changes
Resolved issues and error corrections
The French point of sale audit report now processes large order histories much faster by reading only the data needed for its integrity checks. This reduces delays and memory pressure for businesses with high POS order volumes while keeping the same tamper-checking purpose.
Original PR description
### Problem: Pos inalterability Check report is specific to French localization. It verifies whether POS orders have been modified by computing a hash of the order data and comparing it to the previously stored hash. _compute_string_to_hash method is computationally expensive and leads to significant performance and memory issues when processing more than 50,000 orders. ### Benchmark Before: | Orders | Time | Memory | |--------|---------|--------| | 1k | 15s | 10MB | | 10k | 77s | 81MB | | 20k | 102s | 110MB | | 40K | timeout | 256MB | After: | Orders | Time | Memory | |--------|------|--------| | 1k | 5s | 7MB | | 10k | 9s | 42MB | | 40K | 20s | 174MB | | 100k | 42s | 550MB | | 330k | 126s | 1.2GB | ### Solution: Fetching only required fields to compute _compute_string_to_hash opw-4901994 Forward-Port-Of: odoo/odoo#221040 Forward-Port-Of: odoo/odoo#217348
This update prevents activity lists from applying an archive-related filter to records that do not support archiving. It helps avoid errors or missing activity information in areas such as Calendar, Mail, SMS Marketing, and Project To-Do while keeping archived activities hidden where appropriate.
Original PR description
In this forward-port [1]
`active_test=False` is replaced with `[('active', 'in', [True, False])]`
to prevent "active_test" from applying on the activities, which should
not be displayed when archived by default.
The change cannot be applied generically because not all activity mixin
models have an "active" field.
Instead the groups can define their domain depending on their individual
fields. "group domains" are conveniently already supported for use cases
like "fake" groups for todo tasks and the likes.
[1]: https://github.com/odoo/odoo/commit/1cd920a2c7ed251d5e74a890f7183a7620bc06a3Italian electronic invoicing now preserves the document type selected by the user when sending reverse charge tax integrations for vendor credit notes. This ensures credit notes are reported with negative amounts, preventing them from being mistaken for additional vendor bills.
Original PR description
When tax integrations are sent from a credit note (of a vendor bill) they should have a negative value, as it is the reversal operation. However, currently the amounts are positive, so it appears to…
When tax integrations are sent from a credit note (of a vendor bill) they should have a negative value, as it is the reversal operation. However, currently the amounts are positive, so it appears to be a second Bill rather than its reverse. **Steps to reproduce (with an IT Company)** - Create a non-eu [PARTNER] with complete address and VAT - Create a Vendor Bill with: - Partner: [PARTNER] - Electronic Invoicing > Document Type set to TD18 - A line having Reverse charge tax (ie. 22% G RC) - Confirm and send tax integration - Reverse move - Ensure the document type is set to TD18 as well - Confirm and send tax integration - Check the generated xml **Issue** Credit note tax integration will have a positive amounts, while being a credit note it should have negative amounts This occurs because when generating the xml, the document type is recomputed from the invoice features, even if the user set it manually Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4788529) opw-4788529 Forward-Port-Of: odoo/odoo#220878