Daily updates from Odoo
Monday, June 1, 2026
177 changes
25 changes
Resolved issues and error corrections
This update corrects a bug where paying off an account balance through a POS order resulted in an incorrect 'Settle Due' amount being displayed. The fix prevents negative values from affecting calculations, ensuring accurate remaining balances are shown to customers. This improves the user experience and financial reporting.
Original PR description
When a customer paid off their account balance through a POS order, a negative pay_later amount was used. The condition `if order_due:` in `_compute_customer_due_total` evaluated to True for negative values, causing `customer_due_total` and `init_customer_due_total` to be set to a negative amount. This made `pos_orders_amount_due` on the partner go negative, which in turn inflated `remainingDue` in the frontend (remainingDue = totalDue - posOrdersAmountDue), showing a wrong amount in the "Settle due amount" button. opw-6187771 Forward-Port-Of: odoo/enterprise#116394
This update resolves an issue where product prices didn't automatically update when the cost price of a product variant changed. Previously, users had to manually switch price lists to trigger the update. The fix ensures that changes to the cost price are immediately reflected in the on-sale price, streamlining the pricing process.
Original PR description
When we create a product variant and have a pricelist which is based on the cost price, and change the cost price, the on_sale_price doesn't update. You have the change the price list to other and…
When we create a product variant and have a pricelist which is based on the cost price, and change the cost price, the on_sale_price doesn't update. You have the change the price list to other and back to the one you want for it to trigger change because the _onchange_compute_pricing only gets triggered if there's change on pricelist (pricer_sale_pricelist_id), and sales price (lst_price). Steps to Reproduce: 1.Create a pricelist and add a line with "formula" price type, and based on "cost", 2.Create a product variant, and add the pricelist just created. 3.Change the "Cost". The "On Sale Price" doesn't update. 4.You have to change the price list to some other and back to the one you want for the "On Sale Price" to update. To fix the issue, we add the field Cost (standard_price) on api.onchange, so when we change the cost it'll update the "On Sale Price" right away. opw-5947995 Forward-Port-Of: odoo/enterprise#118584 Forward-Port-Of: odoo/enterprise#111892
This update resolves an issue where deleting an action linked to an inactive filter would sometimes cause errors. The change ensures that inactive filters are also removed when an action is deleted, maintaining data consistency and preventing unexpected behavior. This improves the overall stability and reliability of the system.
Original PR description
How to reproduce: - Delete an action linked to an inactive user-defined filter. - Go to the User-Defined menu, - Show inactive filters (with "Archived filter") - Got a MissingError. Explanation: odoo/odoo#156622 fixes an inconsistency when deleting an action, but the reviewer was "amorti" so he (I) forgot to account for inactive "ir.filters". Add active_test=False to ensure inactive "ir.filters" are also removed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266761 Forward-Port-Of: odoo/odoo#262195
This update resolves a technical issue impacting US reporting. Previously, a duplicated configuration caused incorrect formatting for US chart of accounts reports. The fix combines the necessary settings into a single, streamlined file, ensuring accurate reporting for US users.
Original PR description
In 19.1, when `account_reports_negative_format` was introduced, the PR created a new `template_us` file for `l10n_us_reports` to set the new field, not realizing that `account_chart_template` already existed. Since both files were to the same template and had the exact same method name, one shadowed the other which means all this time the `negative_format` was not properly set for US CoA. Since most other countries keep their CoA in a `template_TEMPLATE_NAME.py` file, move the deferred accounts to `template_us` and remove the `account_chart_template` file. task-none Forward-Port-Of: odoo/enterprise#118712
This update resolves an issue where a test in the account payment module was unreliable due to dependencies on a module not always present. The change simplifies the test by directly using the intended calculation method, ensuring consistent and predictable results. This improves the overall stability and reliability of our payment processing tests.
Original PR description
The set_line_bank_statement_line method is defined in account_accountant, meaning we can't use it in account_payment as it will automatically break if enterprise is not installed. Replace it with direct call to _get_partial_amounts, which is the purpose of this test anyway. runbot-939260 Forward-Port-Of: odoo/odoo#267139
This pull request addresses a few minor issues identified during a recent update (FW-porting) of the l10n_fr_pdp module. These fixes improve the functionality and stability of the module, ensuring continued accurate processing of French accounting data. The changes are focused on internal improvements within the module.
Original PR description
Backports some fixes discovered during FW-porting task-None Forward-Port-Of: odoo/odoo#267375 Forward-Port-Of: odoo/odoo#267330
This update resolves an issue that caused errors when sending shifts involving multiple team members. The fix ensures the system correctly handles shifts with multiple resources, preventing a traceback and improving the reliability of shift scheduling. This enhancement ensures smoother operations for teams managing resources.
Original PR description
Steps to reproduce: - Install Planning - Create two resources - Enable "Employee Unavailabilities > Unassign themselves from shifts - Create a shift with multiple resources - Send the shift Issue: A traceback occurred when sending a shift linked to multiple resources. Cause: The unavailability URL was generated using `employees.token`, which expects a single employee record. Fix: Handle shifts with multiple resources correctly when generating the unavailability URL to avoid the traceback when sending shifts. issue commit-https://github.com/odoo/enterprise/pull/106700/commits Forward-Port-Of: odoo/enterprise#118292
This update fixes an issue where commission plans were incorrectly displayed in the 'Other Plans' section for salespeople, even when their assignment periods didn't overlap. The system now accurately checks for overlapping salesperson assignment dates, ensuring that only relevant plans are shown. This improves the accuracy of commission reporting.
Original PR description
Version - 18.0 Steps to reproduce: 1. Create a commission plan A with effective period 2025–2026 2. Assign salesperson to plan A from 01/01/2025 to 31/12/2025 3. Create another commission plan B with effective period 2026 4. Assign the same salesperson to plan B from 01/01/2026 to 31/12/2026 5. Open plan B and check the 'Other Plans' section in the salespeople tab Issue: Plans are shown in 'Other Plans' even when salesperson assignment periods do not overlap. System incorrectly relies on plan effective dates instead of salesperson-specific assignment dates Fix: A plan is now considered overlapping only if the salesperson assignment periods intersect. Non-overlapping plans are properly excluded from 'Other Plans'. Taskid-6055253 Forward-Port-Of: odoo/enterprise#118769 Forward-Port-Of: odoo/enterprise#112694
A previous error prevented users from canceling draft POS orders. This fix corrects a recent code change that caused a conflict when attempting to cancel an order. The update ensures the cancellation process now functions correctly.
Original PR description
Currently an error is generated when the user tries to cancel a draft POS order as follows: - Install the `pos_enterprise` module with demo data - Open the register of `Furniture store` and select…
Currently an error is generated when the user tries to cancel a draft POS order as follows: - Install the `pos_enterprise` module with demo data - Open the register of `Furniture store` and select any product - Click on the `Upload` icon to save the draft order and go to the backend. - Navigate Orders > Orders > open Draft order - Click the `cog` icon and click `Cancel Order` >>> Error occurs This issue is caused by the recent refactor introduced in [1]. The `action_pos_order_cancel` action now returns the `order` (`pos.order` recordset) instead of default returning `None`. As a result, the `action` variable contains a `pos.order` recordset, and an error is raised at line [2] when `setdefault` is called on it, since `setdefault` expects a dictionary-like object. This commit fixes the above issue by removing the code that returns the `pos.order` object from the action. As a result, the action now behaves as expected and returns the default value (`None`). [1]: https://github.com/odoo/enterprise/commit/27f57036a1d0468efe6e68d7aceafe0f01b21f93 [2]: https://github.com/odoo/odoo/blob/48f93ca056633bd5cba36b66ee1008fb57ca666c/addons/web/controllers/utils.py#L24 Sentry-7354160052 Forward-Port-Of: odoo/enterprise#118035
This update ensures that work entry data exported to Acerta adheres to their specific formatting requirements. The export now correctly pads the external reference number to 17 digits with spaces and formats the work entry type code to 4 digits with spaces, resolving potential data discrepancies with the Acerta system. This ensures accurate data transmission and processing.
Original PR description
We want to adhere to the correct format for the export of work entries to Acerta. There, the number of external reference is padded to 17, not 20, and is followed by 3 spaces, before the date. Also, the code of the work entry type is padded to 4 and followed by 2 spaces. Task: 6168106 Forward-Port-Of: odoo/enterprise#118568 Forward-Port-Of: odoo/enterprise#118124
This update corrects a technical issue that could cause errors in the DMFA report PDF generation. The change adds a validation check to ensure only numerical characters are used, preventing data entry problems and ensuring accurate report output. This improves the reliability of payroll reporting.
Original PR description
Added a validation error in the _get_code function in case the code contains non-numerical characters. This prevents non-numerical characters input from breaking the DMFA report PDF generation. Task: 6231125 Forward-Port-Of: odoo/enterprise#118367 Forward-Port-Of: odoo/enterprise#117889
This update resolves an issue where users without specific accounting permissions were encountering errors when loading templates within the Knowledge Articles module. The fix delays access to sensitive audit reporting data, ensuring the template loading process works correctly for all user roles. This prevents disruptions to users creating and managing knowledge articles.
Original PR description
Steps to reproduce: 1. Install `accountant_knowledge` with `demo data` 2. Remove demo user from bookkeeper access right and give some lesser right 3. Open knowledge and create a new artical with demo user 4. Click on Load template for example `Meeting Minutes` Issue: It gives a access error: `This operation is allowed for the following groups: - Accounting/Bookkeeper` Cause: - accountant_knowledge was doing accounting-only work during generic template loading. Immediately calling `target_article._get_inherited_audit_report()` that returns `inherited_audit_report_id`, which is a computed relation to audit report. `audit.report` is only readable by `account.group_account_user` Solution: - delay that access until it is actually needed, - only if the template contains data-embedded="accountReport" opw-6067390 Forward-Port-Of: odoo/enterprise#117292 Forward-Port-Of: odoo/enterprise#112946
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 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 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
21 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
Resolved issues and error corrections
This update resolves a technical issue preventing correct reporting of US Chart of Accounts settings. The previous implementation caused a conflict between files, leading to incorrect formatting. This change consolidates the US CoA definitions for improved reporting accuracy.
Original PR description
In 19.1, when `account_reports_negative_format` was introduced, the PR created a new `template_us` file for `l10n_us_reports` to set the new field, not realizing that `account_chart_template` already existed. Since both files were to the same template and had the exact same method name, one shadowed the other which means all this time the `negative_format` was not properly set for US CoA. Since most other countries keep their CoA in a `template_TEMPLATE_NAME.py` file, move the deferred accounts to `template_us` and remove the `account_chart_template` file. task-none Forward-Port-Of: odoo/enterprise#118712
This update resolves an issue where deleting an action linked to an inactive filter would sometimes cause an error. The change ensures that inactive filters are also removed when an action is deleted, preventing data inconsistencies and improving the user experience. This improves data integrity and stability.
Original PR description
How to reproduce: - Delete an action linked to an inactive user-defined filter. - Go to the User-Defined menu, - Show inactive filters (with "Archived filter") - Got a MissingError. Explanation: odoo/odoo#156622 fixes an inconsistency when deleting an action, but the reviewer was "amorti" so he (I) forgot to account for inactive "ir.filters". Add active_test=False to ensure inactive "ir.filters" are also removed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266761 Forward-Port-Of: odoo/odoo#262195
This update resolves an issue where a test in the account payment module was unreliable due to dependencies on a module not always present. The test has been updated to use a more direct method, ensuring consistent and stable results. This improves the overall quality and reliability of our payment processing tests.
Original PR description
The set_line_bank_statement_line method is defined in account_accountant, meaning we can't use it in account_payment as it will automatically break if enterprise is not installed. Replace it with direct call to _get_partial_amounts, which is the purpose of this test anyway. runbot-939260 Forward-Port-Of: odoo/odoo#267139
This pull request addresses minor issues identified during the recent update of the French payroll module (l10n_fr_pdp). It backports necessary fixes to ensure proper functionality and data accuracy within this module. This update improves the reliability of financial reporting for French businesses using Odoo.
Original PR description
Backports some fixes discovered during FW-porting task-None Forward-Port-Of: odoo/odoo#267375 Forward-Port-Of: odoo/odoo#267330
This update fixes an issue where commission plans were incorrectly shown in a salesperson's list even when their assignment periods didn't overlap. The system now accurately checks for overlapping assignment dates, ensuring that only relevant plans are displayed, improving reporting accuracy and plan management.
Original PR description
Version - 18.0 Steps to reproduce: 1. Create a commission plan A with effective period 2025–2026 2. Assign salesperson to plan A from 01/01/2025 to 31/12/2025 3. Create another commission plan B with effective period 2026 4. Assign the same salesperson to plan B from 01/01/2026 to 31/12/2026 5. Open plan B and check the 'Other Plans' section in the salespeople tab Issue: Plans are shown in 'Other Plans' even when salesperson assignment periods do not overlap. System incorrectly relies on plan effective dates instead of salesperson-specific assignment dates Fix: A plan is now considered overlapping only if the salesperson assignment periods intersect. Non-overlapping plans are properly excluded from 'Other Plans'. Taskid-6055253 Forward-Port-Of: odoo/enterprise#118769 Forward-Port-Of: odoo/enterprise#112694
A recent update caused an error when users attempted to cancel draft POS orders. This fix removes a problematic code change that was causing the error, allowing users to successfully cancel draft orders. This ensures smooth order management within the POS system.
Original PR description
Currently an error is generated when the user tries to cancel a draft POS order as follows: - Install the `pos_enterprise` module with demo data - Open the register of `Furniture store` and select…
Currently an error is generated when the user tries to cancel a draft POS order as follows: - Install the `pos_enterprise` module with demo data - Open the register of `Furniture store` and select any product - Click on the `Upload` icon to save the draft order and go to the backend. - Navigate Orders > Orders > open Draft order - Click the `cog` icon and click `Cancel Order` >>> Error occurs This issue is caused by the recent refactor introduced in [1]. The `action_pos_order_cancel` action now returns the `order` (`pos.order` recordset) instead of default returning `None`. As a result, the `action` variable contains a `pos.order` recordset, and an error is raised at line [2] when `setdefault` is called on it, since `setdefault` expects a dictionary-like object. This commit fixes the above issue by removing the code that returns the `pos.order` object from the action. As a result, the action now behaves as expected and returns the default value (`None`). [1]: https://github.com/odoo/enterprise/commit/27f57036a1d0468efe6e68d7aceafe0f01b21f93 [2]: https://github.com/odoo/odoo/blob/48f93ca056633bd5cba36b66ee1008fb57ca666c/addons/web/controllers/utils.py#L24 Sentry-7354160052 Forward-Port-Of: odoo/enterprise#118035
This update resolves an issue where users without specific accounting permissions were encountering errors when loading templates within the knowledge article feature. The fix delays access to sensitive audit reporting data, ensuring the feature works correctly for a wider range of user roles. This improves usability and prevents disruptions for users accessing this functionality.
Original PR description
Steps to reproduce: 1. Install `accountant_knowledge` with `demo data` 2. Remove demo user from bookkeeper access right and give some lesser right 3. Open knowledge and create a new artical with demo user 4. Click on Load template for example `Meeting Minutes` Issue: It gives a access error: `This operation is allowed for the following groups: - Accounting/Bookkeeper` Cause: - accountant_knowledge was doing accounting-only work during generic template loading. Immediately calling `target_article._get_inherited_audit_report()` that returns `inherited_audit_report_id`, which is a computed relation to audit report. `audit.report` is only readable by `account.group_account_user` Solution: - delay that access until it is actually needed, - only if the template contains data-embedded="accountReport" opw-6067390 Forward-Port-Of: odoo/enterprise#117292 Forward-Port-Of: odoo/enterprise#112946
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 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 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 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 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
18 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 deleting an action linked to an inactive filter would sometimes cause an error. The change ensures that inactive filters are also removed when an action is deleted, maintaining data consistency and preventing unexpected errors for users. This improves the stability and reliability of the system.
Original PR description
How to reproduce: - Delete an action linked to an inactive user-defined filter. - Go to the User-Defined menu, - Show inactive filters (with "Archived filter") - Got a MissingError. Explanation: odoo/odoo#156622 fixes an inconsistency when deleting an action, but the reviewer was "amorti" so he (I) forgot to account for inactive "ir.filters". Add active_test=False to ensure inactive "ir.filters" are also removed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266761 Forward-Port-Of: odoo/odoo#262195
This update corrects an issue where placeholder text within blog posts was incorrectly displayed as HTML spans after translation. The fix ensures that placeholder text always shows as plain text, regardless of language settings, improving the user experience and consistency of blog content. This resolves a visual inconsistency that was impacting readability.
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#266166 Forward-Port-Of: odoo/odoo#263320
This update backports several bug fixes identified during a recent upgrade process (FW-porting) for the l10n_fr_pdp module. These fixes address minor issues related to French accounting functionality, ensuring continued accuracy and reliability for our French-speaking customers. The changes improve the overall stability of the module.
Original PR description
Backports some fixes discovered during FW-porting task-None Forward-Port-Of: odoo/odoo#267330
This update resolves an issue where a test was failing due to an outdated method call. The change simplifies the test by directly using the intended functionality, ensuring consistent and reliable test results. This improves the overall stability of the payment processing system.
Original PR description
The set_line_bank_statement_line method is defined in account_accountant, meaning we can't use it in account_payment as it will automatically break if enterprise is not installed. Replace it with direct call to _get_partial_amounts, which is the purpose of this test anyway. runbot-939260 Forward-Port-Of: odoo/odoo#267139
This update fixes a potential issue where customer display URLs were inconsistently formatted across Odoo. By standardizing this URL generation logic, it now allows other modules, like the mobile POS app, to reliably access the correct URL. This ensures consistent customer access and simplifies future development.
Original PR description
Previously, the logic to build the customer display URL was scoped entirely within the `openCustomerDisplay` method. This prevented other modules from easily reusing the exact same URL formatting logic, leading to duplicated or inconsistent URL construction. By extracting this logic into a dedicated `customerDisplayURL` getter, we allow extending modules (such as `pos_mobile`) to reliably access the correctly formatted URL. This ensures that essential parameters, like the device UUID and access token, are consistently applied whenever the customer display URL is needed across the codebase. opw-6212067 See also: https://github.com/odoo/enterprise/pull/118458 Forward-Port-Of: odoo/odoo#266854 Forward-Port-Of: odoo/odoo#266581
This update fixes an issue where the mobile point-of-sale app wasn't correctly linking to customer details. By standardizing the URL generation process with the main POS system, the mobile app now reliably displays customer information. This ensures a consistent and accurate customer experience for mobile users.
Original PR description
The `_showDisplayAndGoToUrl` method in the mobile navbar was manually constructing its own URL for the customer display. This hardcoded string incorrectly omitted the device UUID, which is required for proper display identification and tracking. By leveraging the new `customerDisplayURL` getter introduced in the parent `Navbar` component, the mobile implementation now utilizes the exact same URL logic as the standard point of sale. This resolves the inconsistency and ensures the customer display functions reliably on mobile devices. opw-6212067 Forward-Port-Of: odoo/enterprise#118624 Forward-Port-Of: odoo/enterprise#118458
This update fixes an issue where commission plans were incorrectly displayed in the 'Other Plans' section for salespeople, even when their assignment periods didn't overlap. The system now accurately checks for overlapping assignment dates, ensuring that only relevant plans are shown, improving the accuracy of commission calculations.
Original PR description
Version - 18.0 Steps to reproduce: 1. Create a commission plan A with effective period 2025–2026 2. Assign salesperson to plan A from 01/01/2025 to 31/12/2025 3. Create another commission plan B with effective period 2026 4. Assign the same salesperson to plan B from 01/01/2026 to 31/12/2026 5. Open plan B and check the 'Other Plans' section in the salespeople tab Issue: Plans are shown in 'Other Plans' even when salesperson assignment periods do not overlap. System incorrectly relies on plan effective dates instead of salesperson-specific assignment dates Fix: A plan is now considered overlapping only if the salesperson assignment periods intersect. Non-overlapping plans are properly excluded from 'Other Plans'. Taskid-6055253 Forward-Port-Of: odoo/enterprise#118769 Forward-Port-Of: odoo/enterprise#112694
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 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 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
1 change
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
6 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 backports several bug fixes identified during a recent upgrade process for the French payroll module (l10n_fr_pdp). These fixes address minor issues impacting the accurate processing of French tax regulations, ensuring continued compliance and reliable financial reporting.
Original PR description
Backports some fixes discovered during FW-porting task-None Forward-Port-Of: odoo/odoo#267330
This update fixes an issue where group allocations with past start dates incorrectly showed zero accrual amounts. The change ensures that accrual calculations are properly triggered when group allocations are created, regardless of the start date, ensuring accurate time-off tracking.
Original PR description
Problem ------------------ When creating group allocations, when the allocation type is accrual and the start date is set in the past, the newly created allocations have the accrual amounts at 0. To…
Problem ------------------ When creating group allocations, when the allocation type is accrual and the start date is set in the past, the newly created allocations have the accrual amounts at 0. To reproduce: 1. Create an accrual plan with an easily measurable milestone (e.g. 1 day every day) 2. From the allocations view -> New Group Allocation 3. Enter the following values: Grant -> By Employee Employees -> select your employee Time Off Type -> Paid Time Off (doesn't matter too much) Allocation Type -> Based on Accrual Plan Validity Period -> any date a few days in the past (Personally I tested with 1/1/2025 and no end date) Allocation -> Keep at 0 Allocate Time Off 4. Go to the newly created allocation The allocation amount is 0. Reason ---------------------- When creating group allocations, the `hr.leave.allocation.generate.multi.wizard` calls the `_process_accrual_plans()` method to compute the accruals, but when the allocations are created, the nextcall and lastcall fields are set, so the accruals are not computed and the scheduled action also does nothing until the nextcall date. The onchange method manually sets the nextcall date to False so the accruals are processed. Solution ------------------ Created a method to get the fields that need to be set to calculate the initial accrual amounts from the start date, which is called both in the onchange and to batch write in the wizard before accrual plans are processed. The wizard checks the duration values before overwriting the number_of_days field, since user manually setting the amount should overwrite the calculations. task-4938695 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266969 Forward-Port-Of: odoo/odoo#265783
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 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 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
23 changes
Enhancements to existing features
This update simplifies the bank reconciliation view by only displaying the undo button when a reconciliation line is expanded. Previously, the button was present on every reconciled line, which was considered visually cluttered. This change improves the user experience and makes the reconciliation process more intuitive.
Original PR description
Before this commit, the undo button was present on each line that was reconciled, which was a bit too much in the view. we decided to have it only when the line is expand no task id
This update enhances Obox pairing by allowing users to connect directly to the Obox via IP address and identifier, eliminating reliance on odoo.com servers. This provides greater flexibility and control for users, particularly in environments with limited internet connectivity. This change improves Obox usability and expands its deployment options.
Original PR description
We add a way to allow pairing without relying on odoo.com servers by directly providing the IP addess and identifier of the Obox. see odoo/obox#172
This update enhances logging around IoT device connections and message transmissions. Specifically, it adds more detailed logs for IP and version changes, and optimizes a search process to prevent unnecessary activity. These improvements will aid support teams in troubleshooting IoT issues.
Original PR description
This PR adds some minor logs around ip/version change and websocket messages sent to the iot box. It also inverts a condition to avoid doing a useless search when sending websocket messages See https://github.com/odoo/odoo/pull/266410 Forward-Port-Of: odoo/enterprise#118442 Forward-Port-Of: odoo/enterprise#118377
Resolved issues and error corrections
This update enhances the way Odoo handles errors when communicating with external payment systems (IAP). By improving exception handling, the system is now more resilient to potential issues, leading to more reliable transactions and reduced disruption for users. This change focuses on internal stability and doesn't directly impact the user experience.
Original PR description
See the commit in the community repository for more information about this change. task-none
This update corrects a minor issue in the product barcode lookup test data. Previously, the test included an unnecessary 'color' attribute due to a change in how product colors are defined. The fix replaces the 'Purple' color value with 'Invisible' to ensure the test consistently validates the color guard logic without relying on demo data.
Original PR description
The Issue: The barcode lookup flow in `_update_product_by_barcodelookup` searches for an attribute by name and links a matching value to the new product, but it never auto creates a missing color value because of the explicit `if not (attribute_value or attr_name == 'color'):`. Previous to 3181721 `product_barcodelookup` had a `color` attr which was removed in favor of the standard `Color` attr in `product` with demo values such as Purple, that's why now we get an extra attribute line. The Fix: Replace `"color": "Purple"` in the mock with `"color": "Invisible"`, a value not present in demo data. This ensures the test always exercises the color guard logic, but remains stable and independent of demo data. runbot-937747
This update re-enabled a previously skipped test related to the planning_field_service_sale_timesheet module. This change is necessary to ensure the continued stability and functionality of the system following the recent migration to the 'owl3' version. It's a routine maintenance step to maintain test coverage.
Original PR description
This commit unskips a test that has been skipped during the migration to owl3.
This update resolves a technical issue where the confirmation button in the AI tool was failing. The change updates the button's functionality to align with the new Owl 3 interface, ensuring the button now functions correctly and reliably. This improves the user experience for AI tool interactions.
Original PR description
Prior to this commit, the tool confirmation button would throw an error when clicked. This commit change the `on-click` call to match the new Owl 3 interface (using `this.onClick` instead of `onClick`)
This update fixes inconsistencies in how contract types are defined across Odoo modules. Specifically, the contract type ID was standardized and redundant entries were removed to ensure data accuracy and prevent future issues. This change is limited to version 17 and will be addressed in a separate update.
Original PR description
[IMP] hr_contract_salary: fix contract_type_id definition The definitions of the contract_type_id in hr_contract_salary_offer and l10n_be_hr_contract_salary/hr_contract_salary_offer should be same I converted the definition of contract_type_id in the base module to the Belgium one. Also, the contract_type_id was inserted to the view in Belgium one as well, I deleted that part to prevent double appearance. This task is only for v.17, after this version I will open a new PR to handle them. Do not forward the task after v.17 (only for v.17) task - 6101717 Forward-Port-Of: odoo/enterprise#118069 Forward-Port-Of: odoo/enterprise#113244
This update fixes a potential issue where users could select inactive Intrastat codes on products. Now, a warning message will appear if a user attempts to select an invalid or expired code, preventing incorrect data entry and ensuring accurate reporting for Intrastat purposes. This improves data integrity and compliance.
Original PR description
Problem: When choosing an intrastat code on a product, all the codes are shown, even the ones that are expired or not yet active. Users can select an intrastat code that is not active. Steps to reproduce: 1. Check the intrastat code list and find a code with a start date in the future or an expiry date in the past 2. Note the code description 3. Open a product form view and try to set/change the intrastat code 4. Search for the code description noted in step 2 5. Note that the code is proposed while it should not be proposed Solution: When an intrastat code is selected, if the code is not active, a warning message is shown to the user. opw-6217915 Forward-Port-Of: odoo/enterprise#118569 Forward-Port-Of: odoo/enterprise#117884
This update fixes an issue where selecting the start date first would incorrectly set both the start and end dates for deferred accounting periods. The change ensures the end date is correctly set first, resolving a display error where periods appeared reversed (e.g., 2026-2025).
Original PR description
The issue is when selecting deferred dates, if the start date is selected first, the system will set both the start and end dates. However, when selecting the end date first, the period appears backwards example ( 2026 - 2025 ). task: 6140024 Forward-Port-Of: odoo/enterprise#114866
This update addresses a problem where bank statement KPIs weren't being updated correctly when no statements were processed. Now, if no bank statements are reported, the KPIs will be reset to an empty state, ensuring accurate reporting and data integrity within the account module.
Original PR description
The aim of this commit is to update the integer kpis when those aren't received. ### Context: The account module report the bank statement in draft to process. When all bank statement have been processed, there isn't any and thus, the module send back an empty list. ### Before this commit: The bank statement kpi wasn't updated as we didn't received anything about that specific kpi. ### After this commit: Any kpi that wouldn't be reported would get it's column emptied. opw-6170973 Forward-Port-Of: odoo/enterprise#115695
This update resolves an error that prevented users from adding multiple loan lines to a record after the initial creation. The fix ensures that date comparisons within the system are handled correctly, allowing users to accurately manage loan line details. This improves the usability of the loan management feature.
Original PR description
**Steps to reproduce:** - Install the `l10n_fr_account_loans` module and switch to a `FR Company`. - Navigate to Accounting > Accounting > Assets & Liabilities > Loans. - Create a new loan record. -…
**Steps to reproduce:** - Install the `l10n_fr_account_loans` module and switch to a `FR Company`. - Navigate to Accounting > Accounting > Assets & Liabilities > Loans. - Create a new loan record. - Click `Add a line`, set a `Date`, and `save` the record. - Click `Add a line` again. **Error:** `TypeError: '>' not supported between instances of 'datetime.date' and 'bool'` **Root Cause:** At [1], when adding a line after the record has already been saved with at least one existing line, the existing line has a valid `datetime.date` value for `l.date`, while the newly created unsaved line still has `line.date` set to `False`. This results in a comparison between a `datetime.date` object and a boolean value, causing an error. **Fix:** This commit prevents the errors when adding multiple lines after saving the record by applying a fix similar to [2]. [1]: https://github.com/odoo/enterprise/blob/54eef93f295eaebd98d24730d108b1203ca7b35a/l10n_fr_account_loans/models/account_loan_line.py#L21 [2]: https://github.com/odoo/enterprise/blob/54eef93f295eaebd98d24730d108b1203ca7b35a/account_loans/models/account_loan_line.py#L61-L63 opw-6244973 Forward-Port-Of: odoo/enterprise#118354
This update streamlines the timesheet setup process for users. Previously, users had to manually start the activity watch server each login. This change removes that step, thanks to an updated installer, making timesheet setup much simpler and more convenient.
Original PR description
Before this commit, the wizard to onboard the user to correctly install activity watch for timesheet assistant, mentioned the user has to start the server each time he logs in on his computer. This step is not longer needed thanks to an update on the odoo activity watch installer. This commit removes the line saying the user has to start the server each time he starts his working day. task-6081636 Forward-Port-Of: odoo/enterprise#118664 Forward-Port-Of: odoo/enterprise#115373
This update corrects a technical error in the US reporting module that prevented the correct formatting of negative account balances. The issue stemmed from a duplicate file structure, and this fix consolidates the necessary configurations within a single, dedicated file for US reporting. This ensures accurate reporting for US-based financial data.
Original PR description
In 19.1, when `account_reports_negative_format` was introduced, the PR created a new `template_us` file for `l10n_us_reports` to set the new field, not realizing that `account_chart_template` already existed. Since both files were to the same template and had the exact same method name, one shadowed the other which means all this time the `negative_format` was not properly set for US CoA. Since most other countries keep their CoA in a `template_TEMPLATE_NAME.py` file, move the deferred accounts to `template_us` and remove the `account_chart_template` file. task-none Forward-Port-Of: odoo/enterprise#118712
This update ensures that work entry data exported to Acerta adheres to their specific formatting requirements. The export now correctly pads the external reference number to 17 digits with 3 spaces and the work entry type code to 4 digits with 2 spaces, resolving potential data discrepancies with the Acerta system. This ensures accurate data transmission and processing.
Original PR description
We want to adhere to the correct format for the export of work entries to Acerta. There, the number of external reference is padded to 17, not 20, and is followed by 3 spaces, before the date. Also, the code of the work entry type is padded to 4 and followed by 2 spaces. Task: 6168106 Forward-Port-Of: odoo/enterprise#118568 Forward-Port-Of: odoo/enterprise#118124
This update fixes an issue where commission plans were incorrectly listed in the 'Other Plans' section for salespeople, even when their assignment periods didn't overlap. The system now accurately checks for overlapping salesperson assignments, ensuring that only relevant plans are displayed, improving the accuracy of commission calculations.
Original PR description
Version - 18.0 Steps to reproduce: 1. Create a commission plan A with effective period 2025–2026 2. Assign salesperson to plan A from 01/01/2025 to 31/12/2025 3. Create another commission plan B with effective period 2026 4. Assign the same salesperson to plan B from 01/01/2026 to 31/12/2026 5. Open plan B and check the 'Other Plans' section in the salespeople tab Issue: Plans are shown in 'Other Plans' even when salesperson assignment periods do not overlap. System incorrectly relies on plan effective dates instead of salesperson-specific assignment dates Fix: A plan is now considered overlapping only if the salesperson assignment periods intersect. Non-overlapping plans are properly excluded from 'Other Plans'. Taskid-6055253 Forward-Port-Of: odoo/enterprise#118769 Forward-Port-Of: odoo/enterprise#112694
This update resolves an issue that caused errors when sending shifts involving multiple resources. The fix ensures the system correctly handles shifts with multiple assigned employees, preventing a traceback and improving the reliability of shift scheduling. This change enhances the overall stability of the Planning module.
Original PR description
Steps to reproduce: - Install Planning - Create two resources - Enable "Employee Unavailabilities > Unassign themselves from shifts - Create a shift with multiple resources - Send the shift Issue: A traceback occurred when sending a shift linked to multiple resources. Cause: The unavailability URL was generated using `employees.token`, which expects a single employee record. Fix: Handle shifts with multiple resources correctly when generating the unavailability URL to avoid the traceback when sending shifts. issue commit-https://github.com/odoo/enterprise/pull/106700/commits Forward-Port-Of: odoo/enterprise#118292
This update fixes an issue where unreconciling a payment on a recurring invoice would automatically generate a new draft invoice for the following month. The change adds a context flag to prevent this behavior, ensuring invoices are created correctly after reconciliation. This improves invoice management and reduces potential errors.
Original PR description
Issue: Unreconciling a payment in a batch payment from a recurring invoice will cause an invoice for the next recurring period to be generated Steps to reproduce: 1. Create and confirm a monthly…
Issue: Unreconciling a payment in a batch payment from a recurring invoice will cause an invoice for the next recurring period to be generated Steps to reproduce: 1. Create and confirm a monthly recurring invoice 2. Create a payment for the invoice 3. Create a batch payment and add the payment created in step 2 then validate it 4. Create a bank statement line and reconcile it with the batch payment created in step 3 5. Unreconcile the payment from the invoice from the invoice form view 6. Notice that a draft invoice for the next month’s recurring invoice is created Cause: When unreconciling the payment from the invoice via the invoice form view, the method “delete_reconciled_line” is called. In the “account_accountant_batch_payment” override of that method, it will reset the invoice back to draft and repost it. However, when posting a recurring invoice, the default behavior is to create the invoice for the next recurrence period Solution: Adding a new context flag called “skip_recurring_copy” will prevent the next period’s recurring invoice from being generated when invoices are posted through “delete_reconciled_line” opw-6158881 Forward-Port-Of: odoo/enterprise#117011
This update corrects a technical issue that could cause the DMFA report PDF generation to fail when non-numerical characters were entered for work addresses. The change adds a validation check to ensure only numbers are used, improving the reliability of the report and preventing potential disruptions.
Original PR description
Added a validation error in the _get_code function in case the code contains non-numerical characters. This prevents non-numerical characters input from breaking the DMFA report PDF generation. Task: 6231125 Forward-Port-Of: odoo/enterprise#118367 Forward-Port-Of: odoo/enterprise#117889
This update resolves an error that occurred when the Salary Increase wizard was used with a past date for the salary increase. The fix prevents a crash by handling cases where no matching employee versions are found for the specified date, ensuring the wizard functions correctly.
Original PR description
Currently, an error will occur when user puts Date of Salary Increase in the past on the salary increase wizard. Steps to replicate: - Install `hr_payroll` and create a new employee. - From the cog…
Currently, an error will occur when user puts Date of Salary Increase in the past on the salary increase wizard.
Steps to replicate:
- Install `hr_payroll` and create a new employee.
- From the cog menu click `Salary Increase`.
- Put any date from the past in the `Date of Salary Increase` field.
Error:
```py
File '/home/odoo/src/enterprise/saas-19.3/hr_payroll/wizard/hr_payroll_salary_increase_wizard.py', line 43, in _get_affected_version_ids
increase_base_version = employee.version_ids.filtered_domain([('date_version', '<=', self.increase_date)])[-1]
File '/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py', line 6135, in __getitem__
ids = (self._ids[key],)
IndexError: tuple index out of range
```
Cause:
- When the user changes the salary increase date, it triggers the [compute], which calls `_get_affected_version_ids()`. In this method, employee versions [1] are filtered to keep only those whose `date_version` is less than or equal to the selected increase date.
- For newly created employees, version_ids typically contain only an initial version with date_version set to today's date. Therefore, when the selected salary increase date is earlier than today, the filter returns an empty recordset, which later causes the crash when accessing the last record of that recordset.
Solution:
- Early returned empty recordsets when no matching employee versions are found for the selected increase date.
[compute]: https://github.com/odoo/enterprise/blob/2a86967c1754f9c703a87c5d9ceb1d5f5d0ec26f/hr_payroll/wizard/hr_payroll_salary_increase_wizard.py#L34-L39
[1]: https://github.com/odoo/enterprise/blob/2a86967c1754f9c703a87c5d9ceb1d5f5d0ec26f/hr_payroll/wizard/hr_payroll_salary_increase_wizard.py#L43
sentry-7498213478
Forward-Port-Of: odoo/enterprise#118309This 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 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
Code cleanup and technical improvements
This update streamlines how users are added to Odoo discussion channels. Previously, a shorthand method was used, which has now been replaced with a direct store handler for better efficiency and control. This change ensures consistent and reliable channel member management.
Original PR description
Remove the public discuss.channel#add_members() shorthand and expose the functionality directly as a /discuss/channel/add_members store handler. All callers (channel_invitation, join channel action, tests) are updated to go through fetchStoreData. task-4712367
2 changes
Enhancements to existing features
This update ensures that product tags sent to UrbanPiper are dynamically managed based on a product's settings and tax configurations. Previously, tags were hardcoded, but now the system automatically handles relevant tags, improving accuracy and flexibility for integrations with UrbanPiper.
Original PR description
Before this commit: ------------------------------------------ - The UrbanPiper payload used a hardcoded tag when the tax percentage was not 5%. - There was no mechanism to add additional tags based on providers, even though UrbanPiper supports multiple tags. After this commit: ------------------------------------------ - Tags are now dynamically handled using the Tag field in the product. - Users can define tags according to their tax configurations and aggregator requirements. - UrbanPiper only accepts relevant tags (default or provider-specific). task - 5154061 Forward-Port-Of: odoo/enterprise#112550 Forward-Port-Of: odoo/enterprise#96742
Resolved issues and error corrections
This pull request addresses a preliminary fix (POC) for inconsistencies in account reporting across various Odoo localization modules (e.g., France, Germany, Spain). The changes involve updating XML data files and models to improve the accuracy and consistency of financial reports. This ensures that reports generated for different regions align with local accounting standards.
Original PR description
wip
4 changes
Resolved issues and error corrections
This pull request addresses minor fixes identified during the recent update of the French VAT (PDP) module. These changes ensure accurate VAT calculations and reporting for French businesses using Odoo. The fixes are backported to the 18.0 release.
Original PR description
Backports some fixes discovered during FW-porting task-None
This update ensures that descriptions are correctly populated on sale order lines when adding delivery items. Previously, new delivery lines didn't use the product's description, leading to incomplete order information. This change maintains accurate product details across the sales process, improving reporting and order clarity.
Original PR description
When a line is added to a delivery related to a sale order, the corresponding line created in the sale order uses only the display_name as a description. This commit makes sure that if a previous SO line exists for the product, the new line uses the same description. Otherwise we call `get_product_multiline_description_sale()` Steps to reproduce: - Create a product with a description in the Sales tab - Create a quotation with any product (can be said product) and confirm it - Go to the delivery action, and add a new line with the product in the view, set delivered quantity to 1 - After Validating, you'll notice that the new line in the Quotation doesn't have a description opw-6175891
This 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