Daily updates from Odoo
Monday, June 1, 2026
327 changes
18 changes
Resolved issues and error corrections
This update resolves an issue where Odoo was generating incorrect CFDI (Mexican electronic invoice) XML files when using a specific cash rounding strategy. The fix ensures that cash rounding amounts are properly handled according to SAT regulations, preventing XML rejection errors and ensuring compliance. This improves the accuracy of invoices for Mexican customers.
Original PR description
When using the 'add_invoice_line' cash rounding strategy, Odoo adds a journal line with display_type='rounding'. This line has no product and therefore no ClaveProdServ, causing PAC to reject the XML with error 301. Per SAT regulations, cash rounding is not a valid CFDI concept. The CFDI must report the pre-rounding amounts (e.g. 99.80); the rounding difference (e.g. 0.20) belongs only in the journal entry on the accounting side. opw-6024078 Forward-Port-Of: odoo/enterprise#117400 Forward-Port-Of: odoo/enterprise#112633
This update resolves an issue where manually creating a bill from the purchase dashboard defaulted to the wrong journal. Now, the system correctly uses the journal selected when the 'Create a bill manually' link was accessed, ensuring bills are created in the appropriate accounting context. This improves the accuracy and reliability of purchase billing.
Original PR description
This commit fixes the default journal used when pressing "Create a bill manually" on a purchase journal in the journals dashboard. Previously, when creating a bill manually, it would be created on the default purchase journal. Now, the correct purchase journal is chosen depending on which journal I pressed the "creating a bill manually" link from. task-6167135 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261586
This update fixes an issue where orders captured in a POS session would incorrectly reappear in a new session after a device was disconnected. This prevented confusion for users regarding order dates and ensures accurate session tracking. The change improves the reliability of the Point of Sale system.
Original PR description
Before this commit, if an order was captured in a session but could not be synced to the server, and the session was closed from another device, the order would be captured in the opening control session that created after the closing. This could lead to confusion for the user as the session opening date would be after the order capture date. opw-6207434 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263776
This update resolves an issue where the Odoo org chart wouldn't load correctly when employee records had missing or incorrect date information. The fix ensures the chart loads properly by defaulting to a '0' value when the employee's write date is unavailable, preventing a crash.
Original PR description
### Description of the issue / feature this PR addresses The Odoo 19.0 \`hr_org_chart\` controller passes \`employee.write_date\` to JS as a cache-busting key: \`\`\`python #…
### Description of the issue / feature this PR addresses The Odoo 19.0 \`hr_org_chart\` controller passes \`employee.write_date\` to JS as a cache-busting key: \`\`\`python # addons/hr_org_chart/controllers/hr_org_chart.py:35 write_date=int(employee.write_date.timestamp()) * 1000, # to have it in milliseconds for js \`\`\` When \`hr_employee.write_date\` is NULL the ORM returns \`False\` for the field, so the unconditional \`.timestamp()\` call raises: \`\`\` AttributeError: 'bool' object has no attribute 'timestamp' \`\`\` This crashes the employee form view on click for any record with NULL \`write_date\`. NULL audit columns can occur in legacy databases — records inserted via direct SQL by data-loaders, rows carried forward from very old Odoo versions that did not always populate \`_log_access\` columns, or data restored from anonymised backups. The ORM's \`vals.setdefault\` defaults in \`_log_access\` do not override an explicit falsy value passed by callers. This is a regression vs 18.0 — the 18.0 \`_prepare_employee_data\` did not include \`write_date\` at all. ### Behaviour before this PR Opening the form view of an employee with NULL \`write_date\` (any affected employee record) raises \`AttributeError\` and the org chart fails to load. ### Behaviour after this PR The controller falls back to \`0\` when \`write_date\` is missing — the same defensive pattern already used in \`odoo/addons/base/models/avatar_mixin.py:67\`: \`\`\`python bgcolor = get_hsl_from_seed(self[self._avatar_name_field] + str(self.create_date.timestamp() if self.create_date else "")) \`\`\` The org chart loads; the JS cache key for that one record is \`0\` until the record is next written (which will set \`write_date\` via the normal ORM path). No user-visible regression on healthy rows. Forward-Port-Of: odoo/odoo#264591
This update makes carousels on the website more user-friendly by pausing automatic sliding when a user prefers reduced motion. It also increases the time between carousel image changes from 1 second to 5 seconds, preventing a jarring and fast-paced experience. This enhances overall website performance and accessibility.
Original PR description
Auto-sliding carousels should be paused if the user chose prefers reduced motion. This commit also increases the fallback interval when none is set from 1s to 5s. Cycling through images every second is much too fast. task-5470023 Forward-Port-Of: odoo/odoo#266997 Forward-Port-Of: odoo/odoo#250169
This update fixes an issue where the text color button in the HTML editor wasn't consistently updating with the color picker. The fix ensures the button's active state accurately reflects the selected color, improving the user experience when choosing text colors.
Original PR description
Problem: The state of the text color button is not synchronized with the color picker state. When the picker is open, the button is sometimes not shown as active. Cause: The `.active` class depends…
Problem: The state of the text color button is not synchronized with the color picker state. When the picker is open, the button is sometimes not shown as active. Cause: The `.active` class depends on `colorPicker.isOpen`, which does not trigger a rerender when updated. As a result, Owl does not refresh the button state when the picker opens or closes. Solution: Use a component state for the picker visibility and update it through `onOpen` and `onClose` callbacks so Owl rerenders and properly adds or removes the `active` class. Steps to reproduce: - Select some text and expand the toolbar. - Click the text color button to open the color picker. - Observe that the text color button is not active. - Click on the "Custom" tab in the color picker. - Observe that the text color button becomes active. task-6205286 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267065 Forward-Port-Of: odoo/odoo#263754
This update addresses a warning message that appeared during AI development in Odoo 19.3. The change simply keeps a previously disabled setting, allowing the warning to remain visible as it's considered acceptable. This ensures continued monitoring and doesn't impact core functionality.
Original PR description
This reverts commit e1c71a90b3e7163733cba3da401eaf473f190fef. The warning is fine. https://github.com/odoo/odoo/pull/259007#issuecomment-4299650605 > il fallait justement stop le forward-port en 18.2, on veut le warning, mais on n'avait pas la possibilité d'en avoir un avant 18.1 Forward-Port-Of: odoo/odoo#266967 Forward-Port-Of: odoo/odoo#262841
This update resolves an issue where sparse fields containing dates, datetimes, or binary data couldn't be correctly serialized into JSON. The fix ensures that Odoo's standard JSON serialization tools handle these data types properly, preventing errors during data transfer and storage. This improves the reliability of data exchange within the Odoo system.
Original PR description
Storing a sparse field of type Date, Datetime or Binary raises a TypeError because json.dumps() cannot natively serialize the Python objects returned by convert_to_read (date/datetime instances and bytes). Fix Serialized.convert_to_cache to pass json_default (from odoo.tools.json) as the default serializer to json.dumps(). This handles Date, Datetime and Binary values without any extra conversion step in _inverse_sparse, and reuses the existing Odoo infrastructure instead of introducing a custom helper. Steps to reproduce: 1. Create a model with a sparse field of type Date, Datetime or Binary 2. Set a value on it 3. → TypeError: Object of type date is not JSON serializable --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266779
This update fixes an issue where inventory value calculations were inaccurate when a warehouse location was archived. Previously, archived locations weren't properly considered when determining the total value and average cost of inventory. This change ensures that all inventory, including items in archived locations, is accurately reflected in valuation reports.
Original PR description
When a receipt dest location or delivery source location get archived, the corresponding move may not be taken into account when computing the total_value / avg_cost at date. OPW-6099192 --- ### Test…
When a receipt dest location or delivery source location get archived, the corresponding move may not be taken into account when computing the total_value / avg_cost at date.
OPW-6099192
---
### Test result without fix
```
2026-04-23 06:30:34,016 10516 INFO oes_test_19 odoo.addons.stock_account.tests.test_stockvaluation: Starting TestStockValuation.test_archived_location_valuation ...
2026-04-23 06:30:34,255 10516 INFO oes_test_19 odoo.addons.stock_account.tests.test_stockvaluation: ======================================================================
2026-04-23 06:30:34,255 10516 ERROR oes_test_19 odoo.addons.stock_account.tests.test_stockvaluation: FAIL: TestStockValuation.test_archived_location_valuation
Traceback (most recent call last):
File "/home/odoo/Odoo/src/19.0/odoo/addons/stock_account/tests/test_stockvaluation.py", line 3326, in test_archived_location_valuation
self.assertEqual(self.product_avco.with_context(to_date=date_1).avg_cost, 10)
AssertionError: 20.0 != 10
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#264694
Forward-Port-Of: odoo/odoo#260922This update resolves a bug that caused the system to crash when signing salary contracts with a company car option in the configurator. The fix ensures the system correctly handles different contract scenarios, preventing errors and improving stability for users. This change impacts the Belgian payroll functionality.
Original PR description
Before this commit, signing a salary contract in the configurator with a company car selected could crash on the cp200_employees_salary_company_car (ATN.CAR) rule with KeyError('origin_version_id'), because the Belgian _get_period_contracts() accessed self.env.context['origin_version_id'] directly whenever salary_simulation was set, while hr_version_context injects salary_simulation=True without that key.
After this commit, the lookup uses .get() and falls back to the default behavior so the rule evaluates safely.
task-6240418
Forward-Port-Of: odoo/enterprise#118392This update optimizes the HTML editor's performance, specifically when handling large tables like the Accounting Balances Sheets. By changing a selector, the system now recalculates styles more efficiently, reducing delays during actions like hovering, resizing, or sorting.
Original PR description
Avoid using the :has() selector and use a specific class on the body instead to replicate the same behavior. This reduces work during the "Recalculate Style" phase (for example when hovering rows in large tables such as the Accounting > Balances Sheets). It lowers recalculation time during window resizes, heavy scrolling, and table sorting by preventing broad selector matches and limiting style checks to elements with the specific class. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267165
This update corrects an issue where placeholder text within website translations was incorrectly displayed as HTML spans. Previously, when translating blog titles, the system would wrap the placeholder text in a `<span/>` tag, leading to a broken display. This fix ensures placeholder text is correctly rendered as plain text, improving the user experience across multiple languages.
Original PR description
Since placeholder attribute is translated, for non-form elements placeholder attributes that contain a translation <span/> need to be unwrapped to restore the plain text value. Steps to reproduce the issue: - Have website and website_blog installed - Add a second language - Open a blog post in your second lanuage - Start translating - Remove the blog title => Shown placeholder text is <span ...> task-5190459 Forward-Port-Of: odoo/odoo#267327 Forward-Port-Of: odoo/odoo#263320
This update automatically sets the deductibility prorata rate to 100% by default in the Iranian (l10n_ma) tax reports. Previously, users had to manually configure this rate, which often led to inaccurate tax reports. This change simplifies the process and ensures more reliable tax calculations.
Original PR description
Users often forget to complete the deductibility prorata rate, which makes the tax report seems buggy. Set the rate to 100% by default. task-6092580 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263486
This update fixes an issue where replenishment order quantities weren't being rounded correctly when the product and replenishment UoM were the same. Previously, orders would sometimes request fractional units, leading to overstocking. Now, quantities are rounded to the nearest whole unit, ensuring accurate stock levels and reducing potential waste.
Original PR description
**Issue** Replenishment quantity is not rounded when the replenishment UoM is the same as the product UoM. **Steps to reproduce**: - Enable "Units of Measure & Packagings" setting - Create a tracked…
**Issue** Replenishment quantity is not rounded when the replenishment UoM is the same as the product UoM. **Steps to reproduce**: - Enable "Units of Measure & Packagings" setting - Create a tracked product and add a vendor using the same uom (ex: Unit) - Create a replenishment order rule: - min = 0 - max = 10 - multiple: Unit - Create a sale order for that product with 1.11 units -> It tries to replenish 11.11 units instead of 12 **Cause**: While computing `qty_to_order`, it rounds using the given multiple via `_get_multiple_rounded_qty`: https://github.com/odoo/odoo/blob/995629db3231de944710751c3184bf1b8b1355c7/addons/stock/models/stock_orderpoint.py#L471-L475 However, `_get_multiple_rounded_qty` skips rounding when the replenishment UoM matches the product UoM: https://github.com/odoo/odoo/blob/995629db3231de944710751c3184bf1b8b1355c7/addons/stock/models/stock_orderpoint.py#L802-L809 opw-[6015189](https://www.odoo.com/web#id=6015189&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#262105 Forward-Port-Of: odoo/odoo#256006
This update streamlines the calculation of offer fields related to employee contracts, preventing unnecessary recomputations and ensuring accurate updates. Additionally, a recent change was corrected to properly handle payroll flows, ensuring consistent offer field visibility across all versions.
Original PR description
**Problem:** Since this https://github.com/odoo/enterprise/pull/103846, `employee_version_id` depends on `contract_start_date` to adjust the employee state based on the contract date. This introduced…
**Problem:** Since this https://github.com/odoo/enterprise/pull/103846, `employee_version_id` depends on `contract_start_date` to adjust the employee state based on the contract date. This introduced an unnecessary dependency chain: ``` contract_start_date -> employee_version_id -> contract_template_id -> wages and other offer fields ``` As a result, updating `contract_start_date` invalidates and recomputes the whole chain, even when `employee_version_id` does not actually change. In addition, offer fields were coupled in a single compute, causing unrelated fields to be reset to template values when only one field required recomputation. **Fix:** - `contract_template_id` compute now depends on `employee_id` instead of `employee_version_id`, and directly uses the employee's `version_id`, breaking the chain while preserving default behavior. - The offer fields computations were also split to avoid unintended recomputations and field resets. - Simplified `_get_version` by always copying values from the template to the currently active version. --- **Additional fix:** The `is_hr_payroll` context flag is used to distinguish payroll vs recruitment flows when creating an offer with both `employee_id` and `applicant_id` unset. A recent change in [Task #6094737](https://www.odoo.com/odoo/project/1251/tasks/6094737) did not account for this flag, causing both fields to be hidden when opening the form from Payroll (a new feature added in saas-19.3). This is fixed by properly considering `is_hr_payroll`, restoring consistent behavior across all versions. Task: 6158245 Forward-Port-Of: odoo/enterprise#115408
This update resolves a rare test failure related to timing issues in the website's interaction tests. By eliminating a potential delay introduced by animation frame waits, the test now consistently passes. The fix also includes minor improvements to the test's structure for enhanced reliability.
Original PR description
This commit fixes the test "waitForTimeout does not trigger update if interaction is not ready yet", which could very rarely fail on runbot. **Origin of the problem** The test relies on precise…
This commit fixes the test "waitForTimeout does not trigger update if interaction is not ready yet", which could very rarely fail on runbot. **Origin of the problem** The test relies on precise timings, but the helper `advanceTime` could introduce a non-deterministic lag because, when called with default options, it awaits for an animation frame. If the lag happens to be too long, the second `verifySteps` is called too late and the test fails. **Fix** The helper `advanceTime` is now called with the option `animationFrame` set to false to avoid awaiting for an animation frame. For additional safety, the waiting time is also reduced. Two changes not directly related to this problem have been applied to improve the test: 1. an unnecessary `await` in `willStart` has been removed; 2. the `animationFrame` has been set to false also on the second `advanceTime` (a non-deterministic lag here can't fail the test, but still there is no reason to await for the animation frame). runbot-243515 Forward-Port-Of: odoo/odoo#266432
This update fixes an issue where project records weren't opening in a new tab when a user initiated the action. Previously, users had to manually click and drag to open records in a separate window. Now, a simple Ctrl+click will correctly open records in a new tab, improving user workflow and efficiency.
Original PR description
Steps to reproduce ================== - Install project,board - Go to project - Open any project - Click on the cog menu - Click on Dashboard > Add to my dashboard - Confirm - Open the dashboard app > My dashboard - ctrl+click on a record => The record is opened in the current tab Cause of the issue ================== The params newWindow passed to the selectRecord props was ignored Forward-Port-Of: odoo/odoo#267059 Forward-Port-Of: odoo/odoo#266729
This update resolves an issue where branch users without access to a parent company couldn't create transactions in the parent company's currency journals. The fix ensures accurate currency conversion by temporarily elevating permissions during the transaction process, allowing branch users to manage transactions in parent company accounts.
Original PR description
**Problem:** When a branch user with no access to the parent company tries to create a transaction for a parent company's journal with a foreign currency set, this will raise an access error. **Steps…
**Problem:** When a branch user with no access to the parent company tries to create a transaction for a parent company's journal with a foreign currency set, this will raise an access error. **Steps to Reproduce:** - Make a branch of "My Company (San Francisco)" - Set user "Marc Demo" to only have access to the branch - Add a new bank journal set to "EUR" currency - Switch to Marc Demo - Try to add a transaction in the new bank journal **Root Cause:** When a transaction is created, Odoo determines the amount in company currency by converting it from the foreign currency. The method to convert currency uses "with_company()" to use the company's rates, but the allowed companies of the branch user does not have access to the parent company, causing an access error. **Solution:** Call the currency conversion with sudo() to ensure access to the relevant companies. Ticket [link](https://www.odoo.com/odoo/project.task/6186901) opw-6186901 Forward-Port-Of: odoo/odoo#263968 Forward-Port-Of: odoo/odoo#263425
30 changes
Enhancements to existing features
This update clarifies how half-day work periods are displayed on payslips. Previously, half-days were shown as separate entries, which was confusing. Now, the system consolidates these entries for a clearer and more straightforward view of employee work time and pay.
Original PR description
In order to clearly distinguish work days that extended full day or half day, the worked days under the payslips will not display both entries as separate types with the half days flagged Task: 5975762 Forward-Port-Of: odoo/enterprise#112328
This update improves the handling of Philippine taxes within Odoo. Specifically, it reorganizes VAT and reverse charge taxes into groups with positive and negative components, streamlining calculations. It also disables automatic tax closing entries for withholding taxes, ensuring accurate reporting.
Original PR description
Restructure FWVAT DS and FWVAT EM from single percentage taxes into group taxes with two children each: a positive 12% input VAT child and a negative 12% reverse charge child (FWVAT RC). Also, we disable tax closing entry for WHT taxes. task-6146238 Forward-Port-Of: odoo/odoo#266625
Resolved issues and error corrections
This update resolves an issue where resetting payroll work entries (attendance) would unexpectedly delete them. The problem stemmed from a mismatch between the calendar timezone and the employee's timezone when calculating the reset window. The fix ensures work entries are handled correctly regardless of timezone, preventing data loss.
Original PR description
Setup: Set the work entry source to attendance for an employee with active contract and change his timezone so that it differs from the working schedule one. Reset previous/next day delete Work Entry (payroll) - Step to reproduce: after an attendance was created, go to "Work Entries" in payroll, select the previous/next day and hit "Reset Selected Work Entries". The Work Entry will disappear. - Cause: reset window computed with calendar tz and work entry computed with user tz - Solution: localize work entries using calendar or user tz - Test: testing positive ans negative tz in hr_work_entry_attendance (enterprise) Task: 6072325 Forward-Port-Of: odoo/odoo#266537 Forward-Port-Of: odoo/odoo#257309
This update corrects a bug where the 'Reset Selected Work Entries' function in the payroll module was unexpectedly deleting work entries due to timezone discrepancies. The fix adjusts the system's timezone handling to ensure accurate work entry management, preventing data loss and improving payroll processing reliability.
Original PR description
Setup: Set the work entry source to attendance for an employee with active contract and change his timezone so that it differs from the working schedule one. Reset previous/next day delete Work Entry (payroll) - Step to reproduce: after an attendance was created, go to "Work Entries" in payroll, select the previous/next day and hit "Reset Selected Work Entries". The Work Entry will disappear. - Cause: domain to nullify using wrong tz - Solution: adjust domain to use calendar tz - Test: testing positive ans negative tz in hr_work_entry_attendance (enterprise) Task: 6072325 Forward-Port-Of: odoo/enterprise#118441 Forward-Port-Of: odoo/enterprise#114148
This update resolves an issue where Odoo was incorrectly generating CFDI invoices in Mexico, leading to XML rejection by tax authorities. The fix ensures that cash rounding lines, which are not valid CFDI concepts, are excluded, aligning with SAT regulations. This prevents errors and ensures accurate invoice generation.
Original PR description
When using the 'add_invoice_line' cash rounding strategy, Odoo adds a journal line with display_type='rounding'. This line has no product and therefore no ClaveProdServ, causing PAC to reject the XML with error 301. Per SAT regulations, cash rounding is not a valid CFDI concept. The CFDI must report the pre-rounding amounts (e.g. 99.80); the rounding difference (e.g. 0.20) belongs only in the journal entry on the accounting side. opw-6024078 Forward-Port-Of: odoo/enterprise#117400 Forward-Port-Of: odoo/enterprise#112633
This update fixes an issue where manually creating a bill from the purchase dashboard would always use the default purchase journal. Now, the system correctly selects the journal the user was previously viewing, ensuring bills are created in the appropriate accounting context. This improves the accuracy and reliability of purchase transactions.
Original PR description
This commit fixes the default journal used when pressing "Create a bill manually" on a purchase journal in the journals dashboard. Previously, when creating a bill manually, it would be created on the default purchase journal. Now, the correct purchase journal is chosen depending on which journal I pressed the "creating a bill manually" link from. task-6167135 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261586
This update corrects an issue where placeholder text within blog posts was incorrectly displayed as HTML spans when translations were applied. The fix ensures that placeholder text always shows as plain text, improving the user experience and consistency across languages. This resolves a visual inconsistency that could confuse users.
Original PR description
Since placeholder attribute is translated, for non-form elements placeholder attributes that contain a translation <span/> need to be unwrapped to restore the plain text value. Steps to reproduce the issue: - Have website and website_blog installed - Add a second language - Open a blog post in your second lanuage - Start translating - Remove the blog title => Shown placeholder text is <span ...> task-5190459 Forward-Port-Of: odoo/odoo#267327 Forward-Port-Of: odoo/odoo#263320
This update ensures that customers only see product categories accessible from their current website view. Previously, some categories were incorrectly displayed on Website 1, leading to a 'Not Found' error. The fix filters categories based on website access, improving the user experience and preventing broken links.
Original PR description
Steps to produce: --- - Install `website_sale` with demo data. - Go to `website > ecommerce > products > ecommerce categories`. - Open `Desks/Components` category > Set website to `My website 2`. -…
Steps to produce: --- - Install `website_sale` with demo data. - Go to `website > ecommerce > products > ecommerce categories`. - Open `Desks/Components` category > Set website to `My website 2`. - Open the shop page on website > Click on Desks category. Issue: --- - The Components subcategory is still displayed on Website 1. - Clicking on it leads to a Not Found page since the category is not assigned to that website. Root cause: --- - At [1], In the category filmstrip template, subcategories are fetched without filtering based on website access. - As a result, categories restricted to another website are still shown. Solution: --- - Filter categories using the `can_access_from_current_website` method to ensure only categories accessible from the current website are displayed. [1]https://github.com/odoo/odoo/blob/900fc043064216c5943ea07392d8120be7b50b63/addons/website_sale/views/templates.xml#L758-L769 opw-6159549 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266637 Forward-Port-Of: odoo/odoo#262410
This update fixes a problem preventing AI Livechat embedded on other websites from receiving AI responses correctly. The previous setup bypassed security controls, and the response format was incompatible. The fix exposes the necessary endpoint as an HTTP stream and ensures the correct guest token is passed, allowing seamless AI interaction within embedded Livechat.
Original PR description
AI livechat embedded on another origin could not receive AI responses. The response stream is requested with fetch(), so it bypassed the livechat CORS routing that only wraps RPC calls. The matching CORS controller was also exposed as JSON-RPC, which cannot return the streamed HTTP response correctly. Expose the CORS endpoint as an HTTP stream, route the embedded fetch call to it, and pass the livechat guest token explicitly. task-id-6201054 Forward-Port-Of: odoo/enterprise#117535
This update resolves an issue preventing correct calculation of the 13th month salary in the Belgian localization. The fix ensures the forced variable salary is properly applied during payslip computation, addressing a previous type error.
Original PR description
Steps to reproduce: * Create a new payslip in belgian localization * Set pay structure type to 13th month * Set the input value for the forced variable salary * Compute the payslip sheet Issue: * Despite the change of benefits to properties, the avg_variable_revenues was still being set as one of the benefit lines instead of ref_property value which was causing an type_error traceback Solution: A simple approach is to be followed to retrieve the value fo the forced variable salary from the actual property being set by the user at the payslip form view and will be accounted for in the payslip computation. Task: 6241608 Forward-Port-Of: odoo/enterprise#118644
This update fixes an issue where orders captured in a POS session would incorrectly reappear in a new session after a device was used to close the original. This prevented users from accurately tracking order history and caused confusion about session dates. The change ensures orders are properly recorded in the intended session.
Original PR description
Before this commit, if an order was captured in a session but could not be synced to the server, and the session was closed from another device, the order would be captured in the opening control session that created after the closing. This could lead to confusion for the user as the session opening date would be after the order capture date. opw-6207434 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263776
This update fixes an issue where POS refund orders were incorrectly showing as paid, leading to an underestimation of the outstanding balance on linked sales orders. The change ensures that refund amounts are properly accounted for when calculating the unpaid balance, improving the accuracy of financial reporting. This resolves a previous bug reported as opw-6190337.
Original PR description
POS refund order lines have a positive `price_subtotal_incl` but represent money returned to the customer. `_compute_amount_unpaid` was treating them as paid amounts, causing the unpaid balance on the linked sale order to be understated. opw-6190337 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263241
This update resolves an issue where the employee org chart would crash when displaying records with a missing 'write_date' field. This occurred due to a type error when attempting to use the timestamp of a NULL value. The fix mirrors a similar pattern used elsewhere in Odoo to gracefully handle missing dates, ensuring the chart loads correctly for all employee records, including those with legacy data.
Original PR description
### Description of the issue / feature this PR addresses The Odoo 19.0 \`hr_org_chart\` controller passes \`employee.write_date\` to JS as a cache-busting key: \`\`\`python #…
### Description of the issue / feature this PR addresses The Odoo 19.0 \`hr_org_chart\` controller passes \`employee.write_date\` to JS as a cache-busting key: \`\`\`python # addons/hr_org_chart/controllers/hr_org_chart.py:35 write_date=int(employee.write_date.timestamp()) * 1000, # to have it in milliseconds for js \`\`\` When \`hr_employee.write_date\` is NULL the ORM returns \`False\` for the field, so the unconditional \`.timestamp()\` call raises: \`\`\` AttributeError: 'bool' object has no attribute 'timestamp' \`\`\` This crashes the employee form view on click for any record with NULL \`write_date\`. NULL audit columns can occur in legacy databases — records inserted via direct SQL by data-loaders, rows carried forward from very old Odoo versions that did not always populate \`_log_access\` columns, or data restored from anonymised backups. The ORM's \`vals.setdefault\` defaults in \`_log_access\` do not override an explicit falsy value passed by callers. This is a regression vs 18.0 — the 18.0 \`_prepare_employee_data\` did not include \`write_date\` at all. ### Behaviour before this PR Opening the form view of an employee with NULL \`write_date\` (any affected employee record) raises \`AttributeError\` and the org chart fails to load. ### Behaviour after this PR The controller falls back to \`0\` when \`write_date\` is missing — the same defensive pattern already used in \`odoo/addons/base/models/avatar_mixin.py:67\`: \`\`\`python bgcolor = get_hsl_from_seed(self[self._avatar_name_field] + str(self.create_date.timestamp() if self.create_date else "")) \`\`\` The org chart loads; the JS cache key for that one record is \`0\` until the record is next written (which will set \`write_date\` via the normal ORM path). No user-visible regression on healthy rows. Forward-Port-Of: odoo/odoo#264591
This update makes carousels on the website more user-friendly by pausing automatic sliding when a user prefers reduced motion. It also increases the time between carousel image changes from 1 second to 5 seconds, preventing a jarring and fast-paced experience. This improves accessibility and overall website performance.
Original PR description
Auto-sliding carousels should be paused if the user chose prefers reduced motion. This commit also increases the fallback interval when none is set from 1s to 5s. Cycling through images every second is much too fast. task-5470023 Forward-Port-Of: odoo/odoo#266997 Forward-Port-Of: odoo/odoo#250169
This update resolves a warning message that appeared during AI development in Odoo 19.2. The change ensures the warning remains visible, as it was previously suppressed due to limitations in earlier versions. This maintains visibility into potential issues during AI integration.
Original PR description
This reverts commit e1c71a90b3e7163733cba3da401eaf473f190fef. The warning is fine. https://github.com/odoo/odoo/pull/259007#issuecomment-4299650605 > il fallait justement stop le forward-port en 18.2, on veut le warning, mais on n'avait pas la possibilité d'en avoir un avant 18.1 Forward-Port-Of: odoo/odoo#266967 Forward-Port-Of: odoo/odoo#262841
This update resolves an issue where Odoo couldn't properly serialize Date, Datetime, or Binary values stored in sparse fields when exporting data to JSON. The fix utilizes existing Odoo tools to handle these types natively, preventing errors and ensuring data is consistently serialized. This improves the reliability of data exports and integrations.
Original PR description
Storing a sparse field of type Date, Datetime or Binary raises a TypeError because json.dumps() cannot natively serialize the Python objects returned by convert_to_read (date/datetime instances and bytes). Fix Serialized.convert_to_cache to pass json_default (from odoo.tools.json) as the default serializer to json.dumps(). This handles Date, Datetime and Binary values without any extra conversion step in _inverse_sparse, and reuses the existing Odoo infrastructure instead of introducing a custom helper. Steps to reproduce: 1. Create a model with a sparse field of type Date, Datetime or Binary 2. Set a value on it 3. → TypeError: Object of type date is not JSON serializable --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266779
This update corrects a minor inaccuracy in how remaining days are displayed. Specifically, when deadlines are very close to the current date, the display was sometimes misleading (e.g., showing 'Next month' for a deadline of May 1st when today is April 30th). This change ensures a more precise and user-friendly representation of time remaining.
Original PR description
Luxon is not very accurate when the field is close to today: If today is Apr 30, so a deadline set to May 1 will be displayed as "Next month". In practice, it is not wrong, but it is not very accurate. task-6175442 Forward-Port-Of: odoo/odoo#267102
This update fixes an issue where receipts for orders with many items (over 70) would be cut off mid-print, resulting in incomplete tickets. The fix increases the timeout period for printing, ensuring that all order details are printed correctly, even with extensive product lists. This improves the customer experience and prevents data loss.
Original PR description
**Steps to reproduce:** - Connect an Epson printer - Go to the PoS - Make an order with 50+ products (70 to be safe) - Pay for it and try to print the receipt - It will stop halfway through, and the next ticket will have some leftover lines on top of it **Why the fix:** In d2a4bbc the timeout for the error popup was reduced from 15000 to 3000, and a timeout on the request was also added at 3000. This means that after 3000ms, the printing will stop, even in the middle of printing. Because of this, if the order has too many items, the printing will be forcefully stopped before everything could be printed, and as we stopped it in the middle, some leftover lines can be found on top of the next printed ticket. After this commit, the timeout is set to double the current time, and will be expanded further if we still have some issues. opw-6049062
This update optimizes the HTML editor's performance, specifically when handling large tables like the Accounting > Balances Sheets. By changing a selector, the system now recalculates styles more quickly, reducing delays during actions like hovering or sorting, leading to a smoother user experience.
Original PR description
Avoid using the :has() selector and use a specific class on the body instead to replicate the same behavior. This reduces work during the "Recalculate Style" phase (for example when hovering rows in large tables such as the Accounting > Balances Sheets). It lowers recalculation time during window resizes, heavy scrolling, and table sorting by preventing broad selector matches and limiting style checks to elements with the specific class. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267165
This update automatically sets the deductibility prorata rate to 100% by default in the Iranian (l10n_ma) tax reports. Previously, users had to manually configure this rate, which often led to inaccurate tax reports. This change ensures more reliable tax reporting for businesses using the Iranian localization.
Original PR description
Users often forget to complete the deductibility prorata rate, which makes the tax report seems buggy. Set the rate to 100% by default. task-6092580 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263486
This update fixes an issue where replenishment quantities weren't being rounded correctly when the product and replenishment UoM were the same. Previously, orders were calculated with decimals, leading to inaccurate replenishment amounts. This change ensures that replenishment quantities are rounded to the nearest whole unit, aligning with expected inventory behavior.
Original PR description
**Issue** Replenishment quantity is not rounded when the replenishment UoM is the same as the product UoM. **Steps to reproduce**: - Enable "Units of Measure & Packagings" setting - Create a tracked…
**Issue** Replenishment quantity is not rounded when the replenishment UoM is the same as the product UoM. **Steps to reproduce**: - Enable "Units of Measure & Packagings" setting - Create a tracked product and add a vendor using the same uom (ex: Unit) - Create a replenishment order rule: - min = 0 - max = 10 - multiple: Unit - Create a sale order for that product with 1.11 units -> It tries to replenish 11.11 units instead of 12 **Cause**: While computing `qty_to_order`, it rounds using the given multiple via `_get_multiple_rounded_qty`: https://github.com/odoo/odoo/blob/995629db3231de944710751c3184bf1b8b1355c7/addons/stock/models/stock_orderpoint.py#L471-L475 However, `_get_multiple_rounded_qty` skips rounding when the replenishment UoM matches the product UoM: https://github.com/odoo/odoo/blob/995629db3231de944710751c3184bf1b8b1355c7/addons/stock/models/stock_orderpoint.py#L802-L809 opw-[6015189](https://www.odoo.com/web#id=6015189&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#262105 Forward-Port-Of: odoo/odoo#256006
This update streamlines the calculation of offer fields, resolving performance issues caused by unnecessary dependency chains and redundant computations. Additionally, a fix ensures offer forms display correctly within the payroll workflow, maintaining consistent functionality across versions.
Original PR description
**Problem:** Since this https://github.com/odoo/enterprise/pull/103846, `employee_version_id` depends on `contract_start_date` to adjust the employee state based on the contract date. This introduced…
**Problem:** Since this https://github.com/odoo/enterprise/pull/103846, `employee_version_id` depends on `contract_start_date` to adjust the employee state based on the contract date. This introduced an unnecessary dependency chain: ``` contract_start_date -> employee_version_id -> contract_template_id -> wages and other offer fields ``` As a result, updating `contract_start_date` invalidates and recomputes the whole chain, even when `employee_version_id` does not actually change. In addition, offer fields were coupled in a single compute, causing unrelated fields to be reset to template values when only one field required recomputation. **Fix:** - `contract_template_id` compute now depends on `employee_id` instead of `employee_version_id`, and directly uses the employee's `version_id`, breaking the chain while preserving default behavior. - The offer fields computations were also split to avoid unintended recomputations and field resets. - Simplified `_get_version` by always copying values from the template to the currently active version. --- **Additional fix:** The `is_hr_payroll` context flag is used to distinguish payroll vs recruitment flows when creating an offer with both `employee_id` and `applicant_id` unset. A recent change in [Task #6094737](https://www.odoo.com/odoo/project/1251/tasks/6094737) did not account for this flag, causing both fields to be hidden when opening the form from Payroll (a new feature added in saas-19.3). This is fixed by properly considering `is_hr_payroll`, restoring consistent behavior across all versions. Task: 6158245 Forward-Port-Of: odoo/enterprise#115408
This update resolves a rare test failure related to timing issues in the website's interaction testing. The fix eliminates a potential delay caused by waiting for animation frames, ensuring more reliable test results. This improves the overall stability of the website development process.
Original PR description
This commit fixes the test "waitForTimeout does not trigger update if interaction is not ready yet", which could very rarely fail on runbot. **Origin of the problem** The test relies on precise…
This commit fixes the test "waitForTimeout does not trigger update if interaction is not ready yet", which could very rarely fail on runbot. **Origin of the problem** The test relies on precise timings, but the helper `advanceTime` could introduce a non-deterministic lag because, when called with default options, it awaits for an animation frame. If the lag happens to be too long, the second `verifySteps` is called too late and the test fails. **Fix** The helper `advanceTime` is now called with the option `animationFrame` set to false to avoid awaiting for an animation frame. For additional safety, the waiting time is also reduced. Two changes not directly related to this problem have been applied to improve the test: 1. an unnecessary `await` in `willStart` has been removed; 2. the `animationFrame` has been set to false also on the second `advanceTime` (a non-deterministic lag here can't fail the test, but still there is no reason to await for the animation frame). runbot-243515 Forward-Port-Of: odoo/odoo#266432
This update fixes an issue where the sidebar menu wouldn't scroll properly when it contained a large number of items, preventing users from accessing the bottom menu options. The fix adds scrolling functionality to the sidebar menu, ensuring a smoother user experience, particularly with extensive menus. This resolves a long-standing issue that has persisted across multiple Odoo versions.
Original PR description
Scenario: - set menu bar as sidebar - adds lot of menu item (or decrease page height) - try to scroll to bottom menu item that are not shown Result: you can't see the bottom of the menu Cause: there is no overflow auto on sidebar elements so the default visible is used without possible scroll. This issue doesn't happen for hamburger menu (hamburger template or on mobile) because it wraps the menu in an .offcanvas-body element that has in bootstrap overflow-y: auto Fix: add vertical overflow to o_header_sidebar menu. opw-5486934 --- __pr note__: I'm not sure if there is a reason this was not done yet or if this has just not been reported. The behavior happen from 16.0 to now. Since the query is from 19.0 to lower risk (and since it's not really broken, just not working with a big number of menu) I've targeted 19.0 but I could go lower if wanted. Forward-Port-Of: odoo/odoo#252047
This update resolves an issue where branch users without access to a parent company couldn't create transactions in the parent company's currency journals. The fix ensures accurate currency conversion by temporarily elevating permissions during the transaction process, allowing branch users to manage transactions in parent company accounts.
Original PR description
**Problem:** When a branch user with no access to the parent company tries to create a transaction for a parent company's journal with a foreign currency set, this will raise an access error. **Steps…
**Problem:** When a branch user with no access to the parent company tries to create a transaction for a parent company's journal with a foreign currency set, this will raise an access error. **Steps to Reproduce:** - Make a branch of "My Company (San Francisco)" - Set user "Marc Demo" to only have access to the branch - Add a new bank journal set to "EUR" currency - Switch to Marc Demo - Try to add a transaction in the new bank journal **Root Cause:** When a transaction is created, Odoo determines the amount in company currency by converting it from the foreign currency. The method to convert currency uses "with_company()" to use the company's rates, but the allowed companies of the branch user does not have access to the parent company, causing an access error. **Solution:** Call the currency conversion with sudo() to ensure access to the relevant companies. Ticket [link](https://www.odoo.com/odoo/project.task/6186901) opw-6186901 Forward-Port-Of: odoo/odoo#263968 Forward-Port-Of: odoo/odoo#263425
This update corrects a technical issue in the Peru Accounting Reports module that was causing reports to be rejected by the SUNAT system. Specifically, the report was incorrectly including too much data in field 8 of the DAM document, leading to an error. The fix ensures the report accurately uses the required 3-digit customs dependency code as defined by SUNAT regulations.
Original PR description
**Steps to reproduce:** * Install Peru - Accounting Reports (l10n_pe_reports). * Create a vendor bill with Document Type 50 (Declaración Aduanera de Mercancías - DAM) and a document number in the…
**Steps to reproduce:** * Install Peru - Accounting Reports (l10n_pe_reports). * Create a vendor bill with Document Type 50 (Declaración Aduanera de Mercancías - DAM) and a document number in the standard pediment format (e.g. C235202610-38047). * Go to Accounting > Reporting > Purchase Electronic Record (RCE 8.4). * Export the TXT file and open it. **Observed behavior:** * Field 8 contains the full first numeric block of the document name including the year and sequence digits (e.g. 235202610) instead of only the 3-digit customs dependency code. * SUNAT/SIRE rejects the file immediately because 235202610 does not exist in Table 4 (RS 040-2022), which only defines 3-digit codes. **Cause:** * `_get_serie_folio()` splits the document name by taking everything before the last digit group as the serie. For a name like C235202610-38047 this produces serie = "C235202610", and the existing `serie[1:]` logic strips only the leading letter, leaving "235202610" in field 8 instead of the 3-digit customs dependency code "235". * The same incorrect value was also written to field 28 (aduana_code). * ref : https://www.sunat.gob.pe/legislacion/superin/2022/anexo-040-2022.pdf **Fix:** * For document types 50 and 52, extract the first numeric group from the document name using `re.search(r'\d+', move_name)` and slice the first 3 characters to obtain the customs dependency code as defined in SUNAT Table 4 (always a 3-digit value). * Apply the same logic to field 28 (aduana_code) for consistency. opw-6157662 Forward-Port-Of: odoo/enterprise#115406
This update improves the stability of the KSeF vendor bill download cron job. Previously, a single error in an XML file would halt the entire process. Now, the system gracefully handles parsing errors, logs them for investigation, and continues processing valid invoices, preventing data loss and queue congestion.
Original PR description
### Description of the issue/feature this PR addresses: **Issue:** When downloading vendor bills from KSeF via the cron, the system attempts to parse the XML files sequentially. If a single XML file…
### Description of the issue/feature this PR addresses: **Issue:** When downloading vendor bills from KSeF via the cron, the system attempts to parse the XML files sequentially. If a single XML file is missing something that is expected, the parser raises a UserError. This unhandled exception halts the entire cron job and rolls back the database transaction, clogging up the rest of the queue. **Solution:** This PR wraps the l10n_pl_edi_get_ksef_bill_vals_from_xml parsing step inside a try/except block within the batch download loop. If a UserError is encountered for a specific invoice, the error is logged as a warning, and the cron proceeds. ### Current behavior before PR: A single malformed XML file causes the cron to fail completely. Valid invoices in the same batch are not created due to the halted queue. ### Desired behavior after PR is merged: The cron successfully processes the batch of downloaded XMLs even if one or more files are invalid. Errors on specific invoices are logged for the user to investigate, while the rest of the valid vendor bills in the batch are succesfully created. opw-6179479 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266180
This update resolves a problem where users couldn't confirm shipments due to incorrect province codes being submitted to the UPS API. The fix ensures that only 5-character province codes are used, aligning with the API's requirements and limitations for supported regions (USA, Canada, and Vietnam).
Original PR description
Issue ----- Users cannot confirm shipments depending on the destination's province. Steps to reproduce ----- - Set up UPS - Create a contact in Philipines - Province: Cebu - Create a delivery - Validate the delivery > Error message Cause ----- Codes can only be 5 characters long, as per the API https://developer.ups.com/tag/Shipping?loc=en_US#operation/Shipment According to the doc, the field is only useful for USA, Canada and Vietnam. ----- Ticket: opw-6149404 Forward-Port-Of: odoo/enterprise#117203
This update clarifies the meaning of a document access right within the Documents app. Previously, 'No' indicated no access, which was misleading. It's now 'Basic,' accurately reflecting that users retain access to their own and shared documents.
Original PR description
In the Documents app, the lowest tier access right was called "No", which implies the user has no access. However, this is not the case. The user still has access to the app, their own documents, and shared documents. To resolve this confusion, "No" is changed to "Basic" and the relevant descriptions are updated. task-6099135 Forward-Port-Of: odoo/enterprise#113660
This update ensures that changes to pricelist item dates made after a Point of Sale session is opened are correctly reflected within that session. Previously, reloading the POS wouldn't update the items. This improves the accuracy of pricing displayed to customers during transactions.
Original PR description
Before this commit, if the date validity of a pricelist item was changed after opening a POS session, reloading the POS won't update the items. opw-6223217 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265211
26 changes
Enhancements to existing features
This update clarifies how half-day work periods are displayed on payslips. Previously, half days were grouped with full days, making it difficult to understand total work hours. Now, half days are clearly identified, providing a more accurate and transparent view of employee compensation.
Original PR description
In order to clearly distinguish work days that extended full day or half day, the worked days under the payslips will not display both entries as separate types with the half days flagged Task: 5975762 Forward-Port-Of: odoo/enterprise#112328
Resolved issues and error corrections
This update resolves an issue where manually created bills were incorrectly assigned to the default purchase journal. Now, bills created through the 'Create a bill manually' option will automatically use the correct journal based on the user's previous selection, ensuring accurate financial record-keeping.
Original PR description
This commit fixes the default journal used when pressing "Create a bill manually" on a purchase journal in the journals dashboard. Previously, when creating a bill manually, it would be created on the default purchase journal. Now, the correct purchase journal is chosen depending on which journal I pressed the "creating a bill manually" link from. task-6167135 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261586
This update resolves an issue where certain product categories were incorrectly displayed on Website 1, leading to a 'Not Found' error. The fix ensures that categories are only shown to users on the current website, improving the user experience and preventing broken links. This change was made to maintain consistent and accurate product listings.
Original PR description
Steps to produce: --- - Install `website_sale` with demo data. - Go to `website > ecommerce > products > ecommerce categories`. - Open `Desks/Components` category > Set website to `My website 2`. -…
Steps to produce: --- - Install `website_sale` with demo data. - Go to `website > ecommerce > products > ecommerce categories`. - Open `Desks/Components` category > Set website to `My website 2`. - Open the shop page on website > Click on Desks category. Issue: --- - The Components subcategory is still displayed on Website 1. - Clicking on it leads to a Not Found page since the category is not assigned to that website. Root cause: --- - At [1], In the category filmstrip template, subcategories are fetched without filtering based on website access. - As a result, categories restricted to another website are still shown. Solution: --- - Filter categories using the `can_access_from_current_website` method to ensure only categories accessible from the current website are displayed. [1]https://github.com/odoo/odoo/blob/900fc043064216c5943ea07392d8120be7b50b63/addons/website_sale/views/templates.xml#L758-L769 opw-6159549 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266637 Forward-Port-Of: odoo/odoo#262410
This update resolves an issue where paying with the 'customer account' payment method on a zero-priced POS order incorrectly created a customer balance due. The fix hides the 'pay_later' payment option in this scenario, aligning with business requirements and preventing incorrect financial reporting. This ensures accurate order settlement.
Original PR description
Step to reproduce: - install "pos_settle_due" - create a pos order, set order price = 0, select a customer - go to payment page, select "customer account" as payment method - here you can set any…
Step to reproduce: - install "pos_settle_due" - create a pos order, set order price = 0, select a customer - go to payment page, select "customer account" as payment method - here you can set any amount to pay, ex 100$ - fulfill the order. Observation: - the order amount is 0, if we pay 100$ using customer account, it is considered as change (which means we returned it to customer) - As per PO, this flow doesn't make sense Issue: - customer has 100$ due for this order, but he won't be able to settle this as fetch order to settle with amount != 0, after commit [1] - [1] https://github.com/odoo/enterprise/commit/12af23d5382e972facfaa999e4c5ab30c97e8d1f https://github.com/odoo/enterprise/blob/951e5f42884c898bc14d9c32ae6a8f08c31ff06d/pos_settle_due/static/src/app/screens/partner_list/partner_line/partner_line.js#L35 Fix: - we hide payment method of type "pay_later" in case of 0 price order opw-6123699 Forward-Port-Of: odoo/enterprise#118296 Forward-Port-Of: odoo/enterprise#116556
This update resolves a test failure related to how binary data is handled during the import of Italian electronic invoices. The fix ensures that test data is correctly formatted for Python 3.14's stricter base64 validation requirements, preventing an error. This ensures the Italian EDI functionality continues to operate reliably.
Original PR description
This commit fixes an error when running the `test_edi_import` test on Python 3.14, which is stricter about base64 validation. Ultimately, the root issue was that raw test content was being passed to the `datas` field of an attachment when a base64 representation was actually expected (which is obviously invalid base64). Passing it via the `raw` field instead correctly handles the raw binary data. runbot-939133 Forward-Port-Of: odoo/odoo#266731
This update fixes an issue where orders captured in a POS session would incorrectly reappear in a new session after a device was disconnected. This change ensures order dates align accurately, reducing user confusion and improving session management. It addresses a technical glitch that could have caused inaccurate reporting.
Original PR description
Before this commit, if an order was captured in a session but could not be synced to the server, and the session was closed from another device, the order would be captured in the opening control session that created after the closing. This could lead to confusion for the user as the session opening date would be after the order capture date. opw-6207434 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263776
This update fixes a bug where POS refund orders were incorrectly showing as paid, leading to an inaccurate calculation of outstanding balances on linked sale orders. The change ensures that refund amounts are properly accounted for when determining the unpaid balance, improving the accuracy of financial reporting. This resolves issue OPW-6190337.
Original PR description
POS refund order lines have a positive `price_subtotal_incl` but represent money returned to the customer. `_compute_amount_unpaid` was treating them as paid amounts, causing the unpaid balance on the linked sale order to be understated. opw-6190337 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263241
This update resolves an issue where the employee org chart would crash when displaying records with a missing 'write_date' field. This often occurred with legacy data imported into Odoo. The fix ensures the chart gracefully handles these records by defaulting to a '0' value, preventing the error and maintaining chart functionality.
Original PR description
### Description of the issue / feature this PR addresses The Odoo 19.0 \`hr_org_chart\` controller passes \`employee.write_date\` to JS as a cache-busting key: \`\`\`python #…
### Description of the issue / feature this PR addresses The Odoo 19.0 \`hr_org_chart\` controller passes \`employee.write_date\` to JS as a cache-busting key: \`\`\`python # addons/hr_org_chart/controllers/hr_org_chart.py:35 write_date=int(employee.write_date.timestamp()) * 1000, # to have it in milliseconds for js \`\`\` When \`hr_employee.write_date\` is NULL the ORM returns \`False\` for the field, so the unconditional \`.timestamp()\` call raises: \`\`\` AttributeError: 'bool' object has no attribute 'timestamp' \`\`\` This crashes the employee form view on click for any record with NULL \`write_date\`. NULL audit columns can occur in legacy databases — records inserted via direct SQL by data-loaders, rows carried forward from very old Odoo versions that did not always populate \`_log_access\` columns, or data restored from anonymised backups. The ORM's \`vals.setdefault\` defaults in \`_log_access\` do not override an explicit falsy value passed by callers. This is a regression vs 18.0 — the 18.0 \`_prepare_employee_data\` did not include \`write_date\` at all. ### Behaviour before this PR Opening the form view of an employee with NULL \`write_date\` (any affected employee record) raises \`AttributeError\` and the org chart fails to load. ### Behaviour after this PR The controller falls back to \`0\` when \`write_date\` is missing — the same defensive pattern already used in \`odoo/addons/base/models/avatar_mixin.py:67\`: \`\`\`python bgcolor = get_hsl_from_seed(self[self._avatar_name_field] + str(self.create_date.timestamp() if self.create_date else "")) \`\`\` The org chart loads; the JS cache key for that one record is \`0\` until the record is next written (which will set \`write_date\` via the normal ORM path). No user-visible regression on healthy rows. Forward-Port-Of: odoo/odoo#264591
This update makes carousels on the website more user-friendly by pausing automatic scrolling when a user prefers reduced motion. It also increases the delay between carousel image changes to 5 seconds, preventing a jarringly fast experience. This enhances accessibility and overall website performance.
Original PR description
Auto-sliding carousels should be paused if the user chose prefers reduced motion. This commit also increases the fallback interval when none is set from 1s to 5s. Cycling through images every second is much too fast. task-5470023 Forward-Port-Of: odoo/odoo#266997 Forward-Port-Of: odoo/odoo#250169
This update resolves a warning message that appeared during AI development in Odoo 19.1. The change ensures the warning remains visible, as it was previously disabled in a prior version. This allows for continued monitoring and identification of potential issues related to AI integration.
Original PR description
This reverts commit e1c71a90b3e7163733cba3da401eaf473f190fef. The warning is fine. https://github.com/odoo/odoo/pull/259007#issuecomment-4299650605 > il fallait justement stop le forward-port en 18.2, on veut le warning, mais on n'avait pas la possibilité d'en avoir un avant 18.1 Forward-Port-Of: odoo/odoo#266967 Forward-Port-Of: odoo/odoo#262841
This update resolves a technical issue where Odoo couldn't properly serialize certain data types (Date, Datetime, and Binary) within sparse fields when exporting data to JSON. The fix ensures that these values are correctly formatted for JSON, preventing errors and improving data compatibility. This change ensures data is consistently exported and imported.
Original PR description
Storing a sparse field of type Date, Datetime or Binary raises a TypeError because json.dumps() cannot natively serialize the Python objects returned by convert_to_read (date/datetime instances and bytes). Fix Serialized.convert_to_cache to pass json_default (from odoo.tools.json) as the default serializer to json.dumps(). This handles Date, Datetime and Binary values without any extra conversion step in _inverse_sparse, and reuses the existing Odoo infrastructure instead of introducing a custom helper. Steps to reproduce: 1. Create a model with a sparse field of type Date, Datetime or Binary 2. Set a value on it 3. → TypeError: Object of type date is not JSON serializable --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266779
This update corrects a minor inaccuracy in how the 'remaining days' field displays dates close to the current date. Previously, deadlines near today's date were sometimes incorrectly shown as 'Next month'. This change ensures a more precise and user-friendly display of time remaining.
Original PR description
Luxon is not very accurate when the field is close to today: If today is Apr 30, so a deadline set to May 1 will be displayed as "Next month". In practice, it is not wrong, but it is not very accurate. task-6175442 Forward-Port-Of: odoo/odoo#267102
This update resolves an issue preventing users from editing the short description of new partners within the website. A recent change removed essential styling, causing the editing field to be unusable. The fix restores the necessary styling and adds a placeholder for improved user experience.
Original PR description
Steps to reproduce: 1. Create a new partner with any level. 2. Click on the Go to Website button and publish it. 3. Now go to the /partners page and activate editor. 4. Now try to edit the short description of the partner. Current behavior: The short description is not editable in the frontend. This is due to the changes made in the editor, before the changes, the o_editable class was getting added additional properties to give it a minimum height and width, along with making it an inline-block element. But now, these properties has been removed, which is causing an issue for users adding new partners and trying to edit the short description in the website. Solution: We brought back the crm_partner_assign.scss and added the properties back to the o-editable element inside our specific partner short description. Also added a placeholder to the short description to make the interaction more intuitive for users. opw-5955922 Forward-Port-Of: odoo/odoo#253097
This update resolves an issue where the Documents app's PDF preview displayed incorrectly, showing a duplicate iframe. The fix ensures that the preview accurately renders PDF attachments received via email, addressing a problem caused by how the system identifies file types. This improvement ensures consistent and reliable PDF viewing within the Documents application.
Original PR description
**Steps to reproduce:** - Install documents_account - Set up alias to catch incoming mails - Receive a mail with xml attachement which can be previewed as pdf - Go to Documents app - Click on the…
**Steps to reproduce:** - Install documents_account - Set up alias to catch incoming mails - Receive a mail with xml attachement which can be previewed as pdf - Go to Documents app - Click on the document preview - Preview is split in two iframes, both with the same content (pdf) **Issue:** Due to the `isPdf` patch the attachment can match multiple types for the preview (pdf and text) as both getter return `true`. ``` <iframe t-if="state.file.isPdf" ... <iframe t-if="state.file.isText" ... ``` It also seems that xml received by mail are imported as text, which is why the issue doesn't happen when manually uploading the same xml file. **Fix:** Ensure that if the document is matching `isPdf`, it doesn't trigger the second iframe with `isText`. Also it seems fixed in 19.0 as the text iframe is replaced by this xpath: `<xpath expr="//iframe[@t-if='state.file.isText']" position="replace">` which was added for https://github.com/odoo/enterprise/commit/de614ee5e9a087d49939c65c0118ae6164c7b31b related patch: https://github.com/odoo/enterprise/commit/ffcdd2275c8bf564e15151ccbcaf3965ed968450 opw-6018536 Forward-Port-Of: odoo/enterprise#118041 Forward-Port-Of: odoo/enterprise#112041
This update resolves an issue where product variants weren't being created in the Point of Sale (POS) system when a product template used a dynamic attribute with a single value. Previously, this prevented users from adding correctly configured items to their orders, leading to errors. This change ensures that all product variants are created, improving the reliability of the POS system.
Original PR description
When a product template has a dynamic attribute with only one value, `isConfigurable()` returns `false` (correctly suppressing the configurator popup), but `create_product_variant_from_pos` was never called, leaving the order line without a proper variant and causing error when trying to add it to the order. opw-6213957 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264134
This update resolves a bug where date calculations within the AI module would fail when the 'offset' value was unexpectedly `None`. The fix ensures that missing or `None` 'offset' values are treated as 0, preventing unintended date movements and improving the stability of AI-powered features. This change enhances the reliability of date-based computations.
Original PR description
Currently, an exception is raised when `offset` is `None` and is compared
with `MIN_OFFSET` or `MAX_OFFSET`.
Currently `offset = op.get("offset", 1)` to assign a default value of `1` when
the `offset` key was missing from `op`. However, this does not handle cases
where the `offset` key is present but its value is `None`.
This commit fixes the issue by defaulting `offset` to `0` when it is missing or
`None` in `op`. Using the default value ensures no date movement occurs
when `offset` is not explicitly provided.
Sentry-7448086997This update fixes an issue where the website builder incorrectly added paragraph tags when inserting icon snippets. The change ensures icons are only wrapped in `<p>` elements when dropped between blocks, preventing unwanted line breaks and formatting problems. This improves the overall consistency and usability of the website builder.
Original PR description
When the "icon" snippet is dropped, after the icon is selected and inserted, a call to `wrapInlinesInBlocks` ensures the icon is wrapped in a `<p>` element. The added `p` is only desired when the icon snippet is dropped between blocks, and it is problematic when the icon snippet is dropped "inline". This commit only wraps the icon if needed (aka, the parent `allowsParagraphRelatedElements`) Steps to reproduce: - Open website builder - Select a span of text and turn it bold - Type `/button` inside the bold text and add a button - Drag and drop the "Icon" snippet (an inner content snippet) - Select any icon - Bug: a `<p>` element is added in the `strong` element (which is invalid html), and this adds line breaks (and the style is affected if the line breaks are manually deleted) task-6251585
This update corrects a technical oversight by adding a new module, 'l10n_hu_reports_a60', to the Odoo translation system (Weblate). The original module was developed but hadn't been properly linked to the translation workflow, preventing accurate Hungarian language support. This fix ensures the module is correctly translated and available for users.
Original PR description
We added a new module here 379c5e9611f1f1c242027c1c134219966474de16 but forgot to add it to weblate.json for translation. no-task
This update optimizes the HTML editor's performance, specifically when handling large tables like the Accounting Balances Sheets. By changing a selector, the system now recalculates styles more quickly, reducing delays during actions like hovering, scrolling, and sorting.
Original PR description
Avoid using the :has() selector and use a specific class on the body instead to replicate the same behavior. This reduces work during the "Recalculate Style" phase (for example when hovering rows in large tables such as the Accounting > Balances Sheets). It lowers recalculation time during window resizes, heavy scrolling, and table sorting by preventing broad selector matches and limiting style checks to elements with the specific class. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267165
This update automatically sets the deductibility prorata rate to 100% by default in the Iranian (l10n_ma) accounting module. Previously, users had to manually configure this rate, which often led to inaccurate tax reports. This change simplifies the process and ensures more reliable tax calculations.
Original PR description
Users often forget to complete the deductibility prorata rate, which makes the tax report seems buggy. Set the rate to 100% by default. task-6092580 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263486
This update resolves a rare test failure related to timing issues in the website's interaction tests. The fix eliminates a potential delay caused by waiting for animation frames, ensuring more reliable test results. This improves the overall stability of the website development process.
Original PR description
This commit fixes the test "waitForTimeout does not trigger update if interaction is not ready yet", which could very rarely fail on runbot. **Origin of the problem** The test relies on precise…
This commit fixes the test "waitForTimeout does not trigger update if interaction is not ready yet", which could very rarely fail on runbot. **Origin of the problem** The test relies on precise timings, but the helper `advanceTime` could introduce a non-deterministic lag because, when called with default options, it awaits for an animation frame. If the lag happens to be too long, the second `verifySteps` is called too late and the test fails. **Fix** The helper `advanceTime` is now called with the option `animationFrame` set to false to avoid awaiting for an animation frame. For additional safety, the waiting time is also reduced. Two changes not directly related to this problem have been applied to improve the test: 1. an unnecessary `await` in `willStart` has been removed; 2. the `animationFrame` has been set to false also on the second `advanceTime` (a non-deterministic lag here can't fail the test, but still there is no reason to await for the animation frame). runbot-243515 Forward-Port-Of: odoo/odoo#266432
This update fixes a visual issue where the background color of selected table cells wasn't accurately displayed in the toolbar. The changes ensure that the selected cell's background color is consistently shown, regardless of whether the cell is empty or contains data. This enhances the user experience when working with tables in the HTML editor.
Original PR description
Before this commit: the background color of selected table cells isn't shown in the toolbar. After this commit: we have a background color processor in the table plugin to calculate the background color of selected cells. The color and background color are also properly reset to update the selected color when selecting an empty table cell. table_selectionchange_handlers is created to make sure the selected color is updated after it. task-5976046 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266911 Forward-Port-Of: odoo/odoo#252011
This update resolves an issue where branch users without access to a parent company couldn't create transactions in the parent company's currency. The fix ensures accurate currency conversion by temporarily elevating access privileges, allowing branch users to properly handle foreign currency transactions within their respective company journals.
Original PR description
**Problem:** When a branch user with no access to the parent company tries to create a transaction for a parent company's journal with a foreign currency set, this will raise an access error. **Steps…
**Problem:** When a branch user with no access to the parent company tries to create a transaction for a parent company's journal with a foreign currency set, this will raise an access error. **Steps to Reproduce:** - Make a branch of "My Company (San Francisco)" - Set user "Marc Demo" to only have access to the branch - Add a new bank journal set to "EUR" currency - Switch to Marc Demo - Try to add a transaction in the new bank journal **Root Cause:** When a transaction is created, Odoo determines the amount in company currency by converting it from the foreign currency. The method to convert currency uses "with_company()" to use the company's rates, but the allowed companies of the branch user does not have access to the parent company, causing an access error. **Solution:** Call the currency conversion with sudo() to ensure access to the relevant companies. Ticket [link](https://www.odoo.com/odoo/project.task/6186901) opw-6186901 Forward-Port-Of: odoo/odoo#263968 Forward-Port-Of: odoo/odoo#263425
This update corrects an error in the Peru - Accounting Reports module that was causing SUNAT's electronic reporting system (SIRE) to reject DAM (Declaración Aduanera de Mercancías) reports. The fix ensures the correct 3-digit customs dependency code is used in field 8, aligning with SUNAT regulations. This prevents report rejections and ensures accurate data submission.
Original PR description
**Steps to reproduce:** * Install Peru - Accounting Reports (l10n_pe_reports). * Create a vendor bill with Document Type 50 (Declaración Aduanera de Mercancías - DAM) and a document number in the…
**Steps to reproduce:** * Install Peru - Accounting Reports (l10n_pe_reports). * Create a vendor bill with Document Type 50 (Declaración Aduanera de Mercancías - DAM) and a document number in the standard pediment format (e.g. C235202610-38047). * Go to Accounting > Reporting > Purchase Electronic Record (RCE 8.4). * Export the TXT file and open it. **Observed behavior:** * Field 8 contains the full first numeric block of the document name including the year and sequence digits (e.g. 235202610) instead of only the 3-digit customs dependency code. * SUNAT/SIRE rejects the file immediately because 235202610 does not exist in Table 4 (RS 040-2022), which only defines 3-digit codes. **Cause:** * `_get_serie_folio()` splits the document name by taking everything before the last digit group as the serie. For a name like C235202610-38047 this produces serie = "C235202610", and the existing `serie[1:]` logic strips only the leading letter, leaving "235202610" in field 8 instead of the 3-digit customs dependency code "235". * The same incorrect value was also written to field 28 (aduana_code). * ref : https://www.sunat.gob.pe/legislacion/superin/2022/anexo-040-2022.pdf **Fix:** * For document types 50 and 52, extract the first numeric group from the document name using `re.search(r'\d+', move_name)` and slice the first 3 characters to obtain the customs dependency code as defined in SUNAT Table 4 (always a 3-digit value). * Apply the same logic to field 28 (aduana_code) for consistency. opw-6157662 Forward-Port-Of: odoo/enterprise#115406
Previously, a single error in downloading vendor bills from KSeF via the cron job would halt the entire process. This update fixes this by allowing the cron job to continue processing valid invoices even if some XML files are malformed, logging the errors for investigation. This ensures a more reliable and efficient import of vendor bills.
Original PR description
### Description of the issue/feature this PR addresses: **Issue:** When downloading vendor bills from KSeF via the cron, the system attempts to parse the XML files sequentially. If a single XML file…
### Description of the issue/feature this PR addresses: **Issue:** When downloading vendor bills from KSeF via the cron, the system attempts to parse the XML files sequentially. If a single XML file is missing something that is expected, the parser raises a UserError. This unhandled exception halts the entire cron job and rolls back the database transaction, clogging up the rest of the queue. **Solution:** This PR wraps the l10n_pl_edi_get_ksef_bill_vals_from_xml parsing step inside a try/except block within the batch download loop. If a UserError is encountered for a specific invoice, the error is logged as a warning, and the cron proceeds. ### Current behavior before PR: A single malformed XML file causes the cron to fail completely. Valid invoices in the same batch are not created due to the halted queue. ### Desired behavior after PR is merged: The cron successfully processes the batch of downloaded XMLs even if one or more files are invalid. Errors on specific invoices are logged for the user to investigate, while the rest of the valid vendor bills in the batch are succesfully created. opw-6179479 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266180
This update resolves a problem where users couldn't confirm shipments to certain locations, specifically in the Philippines (Cebu). The issue stemmed from the UPS API requiring province codes to be only 5 characters long, which wasn't being enforced. This fix ensures that only valid, short province codes are used, allowing shipments to be confirmed correctly.
Original PR description
Issue ----- Users cannot confirm shipments depending on the destination's province. Steps to reproduce ----- - Set up UPS - Create a contact in Philipines - Province: Cebu - Create a delivery - Validate the delivery > Error message Cause ----- Codes can only be 5 characters long, as per the API https://developer.ups.com/tag/Shipping?loc=en_US#operation/Shipment According to the doc, the field is only useful for USA, Canada and Vietnam. ----- Ticket: opw-6149404 Forward-Port-Of: odoo/enterprise#117203
2 changes
Resolved issues and error corrections
This update fixes an issue where quality alerts weren't being created when incoming emails were processed without a company assigned. The fix ensures that a company ID is always provided, preventing errors and guaranteeing that all emails are correctly logged as quality alerts. This improves the reliability of our quality tracking system.
Original PR description
Steps to reproduce 1. Install quality 2. Create an incoming email server 3. Go to Quality > Configuration > Quality Teams > Team > add alias email 4. Do not fill the company field 5. Send email to this alias 6. Fetch emails from incoming email server Issue: - Record is not created in the quality alert Root cause: - For the Quality alert model, the field `company_id` is required, but while we fetch emails We haven't set the `company_id` on the quality alert team, resulting in trying to insert a null value on the quality alert model. Solution: - Give a default value to company_id. - Raise a validation error on not having a company_id - Update alias default values on changing company_id opw-5917791 Forward-Port-Of: odoo/enterprise#117846 Forward-Port-Of: odoo/enterprise#109947
This update fixes an issue where payments to the Mexican tax authority (CFDI) were being sent multiple times for the same invoice. The fix ensures the 'Update Payments' button only appears after the full invoice payment is reconciled, preventing inaccurate reporting and potential overpayment issues. This improves financial accuracy and compliance.
Original PR description
Issue: Sending payments to SAT before its full amount is reconciled allow sending the same invoice payment several times to CFDI. Steps to reproduce: - In a Mexican company - Create an invoice A of…
Issue: Sending payments to SAT before its full amount is reconciled allow sending the same invoice payment several times to CFDI. Steps to reproduce: - In a Mexican company - Create an invoice A of $40 to Inmobiliaria CVA - Confirm and send to CFDI - Go to bank, create a new Bank transaction of $80 - reconcile with Invoice A - Go to invoice A => click on button "Update payments" (it doesn't appear in previous versions) - Then sheet CFDI and Download There is the first XML sent to CFDI with payment for invoice A - Create an invoice B of $40 to Inmobilira CVA - Confirm and send to CFDI - reconcile the transaction with Invoice B - Go to invoice B - Click on button "Update payments" - Then sheet CFDI and Download There is the second XML sent to CFDI with payment for invoices A and B Invoice A payment was sent twice to CFDI Expected behavior: - The "Update payment" button should appear only once the invoice payment is fully reconciled. Current behavior: - The update payment button appear once the invoice is reconciled with a payment. The method `_l10n_mx_edi_cfdi_invoice_get_payments_diff` is called twice, once to check whether it's needed to display the "Update button" and once when you try to update the payment (called only after clicking on said button). opw-5432421 Forward-Port-Of: odoo/enterprise#108355
7 changes
Enhancements to existing features
This update adjusts how global discounts are exported in invoices to align with UBL (Universal Business Language) standards. Previously, discounts were represented as negative invoice lines, which is now changed to 'Allowances'. This ensures compliance with international trade regulations and simplifies the export process for global transactions.
Original PR description
Export global discounts as Allowances instead of negative invoice lines to comply with UBL specifications. task-5900496 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261029
Resolved issues and error corrections
This update resolves an issue where activity labels in the Chatter interface were not displaying correctly when the default summary was removed. The fix ensures that activity labels now consistently use the `display_name` when the summary is empty, providing accurate and consistent information for users.
Original PR description
Before this commit: --- - Chatter activity display used [`summary`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L42) to get…
Before this commit: --- - Chatter activity display used [`summary`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L42) to get the display name. - If `summary` was empty, it fell back to [`display_name`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L44). - However, `_to_store` only [stored](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/models/mail_activity.py#L680) `summary`. - As a result, nothing was shown when `summary` was empty, even though `display_name` was set. Steps to reproduce: --- - Create an activity in chatter - Remove the default summary if set. - Observer the title. https://github.com/user-attachments/assets/1684feb7-02d0-4ac1-9c00-d2aaae88e045 After this commit: --- - Added `display_name` to `_to_store` along with `summary`. - Chatter activity now correctly falls back to `display_name`. - Users can now see the correct activity label in chatter. OPW: 6212976 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where dropshipping orders incorrectly displayed a negative delivered quantity. The change introduced a new feature for returns, which caused a default setting to add incoming stock moves to the calculation, leading to a -1 quantity. This fix restores the correct delivery quantity by reverting a previous change.
Original PR description
Currently, an error occurs when the user receives a dropship order instead of delivering it directly to the customer. As a result, the sale order shows a negative delivered quantity. ## Steps to…
Currently, an error occurs when the user receives a dropship order instead of delivering it directly to the customer. As a result, the sale order shows a negative delivered quantity. ## Steps to replicate: - Install Sales, Inventory, and Purchase. - Enable Dropshipping from Inventory settings. - Create a test product with the Dropship route enabled and set a vendor for it in the Purchase tab. - Create and confirm a quotation for a customer. - Go to Purchase > `Deliver To:` and set it to `My Company: Receipts.` - Confirm the Purchase Order and validate the receipt. - Go back to the Sale Order. ## Observed Behavior: The delivered quantity is -1, which is incorrect because the customer has not returned any products, nor has the user created a sale order line with a negative quantity (which would indicate a return). ## Root cause: When computing the delivered quantity at [1], the function `_get_outgoing_incoming_moves` [2] is called to retrieve the incoming and outgoing stock moves associated with the sale order lines. Inside this function, moves are filtered and categorized as incoming or outgoing. At [3], the condition is satisfied because the default value of `to_refund` is `True`, so the move is added to `incoming_move_ids`. Later, during the computation at [1], the code iterates through the incoming moves and subtracts their quantities from the delivered quantity. Since the initial delivered quantity is 0, including such a move in `incoming_move_ids` causes the delivered quantity to become -1. <h3> Why did this behavior not occur in lower versions?:</h3> This issue was introduced by [commit], which added the functionality for users to return products that are not listed in the purchase order. As a result, their quantities appear as negative received quantities on the purchase order. Before this change (in saas-18.2), the field `move.to_refund` had a default value of `False`. Because of this, the condition at [3] was not satisfied, and the move was not included in `incoming_move_ids`. Therefore, it was not subtracted when iterating through incoming moves, and the delivered quantity did not become negative. Starting from 18.3, the default value of `to_refund` was changed to `True`. This causes the condition at [3] to be satisfied, the move to be included in `incoming_move_ids`, and its quantity to be subtracted during the computation, resulting in a delivered quantity of -1. [1]- https://github.com/odoo/odoo/blob/1256875226436a854558a1334ffdc886fa4767a8/addons/sale_stock/models/sale_order_line.py#L193-L209 [2]- https://github.com/odoo/odoo/blob/1256875226436a854558a1334ffdc886fa4767a8/addons/sale_stock/models/sale_order_line.py#L316-L353 [3]- https://github.com/odoo/odoo/blob/1256875226436a854558a1334ffdc886fa4767a8/addons/sale_stock/models/sale_order_line.py#L346-L351 ## Solution: We can make the condition stricter by ensuring that only incoming moves that are actual returns are counted as negative in the quantity delivered on a sale order. Specifically, if an incoming move has no corresponding originating return move and the customer has not created a sale order line with a negative quantity (which could also indicate a return), it should not be considered when calculating the delivered quantity. [commit]: https://github.com/odoo/odoo/pull/209110/changes/c1c86182e4b28e929bf56e79f57f33aaa13e67f1 opw-5933594
This update resolves a test failure related to how binary data is handled during the import of Italian electronic invoices. The fix ensures test data is correctly formatted for validation, preventing a 'binascii.Error' that occurred with Python 3.14. This improves the reliability of the Italian EDI module.
Original PR description
This commit fixes an error when running the `test_edi_import` test on Python 3.14, which is stricter about base64 validation. Ultimately, the root issue was that raw test content was being passed to the `datas` field of an attachment when a base64 representation was actually expected (which is obviously invalid base64). Passing it via the `raw` field instead correctly handles the raw binary data. runbot-939133 Forward-Port-Of: odoo/odoo#266731
This update significantly speeds up partner searches within the Point of Sale (POS) system. Previously, searching through a large number of partners was slow due to rendering all results. Now, the system limits the displayed results to 200 and adjusts the search input's delay to reduce unnecessary calls, resulting in a faster and more responsive user experience.
Original PR description
Before this commit, when high number of partners were loaded in the POS, searching for a partner was slow. The main issue was that all of the filtered partners based on the search query were being rendered, while in reality, if a query returns lots of results, the search query is not refined enough and the user is likely to type more characters to narrow down the search. So in this commit, we limit the number of rendered partners to 200, which is a reasonable number of results to display and does not cause performance issues. Moreover, the debounce time of the search input has been increased from 100ms to 500ms to further reduce the number of times the search function is called while the user is typing. opw-6215958 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265598 Forward-Port-Of: odoo/odoo#264300
This update corrects a visual issue in the POS system where a split button was always displayed, even when bill splitting was disabled. The fix ensures the button is hidden when the restaurant module is active, aligning the user interface with the current bill splitting settings. This improves the user experience and prevents confusion.
Original PR description
The Split button in the POS control panel was rendered whenever the restaurant module was active, without checking the `iface_splitbill` config flag. opw-6248177 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267037 Forward-Port-Of: odoo/odoo#266654
This update fixes an issue where credit limit warnings incorrectly flagged customers as exceeding their limits when outstanding bank payments were present. Now, the system accurately considers bank payments in its calculations, ensuring warnings only appear when the total outstanding amount exceeds the credit limit. This improves accuracy and prevents unnecessary alerts for customers.
Original PR description
Before this PR: - The credit limit warning calculation only considered credit notes but ignored outstanding bank payments. For example, if a customer had a credit limit of 100,000 and created an invoice for 200,000, then paid 150,000 via bank payment, the warning would still appear incorrectly showing the customer exceeded their limit (200,000 > 100,000), even though the actual outstanding amount was only 50,000. After this PR: - The credit limit warning now properly includes outstanding bank payments in the calculation. Using the same example, after a 150,000 bank payment, the system correctly recognizes the outstanding amount as 50,000 and does not show a warning since it's within the 100,000 credit limit. task-5427613
1 change
Resolved issues and error corrections
This update corrects an issue where the Peru - Accounting Reports module was incorrectly formatting data for SUNAT DAM filings. Specifically, field 8 contained too much information, leading to immediate rejection by the SUNAT system. The fix ensures that only the required 3-digit customs dependency code is used, aligning with SUNAT regulations.
Original PR description
**Steps to reproduce:** * Install Peru - Accounting Reports (l10n_pe_reports). * Create a vendor bill with Document Type 50 (Declaración Aduanera de Mercancías - DAM) and a document number in the…
**Steps to reproduce:** * Install Peru - Accounting Reports (l10n_pe_reports). * Create a vendor bill with Document Type 50 (Declaración Aduanera de Mercancías - DAM) and a document number in the standard pediment format (e.g. C235202610-38047). * Go to Accounting > Reporting > Purchase Electronic Record (RCE 8.4). * Export the TXT file and open it. **Observed behavior:** * Field 8 contains the full first numeric block of the document name including the year and sequence digits (e.g. 235202610) instead of only the 3-digit customs dependency code. * SUNAT/SIRE rejects the file immediately because 235202610 does not exist in Table 4 (RS 040-2022), which only defines 3-digit codes. **Cause:** * `_get_serie_folio()` splits the document name by taking everything before the last digit group as the serie. For a name like C235202610-38047 this produces serie = "C235202610", and the existing `serie[1:]` logic strips only the leading letter, leaving "235202610" in field 8 instead of the 3-digit customs dependency code "235". * The same incorrect value was also written to field 28 (aduana_code). * ref : https://www.sunat.gob.pe/legislacion/superin/2022/anexo-040-2022.pdf **Fix:** * For document types 50 and 52, extract the first numeric group from the document name using `re.search(r'\d+', move_name)` and slice the first 3 characters to obtain the customs dependency code as defined in SUNAT Table 4 (always a 3-digit value). * Apply the same logic to field 28 (aduana_code) for consistency. opw-6157662 Forward-Port-Of: odoo/enterprise#115406
9 changes
Enhancements to existing features
This update adjusts the sale module to allow orders to be shipped even if the stock isn't immediately available. The method name was changed from 'deliver' to 'ship' to better reflect this new functionality. This change streamlines the order fulfillment process.
Original PR description
**Purpose:** Reflect the changes made in sale module **Specification:** Renamed method _compute_show_deliver_button to _compute_show_ship_button Task-5343527 See also: - https://github.com/odoo/odoo/pull/240746 - https://github.com/odoo/upgrade/pull/10170
Resolved issues and error corrections
This update resolves a technical issue where the system incorrectly accessed bike color information when creating new bikes. The fix ensures that color data is only retrieved when a new bike is being added, improving data accuracy and preventing potential errors.
Original PR description
- Cause: for a new bike we try to access color attribute on fleet.vehicle.model (using fleet.vehicle for old bike) - Solution: access color attribute only if not a new bike Task: 6245895
This update ensures Odoo's Czech VAT reports accurately comply with the Czech tax authority's hybrid rounding rules. Previously, the system didn't correctly handle the required rounding of tax bases and VAT amounts. This change directly updates report expressions to ensure accurate VAT return calculations and avoid potential discrepancies.
Original PR description
The Czech tax authority enforces specific hybrid rounding rules for the VAT Return: - Tax bases and subtotals must use standard mathematical rounding. - VAT Due / Tax Amounts must be rounded UP to the nearest whole CZK. - Calculated totals must be the exact sum of the previously rounded lines. Currently, the report generation does not support this mixed rounding behavior out of the box. This commit resolves the issue by updating the report expressions directly in the XML to comply with the legal requirements thus removing the need to have the float_round method in the tax_report_handler. task: 6081523
This update resolves an issue preventing users from unreconciling SEPA CT batch payments with a 'pending' online status. Previously, the system incorrectly blocked this process, causing delays in bank statement reconciliation. The fix allows internal unreconciliation flows to bypass validation, ensuring accurate bank statement updates.
Original PR description
**Issue:** The account_online_payment module overrides `action_draft` to raise a UserError for sepa_ct payments belonging to a batch with a `payment_online_status` = 'pending' or 'accepted'. This…
**Issue:** The account_online_payment module overrides `action_draft` to raise a UserError for sepa_ct payments belonging to a batch with a `payment_online_status` = 'pending' or 'accepted'. This blocks the bank statement unreconciliation process. When `delete_reconciled_line` is called, it tries to set payments to draft and re-post them, despite it being an internal process not a manual user modification. **Steps to reproduce:** - Setup a 'sepa_ct' payment method on a bank journal. - Create a bill with a vendor with a trusted bank account. - Create a payment for that bill with a 'sepa_ct' payment method. - Add the payment to a batch. - Manually set the `payment_online_status` = 'pending'. - Create a bank transaction and reconcile it with the batch. - Try to unreconcile the lines on the transaction - Result: UserError 'You cannot modify a payment that has already been sent to the bank.' **Fix:** Pass a context flag to `action_draft` during the unreconciliation flow so that the validation is skipped when the call originates from the internal unreconcile flow. OPW-6080464 Forward-Port-Of: odoo/enterprise#118649 Forward-Port-Of: odoo/enterprise#117921
This update fixes a previous accounting error in Odoo's Hong Kong payroll system. The Employer Paid Rent rule was incorrectly only recording a debit, resulting in an imbalance. The change now uses the correct credit account (221004) for rent payments, ensuring accurate financial reporting for employees receiving housing allowances.
Original PR description
The Employer Paid Rent rule (HEPR) only had a debit account (5220 Employee Benefits/Staff Costs), leaving the journal entry unbalanced. Set account 221004 (Staff Housing Accrued) as the credit account for the HEPR rule in both CAP57 Monthly Employee Pay and CAP57 Casual Employee Pay structures. Community PR: https://github.com/odoo/odoo/pull/266863 task-6219303 Forward-Port-Of: odoo/enterprise#118629
This update resolves an issue where Odoo was incorrectly generating CFDI invoices in Mexico, leading to export rejections. The fix ensures that cash rounding lines, which are not valid CFDI concepts, are excluded from the invoice XML, aligning with SAT regulations. This prevents errors and ensures compliant invoice generation.
Original PR description
When using the 'add_invoice_line' cash rounding strategy, Odoo adds a journal line with display_type='rounding'. This line has no product and therefore no ClaveProdServ, causing PAC to reject the XML with error 301. Per SAT regulations, cash rounding is not a valid CFDI concept. The CFDI must report the pre-rounding amounts (e.g. 99.80); the rounding difference (e.g. 0.20) belongs only in the journal entry on the accounting side. opw-6024078 Forward-Port-Of: odoo/enterprise#117400 Forward-Port-Of: odoo/enterprise#112633
This update prevents users from creating new work entry types directly within the payrun calendar view. Previously, this could lead to misconfigured payroll settings, causing errors in payrun calculations. This change ensures accurate payroll processing by restricting the ability to manually define these types.
Original PR description
_ ## Short functional explanation As creating new time off type can not be done blindly or it will not be correctly configured (no payroll categories ...), this option is removed from the holidays gantt view __ task-6193813
This update resolves an issue where appointment scheduling displayed 'no slots available' when appointments started in a future month. The fix ensures that the calendar correctly reflects all available months, regardless of when the appointment's booking range begins. This improves the user experience for scheduling appointments with future start dates.
Original PR description
The "show only 1 month at a time" optimization computes the navigated month as datetime.now() + month_id, so the controller passes that (month, year) tuple to _get_appointment_slots:…
The "show only 1 month at a time" optimization computes the navigated month as datetime.now() + month_id, so the controller passes that (month, year) tuple to _get_appointment_slots: https://github.com/odoo/enterprise/blob/57ec37b74a60c7e879a8afa66df5ab22a92c5bcd/appointment/models/appointment_type.py#L833 For a punctual appointment whose Allow Bookings range starts in a future month, the first displayed month is start_datetime.month, so the (month, year) tuple doesn't match the month the visitor is looking at. The model fills an empty month and the recovery loop refills the first displayed month (where slots actually live): https://github.com/odoo/enterprise/blob/57ec37b74a60c7e879a8afa66df5ab22a92c5bcd/appointment/models/appointment_type.py#L973-L988 The calendar the visitor just navigated to comes back empty. Compute the navigation base from start_datetime when it lies in the future and keep datetime.now() otherwise. month_id is added on top of that base so it always matches the displayed month index. Introduced by https://github.com/odoo/enterprise/commit/664857dd2c4ae2bc0dde8f44cb94136659ed2fe2 Steps to reproduce: 1. Open the Appointments app 2. Open an appointment type and set Schedule to Weekly and Allow Bookings to On specific dates with a range starting in a future month (for example 1 September to 31 December) 3. Save and click the Preview button in the header 4. Pick a staff member to reach the calendar 5. Click the right arrow to navigate to the next month => the next month shows "Sorry, we have no more slots available for this month" opw-6206293 Forward-Port-Of: odoo/enterprise#117283
This update resolves an issue where the IP salary rule wasn't correctly displayed on Belgian employee payslips. The underlying calculation has been adjusted to ensure accurate reporting of IP contributions, improving payroll accuracy and compliance for our Belgian clients.
Original PR description
-**Issue**: The IP salary rule was not visible on payslip. -**Fix**: Computation has been adjusted to include the correct field. Forward-Port-Of: odoo/enterprise#112711 Forward-Port-Of: odoo/enterprise#110936
2 changes
Resolved issues and error corrections
This update streamlines the calculation of offer fields related to contracts, preventing unnecessary recomputations and ensuring data consistency. A previous issue with the `is_hr_payroll` context flag has been resolved, restoring correct form behavior when creating offers from the payroll module in version 19.3.
Original PR description
**Problem:** Since this https://github.com/odoo/enterprise/pull/103846, `employee_version_id` depends on `contract_start_date` to adjust the employee state based on the contract date. This introduced…
**Problem:** Since this https://github.com/odoo/enterprise/pull/103846, `employee_version_id` depends on `contract_start_date` to adjust the employee state based on the contract date. This introduced an unnecessary dependency chain: ``` contract_start_date -> employee_version_id -> contract_template_id -> wages and other offer fields ``` As a result, updating `contract_start_date` invalidates and recomputes the whole chain, even when `employee_version_id` does not actually change. In addition, offer fields were coupled in a single compute, causing unrelated fields to be reset to template values when only one field required recomputation. **Fix:** - `contract_template_id` compute now depends on `employee_id` instead of `employee_version_id`, and directly uses the employee's `version_id`, breaking the chain while preserving default behavior. - The offer fields computations were also split to avoid unintended recomputations and field resets. - Simplified `_get_version` by always copying values from the template to the currently active version. --- **Additional fix:** The `is_hr_payroll` context flag is used to distinguish payroll vs recruitment flows when creating an offer with both `employee_id` and `applicant_id` unset. A recent change in [Task #6094737](https://www.odoo.com/odoo/project/1251/tasks/6094737) did not account for this flag, causing both fields to be hidden when opening the form from Payroll (a new feature added in saas-19.3). This is fixed by properly considering `is_hr_payroll`, restoring consistent behavior across all versions. Task: 6158245
This update fixes an issue where payments for Mexican invoices were being sent to CFDI multiple times, leading to inaccurate reporting. The change ensures the 'Update Payments' button only appears after the full invoice payment is reconciled, preventing duplicate XML filings and maintaining accurate financial records.
Original PR description
Issue: Sending payments to SAT before its full amount is reconciled allow sending the same invoice payment several times to CFDI. Steps to reproduce: - In a Mexican company - Create an invoice A of…
Issue: Sending payments to SAT before its full amount is reconciled allow sending the same invoice payment several times to CFDI. Steps to reproduce: - In a Mexican company - Create an invoice A of $40 to Inmobiliaria CVA - Confirm and send to CFDI - Go to bank, create a new Bank transaction of $80 - reconcile with Invoice A - Go to invoice A => click on button "Update payments" (it doesn't appear in previous versions) - Then sheet CFDI and Download There is the first XML sent to CFDI with payment for invoice A - Create an invoice B of $40 to Inmobilira CVA - Confirm and send to CFDI - reconcile the transaction with Invoice B - Go to invoice B - Click on button "Update payments" - Then sheet CFDI and Download There is the second XML sent to CFDI with payment for invoices A and B Invoice A payment was sent twice to CFDI Expected behavior: - The "Update payment" button should appear only once the invoice payment is fully reconciled. Current behavior: - The update payment button appear once the invoice is reconciled with a payment. The method `_l10n_mx_edi_cfdi_invoice_get_payments_diff` is called twice, once to check whether it's needed to display the "Update button" and once when you try to update the payment (called only after clicking on said button). opw-5432421 Forward-Port-Of: odoo/enterprise#108355
5 changes
Resolved issues and error corrections
This update fixes an issue where UBL files weren't correctly applying tax rates during import. The previous system used a simplified cache key, leading to inaccurate tax assignments for similar lines. This change ensures that the tax rates specified in the UBL file are precisely applied, improving data accuracy.
Original PR description
When we import a UBL file, we call the `_import_retrieve_tax` method to fetch taxes to indicate on lines.
During the process, we use cache to avoid performing the search a second time if a new line is the same as a previous one.
https://github.com/odoo/odoo/blob/d0424f2ffcf99ee59befe288150f1643b3fa0112/addons/account/models/account_tax.py#L4459-L4462
The cache_key used is defined as follows: {line's invoice, line's name, line's partner}.
This implies that if two lines from the same invoice share the same name and partner, the same tax will automatically be used even if different taxes were indicated in the file.
This is not desirable as we should match what is indicated in the XML file imported.
opw-6226166
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves a test failure related to how binary data is handled during the import of Italian electronic invoices. The fix ensures the test data is correctly formatted for Python 3.14's stricter base64 validation, preventing an error. This improves the reliability of the Italian EDI module.
Original PR description
This commit fixes an error when running the `test_edi_import` test on Python 3.14, which is stricter about base64 validation. Ultimately, the root issue was that raw test content was being passed to the `datas` field of an attachment when a base64 representation was actually expected (which is obviously invalid base64). Passing it via the `raw` field instead correctly handles the raw binary data. runbot-939133 Forward-Port-Of: odoo/odoo#266731
This update resolves an issue where Odoo's session testing process incorrectly flagged errors in Python 3.14. The change adjusts the tests to recognize a specific `PicklingError` that Python 3.14 now raises when attempting to serialize certain code snippets. This ensures the session tests accurately reflect the behavior of Odoo with the latest Python version.
Original PR description
Python 3.14 now raises `pickle.PicklingError` instead of `AttributeError` when attempting to pickle local functions or lambdas. This updates the session serialization assertions to expect the correct exception depending on the current Python version. runbot-938172 Forward-Port-Of: odoo/odoo#266862
This update resolves an issue where currency differences were incorrectly aggregated in hierarchical financial reports. The change ensures that reports accurately display totals in the original currency, improving the reliability and accuracy of financial data presented to users. This update addresses a potential misrepresentation of financial figures.
Original PR description
opw-6015098 Forward-Port-Of: odoo/enterprise#114827
This update corrects a technical issue preventing vendor bills with DAM (Declaración Aduanera de Mercancías) documents from being accepted by the SUNAT/SIRE system. The fix ensures that only the required 3-digit customs dependency code is used in the relevant field, aligning with SUNAT regulations. This resolves a rejection error and ensures proper reporting.
Original PR description
**Steps to reproduce:** * Install Peru - Accounting Reports (l10n_pe_reports). * Create a vendor bill with Document Type 50 (Declaración Aduanera de Mercancías - DAM) and a document number in the…
**Steps to reproduce:** * Install Peru - Accounting Reports (l10n_pe_reports). * Create a vendor bill with Document Type 50 (Declaración Aduanera de Mercancías - DAM) and a document number in the standard pediment format (e.g. C235202610-38047). * Go to Accounting > Reporting > Purchase Electronic Record (RCE 8.4). * Export the TXT file and open it. **Observed behavior:** * Field 8 contains the full first numeric block of the document name including the year and sequence digits (e.g. 235202610) instead of only the 3-digit customs dependency code. * SUNAT/SIRE rejects the file immediately because 235202610 does not exist in Table 4 (RS 040-2022), which only defines 3-digit codes. **Cause:** * `_get_serie_folio()` splits the document name by taking everything before the last digit group as the serie. For a name like C235202610-38047 this produces serie = "C235202610", and the existing `serie[1:]` logic strips only the leading letter, leaving "235202610" in field 8 instead of the 3-digit customs dependency code "235". * The same incorrect value was also written to field 28 (aduana_code). * ref : https://www.sunat.gob.pe/legislacion/superin/2022/anexo-040-2022.pdf **Fix:** * For document types 50 and 52, extract the first numeric group from the document name using `re.search(r'\d+', move_name)` and slice the first 3 characters to obtain the customs dependency code as defined in SUNAT Table 4 (always a 3-digit value). * Apply the same logic to field 28 (aduana_code) for consistency. opw-6157662 Forward-Port-Of: odoo/enterprise#115406