Daily updates from Odoo
Friday, February 27, 2026
12 changes · saas-18.2
Resolved issues and error corrections
This update fixes a problem where archived employees incorrectly retained their appraisal dates, causing scheduling conflicts. The change ensures that archived employee appraisal dates are cleared, preventing future issues when managing appraisal plans for companies. This improves the accuracy and reliability of the appraisal process.
Original PR description
**Steps to reproduce:** Based on this feedback https://www.odoo.com/odoo/project.task/5270281 companies with archived employees face an issue when they try to toggle Appraisals Plans from Appraisls -> Configuration -> Settings -> Appraisals Plans **Issue:** The propblem is that when employees with next appraisal date are archived, their next appraisal date is not cleared which leads to past date conflicts upon trying to set the next appraisals dates for all the employees (which is done through toggling the Appraisals Plans checkbox) **Solution:** - Unset the next appraisal date upon archiving an employee - exclude archived employees from _compute_next_appraisal_date method Task: 5354002 Forward-Port-Of: odoo/enterprise#108505 Forward-Port-Of: odoo/enterprise#100437
This update fixes the XML templates used for Dutch SBR and ICP reports to align with the latest 2026 version of the Dutch taxonomy. This ensures accurate reporting for our Dutch customers, complying with local tax regulations and improving data reliability.
Original PR description
Fix the xml SBR and SBR ICP file template for the 2026 version of dutch taxonomy Documentation: https://www.sbr-nl.nl/werken-met-sbr/taxonomie/documentatie-nederlandse-taxonomie task-5974129
This update resolves an issue where rapidly clicking the 'Back' button during barcode internal transfer creation resulted in duplicated quantities being added to the transfer. The fix ensures that multiple back clicks don't trigger redundant saving operations, preventing incorrect quantity calculations.
Original PR description
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By…
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By Quantity** and set some *barcode* * Update the on-hand quantity for the product and assign it to one packages. * Open *Barcode > Operations > Internal Transfer* and create a new transfer. * Click the *gear icon* in the top-right corner to open the barcode scanning flow. * manually enter the created product barcode and apply it. * Click the **Back** button multiple times in quick succession. * Go to the backend and open the created internal transfer. **Observed behavior:** * The internal transfer is created with *double quantities* compared to what was added in the barcode interface. **Cause:** * When clicking the *Back* button, the following flow is triggered: `exit()` → `beforeQuit()` → `save()`. https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/components/main.js#L406-L414 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L473-L475 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_picking_model.js#L828-L832 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L477-L483 * If the button is clicked multiple times rapidly, `exit()` is called again before the previous `save()` RPC completes. * This results in multiple `save()` calls being executed, causing duplicated quantities on the picking. reference - https://github.com/odoo/enterprise/pull/103999/changes/b791239c154deb6a25f85d65ebc72e3ac53b6c74 **Fix:** * Prevent rapidly clicking the Back button multiple times does not multiply quantities. --- opw-5375899 Forward-Port-Of: odoo/enterprise#108788 Forward-Port-Of: odoo/enterprise#103130
This update corrects a previous failed backport caused by attempting to use a field that hadn't been implemented in the 18.2 branch. The commit removes the reliance on this missing field, ensuring the backport now functions correctly. This resolves a technical issue preventing the update.
Original PR description
A previous backport was using a field that was not yet present in the 18.2 branch, which caused the backport to fail. This commit remove the use of the field. support: 5975960
This update resolves an issue where taxes weren't correctly calculated during Google Pay (GPay) express checkout using Stripe. The fix ensures that Avatax taxes are now accurately applied, aligning payment amounts with the final order total. This improves payment accuracy and prevents discrepancies for customers using GPay.
Original PR description
## Versions 17.0+ ## Issue Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes. ## Steps to reproduce…
## Versions
17.0+
## Issue
Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes.
## Steps to reproduce
*Ensure the Stripe account has activated Google Pay* *This requires a complete Google profile on Google Chrome (with a valid payment method)*
- Setup Stripe payment method in test mode with Express Checkout;
- In the Settings, in the Accounting section:
- Setup Avatax;
- Set main Sales/Purchase taxes to 0.
- Create a new product with 0% selling taxes and any Avatax category;
- Activate fiscal position and enable automatic detection;
- Open a Chrome session with the Google profile:
- Go to the shop;
- Add the product you created to the cart;
- Enter the cart;
- Click the "Buy with GPay" button:
- The amount is equal to the sales price excluding taxes.
- Go to the Sales app and open the newly created order:
- The total amount differs from the amount paid (cf. transaction).
opw-5020793
Forward-Port-Of: odoo/enterprise#108873
Forward-Port-Of: odoo/enterprise#101579This update fixes an issue where newly hired employees were incorrectly inheriting their private email address as their work email. The fix ensures that the employee's work email field is properly cleared during the contract creation process, preventing this duplication. This ensures accurate email data for new employees.
Original PR description
**Steps to Reproduce:** 1. Send an offer to an applicant. 2. The applicant submits their details via the salary configurator and enters their private email in the Email field. 3. Once the offer and contract are signed, an employee record is created in Odoo. 4. In the created employee record, the `work_email` field is populated with the email entered in the salary configurator. This same value is also present in `private_email`, which is correct. **Reason:** - The email entered in the salary configurator is stored on the partner and represents the applicant's private email. - The employee's `work_email` field is linked to the partner's email via compute and inverse methods, causing it to inherit the private email value when the employee record is created. **Solution:** - Explicitly clear the employee's work_email field when the applicant sign. task: 5502797 Forward-Port-Of: odoo/enterprise#108769 Forward-Port-Of: odoo/enterprise#106974
This update fixes a potential issue where after departure payments wouldn't display a clear error message. Now, if a previous payslip isn't available, the system will show a user-friendly validation error, ensuring accurate payment processing. This prevents confusion and streamlines the process for users.
Original PR description
For after departure payment to work, a previous payslip is required in the system. So, instead of having a traceback, display an informative message to the user. task-5933607 Forward-Port-Of: odoo/enterprise#107386
This update resolves an issue preventing power buttons from appearing in Odoo Studio reports. The fix defines a key configuration within the Studio editor, allowing it to correctly access and utilize necessary data. This ensures Studio reports function as expected and provides a more complete editing experience.
Original PR description
Description of the issue: Commit [1] replaces `overlay` with `localOverlay` for the table menu. However, studio uses its own `wysiwyg` instance and config, which does not define `localOverlayContainers`, causing a traceback when `table_menu` accesses `this.config.localOverlayContainers.key`. Solution: - Define `localOverlayContainers` and its corresponding key in studio’s `wysiwyg` config. - Additionally, adjust the table menu position calculation when the table cell is inside an iframe. - Also Before `localOverlayContainers` was not defined in studio, so power buttons did not appear in studio reports. Now that `localOverlayContainers` is defined, power buttons must be excluded from the main plugin to prevent them from appearing inside studio. Community PR: https://github.com/odoo/odoo/pull/250645 [1]: https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec Forward-Port-Of: odoo/enterprise#108724
This update resolves a warning generated during testing of document attachments. The team replaced artificial PDF content with a standard, minimal PDF file used for testing, ensuring consistent and reliable test results. This improves the stability of the testing process.
Original PR description
While creating attachments/documents for testing, using a "fake PDF content" generates warning from PyPDF 5.4.0 (even with `strict=False`) when the said PDF is eventually parsed. This commit replaces those "fake PDF content" by reading the "minimal" PDF file provided for testing purposes in `base`. runbot-231278 Forward-Port-Of: odoo/enterprise#108779
This update corrects a technical issue in the Spanish reporting module (l10n_es_reports) where an unnecessary date setting was added. This change ensures that reports are generated accurately and reliably, preventing potential data discrepancies. The fix was implemented as a routine maintenance update.
Original PR description
In the Forward Port of this PR: https://github.com/odoo/enterprise/pull/108575 A date_scope was wrongly added opw-5363664 Forward-Port-Of: odoo/enterprise#108886
This update corrects a technical issue that could cause inconsistencies between payslips and their associated line items. The change ensures that all payroll data remains synchronized, preventing potential reporting errors and maintaining accurate financial records. This resolves a minor disruption to payroll processing.
Original PR description
Forward-Port-Of: odoo/enterprise#108729
This update resolves an issue where the cash drawer wasn't automatically opening when the cash details popup was accessed for Italian Point of Sale (POS) systems. The fix ensures that the cash drawer opens consistently, regardless of whether the POS session is open or closed, improving the user experience for Italian retailers. This was a simple function call that was missed.
Original PR description
When opening the cash details popup the cash drawer should be opened. It was not the case for the Italian fiscal printer. Steps to reproduce: ------------------- * Setup a Italian fiscal printer with cash drawer support * Open PoS * Open the cash details popup > Observation: The cash drawer does not open * Try to close the PoS session * Open the cash details popup > Observation: The cash drawer opens Why the fix: ------------ The cash drawer opening function was simply not called opw-5391094 Forward-Port-Of: odoo/enterprise#107987