Tuesday, March 3, 2026
13 changes · saas-18.4
Enhancements to existing features
This update improves the explanatory messages used by Odoo's internal translation lint checks. It updates a documentation reference and adds clearer context and an example, helping developers understand and resolve translation-related warnings more easily.
Original PR description
- Update documentation link for E8502. - Clarify why E8505 is in place and give an example. Forward-Port-Of: odoo/odoo#251444
Resolved issues and error corrections
This fix prevents Chilean miscellaneous journal entries from being incorrectly blocked by electronic document number validation. Businesses can now edit and save these accounting entries without seeing an irrelevant folio error, while validation remains in place for documents where it applies.
Original PR description
Currently, editing a posted `miscellaneous` journal entry in Chile localization incorrectly raises a validation error. **Steps to reproduce:** - Install the `l10n_cl` module and switch to the `CL…
Currently, editing a posted `miscellaneous` journal entry in Chile localization incorrectly raises a validation error. **Steps to reproduce:** - Install the `l10n_cl` module and switch to the `CL company`. - Go to Accounting > Accounting > Journal Entries. - Create a balanced entry using the `Miscellaneous journal `and `post` it. - Reset it to draft, modify the `name`, and try to `save` it. **Observation:** `Validation error`: `The DTE document number (folio) must contain only digits.` **Root cause:** At [1], the constraint validation is applied to all journal entries in Chilean companies, including `miscellaneous` journals. However, `miscellaneous journals (move_type = 'entry')` are not linked to Chilean electronic documents, so the numeric folio validation should not apply to them. **Fix:** This commit ensures that the validation is not raised for `miscellaneous` journal types by excluding miscellaneous journals from the numeric folio validation constraint. [1]: https://github.com/odoo/odoo/blob/f39785bcddd1eb5b7fb503d053c9bb66e2a0f15c/addons/l10n_cl/models/account_move.py#L20-L30 opw-5926773 Forward-Port-Of: odoo/odoo#248965
This fixes an incorrect update in the accounting module related to checking user permissions. It helps ensure the right users can access or perform accounting actions as intended, avoiding disruptions caused by the earlier forward-port mistake.
Original PR description
Bad fix during the forward port of [1]. Was good in saas-18.3[^2] and in 19.0[^3]. [1]: a2b3ca73fd63108fc70a5cec8ef328c150f85554 [^2]: 4816dc594edbd4158b2b071eb5a2eec3c862c8df [^3]: eddc0694b2b3b01f459122bc622876ad82ace039
This fix ensures the Hungarian tax audit export does not accidentally save temporary invoice chain changes while preparing the export. It helps keep invoice records unchanged after audit exports, reducing the risk of unintended accounting data updates.
Original PR description
At the moment, the Hungarian tax audit export wizard's `action_export` creates a savepoint with `flush=False`. The intention of this savepoint is to roll back the changes to `l10n_hu_edi_invoice_chain` once the savepoint exits. But because the changes to `l10n_hu_edi_invoice_chain` stay in cache, and the cache is not flushed before the savepoint is created nor cleared afterwards, those changes end up being committed to DB. Which is precisely what the savepoint was there to prevent. Solution: we use `flush=True` to make sure the cache is flushed before and cleared after the savepoint. task-none Forward-Port-Of: odoo/odoo#251322 Forward-Port-Of: odoo/odoo#250971
The Bulgarian localization now uses corrected tax names and sets the default purchase tax to the appropriate 20% FTC option instead of 20% PTC. This helps businesses using the Bulgarian setup apply clearer, more accurate tax configuration by default.
Original PR description
Fixing incorrect tax names and changing the default purchase tax to 20% FTC instead of 20% PTC. task-5935754 Forward-Port-Of: odoo/odoo#250991 Forward-Port-Of: odoo/odoo#249269
Point of Sale session chatter now shows cash opening and closing details in the user's selected language. This improves clarity for non-English-speaking users reviewing POS session activity.
Original PR description
**Problem:** When opening or closing a POS session, chatter messages display untranslated English text regardless of the user's language setting. **Steps to reproduce:** 1. Set user language to any non-English language (e.g., Spanish) 2. Open a POS session and register cash in/out operations 3. Close the session 4. Check the chatter messages - labels appear in English **Current behavior:** Messages display in English: "Opening cash difference", "Opening cash expected", "Opening cash counted", "Closing difference", etc. **Expected behavior:** Messages should be translated according to the user's language setting. **Cause of the issue:** The hardcoded strings were not wrapped in the translation function `_()`, preventing them from being translated. **Fix:** Wrap the concatenated strings with `_()` to enable proper translation of all cash details messages. opw-5185310 Forward-Port-Of: odoo/odoo#248982 Forward-Port-Of: odoo/odoo#244501
This update corrects an accounting check so it is applied to one bank-related record at a time as intended. This helps avoid occasional errors or unreliable results when validating trusted bank account information.
Original PR description
In some cases, the check was done on multiple records, though the method should be called on one and only one record. Forward-Port-Of: odoo/odoo#251589 Forward-Port-Of: odoo/odoo#251457
Timesheet changes on project tasks now preserve manually set costs on related sales order lines for additional service invoicing policies. This prevents unexpected margin changes when employees update their timesheets.
Original PR description
Originally, timesheet updates for tasks associated with sale order lines would cause the cost (purchase_price) to be recomputed. However, this was prevented if the invoice policy was 'ordered_prepaid.' This should also apply to 'delivered_manual' and 'delivered_milestones.' Otherwise, any timesheet updates will recompute the sales.order.line purchase_price field. Steps to reproduce: 1. Create a service product that creates a project/tasks 2. Create a sales order with the product and manually set the cost 3. Assign the timesheets of the task to an employee 4. Have the employee update their timesheet for the task 5. The cost on the sales order line gets recomputed to the default product price task-5902688 related-pr-205415 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250495
Creating a new contact with autocomplete could fail when a hidden business partner field was made visible through Studio. This fix ensures the Peppol status check only runs once the needed partner information is available, preventing an immediate error during contact creation.
Original PR description
Before this commit, when commercial_partner_id is on the view (possible with web_studio), the value by default is False. When the autocomplete widget is used, many fields could be autofilled and raise _onchange_verify_peppol_status, that requires this field. To avoid this issue we review that the value has been filled. Steps to Reproduce: 1. Open the Contacts app 2. Open Studio on the contact form view 3. Add the field commercial_partner_id to the form view (make it visible) 4. Create a new contact 5. Type a name 6. Select a suggestion from the IAP autocomplete 7. An error is raised immediately OPW-[5896847](https://www.odoo.com/odoo/action-4043/5896847) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249961 Forward-Port-Of: odoo/odoo#248895
This update fixes a minor issue in the Documents app where the action name displayed when creating account moves was inconsistent. Now, the action name accurately reflects the type of document being processed (e.g., 'Vendor Bills' for vendor bills), providing a clearer and more intuitive user experience. This ensures users are always directed to the correct functionality.
Original PR description
Previously, creating account moves from the Documents app opened the account.move list view with a static `Invoices` title, which was not explicit for all move types. Steps to reproduce: 1. Select suitable PDFs in Document App. 2. Click on `Vendor Bill`. 3. See the name of action (below Breadcrumbs) should be `Vendor Bills` instead of `Invoices` This fix adds and uses a mapping based on move_type to set the correct action name (e.g., Vendor Bills) after record creation. task-5983372 Forward-Port-Of: odoo/enterprise#109180
This update addresses a potential issue in the Swiss payroll reporting process. Specifically, it now displays a warning instead of an error when the AVS (Authorized Vendor System) value is negative, improving the user experience and preventing disruptions to payroll calculations. This change ensures accurate reporting and avoids unnecessary alerts.
Original PR description
Forward-Port-Of: odoo/enterprise#109046
This update corrects an issue where the display of shift durations in the Planning app was inaccurate when shifts spanned across multiple days. The fix removes outdated logic that truncated shift names, ensuring correct hour representation regardless of the shift's length. This improves the accuracy of shift scheduling and reporting.
Original PR description
### Issue: The pill name contains the hours when it spans over the next day for less than 3 hours but not if more than 3 hours. ### Steps to reproduce: - Go to Planning app - Create a shift for an…
### Issue: The pill name contains the hours when it spans over the next day for less than 3 hours but not if more than 3 hours. ### Steps to reproduce: - Go to Planning app - Create a shift for an employee from 3pm to 2am (over two days) - The hours of the shift are displayed - Modify the shift end to 3am - The hours of the shift aren't displayed ### Cause: Before the refactor adapting the gantt view to OWL, when a shift spanned over two days less than three hours, then the gantt view truncated the pill to display it in only one day. (see [`_snapToGrid()`](https://github.com/odoo/enterprise/blame/a16b2ef569903c0ae5803c169dbd68acd0141fe1/web_gantt/static/src/js/gantt_row.js#L1044-L1072)) The same logic was done for the computation of the pill's name in [this commit](https://github.com/odoo/enterprise/commit/98a86cbacf484646f486e4648788cfa53cc9648c). But as the pills are no longer truncated since 17.0, the computation of pill names is faulty. ### Solution: We remove the checks of the 3-hour margin. This also makes the variable `spanMoreThanOneDay` useless, so we delete it. opw-5881532 Forward-Port-Of: odoo/enterprise#109217 Forward-Port-Of: odoo/enterprise#107233
This update corrects a problem with how leave periods are tracked, specifically related to time zone differences. By using a new date field, the system now accurately reflects leave interruptions, ensuring correct payroll calculations and reporting. This resolves potential scheduling discrepancies.
Original PR description
This commit fixes the leaves work interruption constraint by replacing `date_from` and `date_to` with `request_date_from` and `request_date_to`, thereby resolving any inconsistencies that may arise from time zone differences. task-5966780 Forward-Port-Of: odoo/enterprise#109114 Forward-Port-Of: odoo/enterprise#108541