Tuesday, December 9, 2025
41 changes · 19.0
Resolved issues and error corrections
This update fixes an accounting error related to invoices in Vietnam (l10n_vn). Previously, the system incorrectly created entries for both receivable and payable accounts for 'Unearned Revenue' (account 3387). Changing the account type to 'Current Liabilities' ensures accurate financial reporting and prevents mismatched balances.
Original PR description
When posting an invoice, the system creates: - Journal Entry: Dr 131 (Receivable) / Cr 511 Then the system creates a deferral entry: - Deferral entry: Dr 511 / Cr 3387 (Payable) Falsifying the…
When posting an invoice, the system creates: - Journal Entry: Dr 131 (Receivable) / Cr 511 Then the system creates a deferral entry: - Deferral entry: Dr 511 / Cr 3387 (Payable) Falsifying the Balance sheet report, in the accounts receivable and accounts payable indicators The issue was that account 3387 was configured as `Payable`, which caused the system to generate both Receivable (131) and Payable (3387) for the same partner. This is incorrect because account 3387 represents "Unearned Revenue", which is a current liability, not a payable account. By changing the account type from `Payable` to `Current Liabilities`, the deferral entry now correctly reflects that 3387 is a current liability account, preventing the incorrect reconciliation behavior where both receivable and payable entries were created for the same partner. After this fix: - Entry: Dr 131 (Receivable) / Cr 511 - Deferral: Dr 511 / Cr 3387 (Current Liabilities) 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#238807 Forward-Port-Of: odoo/odoo#237493
This update simplifies the handling of MPF payments in the Hong Kong accounting module. Previously, separate payments were registered, creating complexity. Now, MPF accounts are set to be unreconcilable by default, directing accountants to reconcile directly with the government platform, streamlining the process.
Original PR description
Currently, we register two separate payments for MPF at the same time as we do for the employee's wages. This is not what we want to do; as both are not paid at the same time. MPF is also handled separately, and paid outside of Odoo on the government platform, making the registration of separate payments more complex for not many benefits. Thus, we make these accounts un-reconcilable by default, and will expect accountants to reconcile the statement with the account directly. task-5349299 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238074
This update resolves an issue where email templates were not rendering correctly due to differences in how HTML was parsed. The change ensures that all HTML elements, except for void elements, are properly closed, resulting in consistent and accurate email formatting. This prevents errors and ensures emails display as intended.
Original PR description
**Step to Reproduce:** - install Subscription (with demo data) - try to edit `Subscription: Payment Reminder` email template **Observation:** - Traceback for faulty template **Cause** For outgoing…
**Step to Reproduce:**
- install Subscription (with demo data)
- try to edit `Subscription: Payment Reminder` email template
**Observation:**
- Traceback for faulty template
**Cause**
For outgoing mails, we are using output_method = 'xml' when normalizing html content
https://github.com/odoo/odoo/blob/cb5176df98490ef04c0aac481f010bd2ac2f2424/odoo/orm/fields_textual.py#L580-L587
when this content is parsed using DOMParser in browser,
https://github.com/odoo/odoo/blob/cb5176df98490ef04c0aac481f010bd2ac2f2424/addons/html_editor/static/src/html_migrations/html_upgrade_manager.js#L61-L63
we might get different result.
For a very basic template like this:
```
<div>
<t t-if="ctx.get('error')">
<pre t-out="ctx['error'] or ''" />.
</t>
<t t-else="">
<span>some text</span>
</t>
</div>
```
when parsed using Domparser(), return a faulty template:
```
<div>
<t t-if="ctx.get('error')">
<pre t-out="ctx['error'] or ''">.
<t t-else="">
<span>some text</span>
</t>
</pre>
</t>
</div>
```
Issue roots because of use of self-closing tags, which are valid for xml but not for html
**Fix:**
- we forcefully replace all self-closing tags(which are not void elements) with a closing tag.
- see list of void elements https://developer.mozilla.org/en-US/docs/Glossary/Void_element
opw-5234345
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#238695
Forward-Port-Of: odoo/odoo#235924This update fixes a problem where old work entries persisted across different version schedules. The change ensures that outdated work entries are automatically removed when a new version with a different schedule is created, maintaining accurate record-keeping. This improves data consistency and simplifies reporting.
Original PR description
Problem ---------- When we create a new version with a new working schedule, it will generate correct work entries (because no one was generated for this version before) But it will not remove the previous one for the other previous versions. Solution ---------- Nullify work entries if outside the valid period of the version if they were already created before. task-5065139 Forward-Port-Of: odoo/odoo#232658
This update corrects a technical issue where text labels from buttons (specifically the 'confirm-title' attribute) were not being included in Odoo's translation files. This ensures these messages can be properly translated and displayed correctly in the user interface for all languages. This improves the localization process and user experience.
Original PR description
Description of the issue/feature this PR addresses: The texts from the "confirm-title" attribute of a <button> tag are missing from the POT files. Current behavior before PR: In this line there is a text (the caption of the confirmation window): https://github.com/odoo/odoo/blob/19.0/addons/mass_mailing/views/mailing_mailing_views.xml#L66 "Ready to unleash emails?" - This text is missing from the POT file. Desired behavior after PR is merged: * These texts will apeear in POT files. * Someone needs to translated them * It will show up as translated texts in UI --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue that previously stopped users from creating new Amazon accounts for new companies. The fix ensures that the system correctly handles the absence of warehouses and stock locations when a company is initially set up, preventing a technical error.
Original PR description
Currently, an error occurs when user tries to create a new amazon account on a new company. Steps to replicate: - Install `sale_amazon`. - Create a new company and switch to it. - Go to Settings >…
Currently, an error occurs when user tries to create a new amazon account on a new company.
Steps to replicate:
- Install `sale_amazon`.
- Create a new company and switch to it.
- Go to Settings > Amazon account > Try to Create a new account.
Error:
```
File /home/odoo/odoo18/enterprise/sale_amazon/models/amazon_account.py, line 214, in create
'location_id': parent_location_data[0]['view_location_id'][0],
IndexError: list index out of range
```
Cause:
- Whenever a new company is created, it doesnt have any warehouses [1] and amazon stock locations [2].
- This causes the `parent_location_data` to be an empty list and causes error at line [3].
Solution:
- Assigning the `location_id` if the `parent_location_data` exists.
[1]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L206-L210
[2]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L201-L204
[3]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L214
sentry-7086464738
Forward-Port-Of: odoo/enterprise#101465This update corrects a discrepancy in the number of employees flagged with invalid bank account warnings within the payroll dashboard. The fix ensures accurate reporting by uniquely identifying employees and optimizing database queries to avoid redundant data processing. This improves the reliability of payroll reporting.
Original PR description
description: - `warning_count` for `hr_payroll_dashboard_warning_employee_invalid_bank_account` is wrong when there are multiple versions for a single employee. steps to reproduce: - install `hr_payroll_account_iso20022` - open Payroll (note: have atleast one employee with multiple versions) - find "Employees With Invalid IBAN Bank Accounts" warning on the dashboard - note the count and click on it, the record count differs fix: - returned unique employee ids from `_get_invalid_iban_employee_ids` - also optimized the query in `_get_account_holder_employees_data` method. reasoning: we do not need bank account data from all the versions, because all the versions share same bank account data. task-5252854
This change prevents distracting audio notifications during local testing of Odoo. It addresses a common frustration for developers encountering unexpected sounds from their systems, particularly old ringtones. This improves the testing experience and reduces interruptions.
Original PR description
When running tests locally, it's really annoying (and sometimes really jarring / surprising) to hear random beeps and boops from your machine, especially when it's an old timey ringtone from voip. Make it stop. Forward-Port-Of: odoo/odoo#238906 Forward-Port-Of: odoo/odoo#238882
This update fixes an issue where custom highlights with filling colors appeared darker than intended. By adjusting the opacity of these highlights, the blending of stroke and fill is now handled correctly, resulting in a cleaner and more consistent visual appearance. This improves the overall user experience when using the website's text editor.
Original PR description
We can use custom colors on highlights using the inline text editor, and when the highlight isn't a line (e.g., has a filling inside) and we set its color to have a different opacity than 100%, we can see the stroke and the filling overlap, and the semi-transparent colors blend together, creating a darker appearance along the edges. To see the issue: - Open the website and start editing - Select any text and apply a highlight with a filling, for example, freehand_3 - Click on Color, open the "Custom" tab, and slide the opacity slider down -> Observe the darker appearance along the edges of the highlight, which happens because the highlight svg has both `fill` and `stroke`. task-5104135
This update resolves an issue where the correct group wasn't being assigned to the teleworking field in the payroll module for Switzerland (l10n_ch_hr_payroll). This ensures accurate reporting and compliance with Swiss tax regulations related to remote work arrangements. The change improves the accuracy of payroll calculations.
Original PR description
Forward-Port-Of: odoo/enterprise#101691
This update fixes an issue where product packages weren't correctly associated with their company during packing operations. The previous comparison logic incorrectly linked packages to company records, leading to inaccurate data. This change ensures packages are properly linked to their associated company, improving inventory tracking and reporting.
Original PR description
Steps to reproduce: - Have two packs, A & B - Put something in pack A - Put pack A in pack B Issue: Despite pack A having both a location & a company set, only the location is set on pack B. Due to a faulty comparison, we compare package records with company records, which means the `all()` condition will never be true. Fixes #236413 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where debugging employee records in the Saudi Arabia payroll module would generate errors due to a redundant, unused field. The field has been removed, streamlining the system and improving stability. This change aligns with our stable policy and ensures consistent data management.
Original PR description
### Issue: The field `l10n_sa_leaves_count_compensable` is a computed field with no compute method. When in debug mode, trying to look at the fields of an employee results in a traceback because of…
### Issue: The field `l10n_sa_leaves_count_compensable` is a computed field with no compute method. When in debug mode, trying to look at the fields of an employee results in a traceback because of this. ### Cause: This [forward port](https://github.com/odoo/enterprise/commit/4124dc4c13055d39d233d7ea9374b5191afdfcf2#diff-1d84d9d2c9ad02353f40d1b88baa5c66af063880df1e14459befd2d02d66cae5) had a conflict that was badly resolved by re-adding a previously deleted field. The field was replaced by `l10n_sa_remaining_annual_leave_balance` in [this commit](https://github.com/odoo/enterprise/commit/339bc032aa763c62d4dd27b73fc42488b3e1c3aa#diff-1d84d9d2c9ad02353f40d1b88baa5c66af063880df1e14459befd2d02d66cae5). [Failing FWP](https://github.com/odoo/enterprise/commit/b3f276d0d73a24faf322aa2ae8965c3d5aad4a87#diff-1d84d9d2c9ad02353f40d1b88baa5c66af063880df1e14459befd2d02d66cae5) ### Solution: We can no longer delete the field because of the stable policy. The solution is to remove the compute and add `store=False`. Then remove the field in master. opw-5352456
This update resolves an issue where the Website editor would crash when users pasted HTML code for embedded videos. The fix ensures the system correctly parses video URLs, preventing tracebacks and improving the reliability of video embedding functionality. This enhances the user experience when adding video backgrounds to website content.
Original PR description
Problem: A traceback occurs when adding an embedded video in the Website editor. Cause: The code uses `urlInput` as the URL source, but when an embed is pasted, `urlInput` contains HTML instead of a direct URL. Solution: Parse the `url` instead of using `urlInput` directly. Steps to reproduce: - Go to Website. - Add a slides snippet. - Change the background to video. - Paste embedded video HTML. - A traceback is triggered. opw-5265390 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the approval date for expenses was incorrectly set to 1 AM. By using the current time, the system now accurately calculates the approval date, ensuring proper tracking of expense approvals. This improves the reliability of expense reporting.
Original PR description
When approving an expense, we compute the approval date. We used fields.Date.context_today(expense) that only the the date but the hours are set to 1 AM. By using field.Datetime.now() the hours are computed correctly. task-5262954 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures Odoo IoT boxes can connect reliably, even with older database versions. The system now checks the IoT box's version and skips WebRTC usage if it's not compatible with the latest Odoo version, preventing connection issues. This improves compatibility and stability for IoT deployments.
Original PR description
Since odoo/odoo#238626, WebRTC support has been removed from the IoT box in `master` (19.1). However, since IoT boxes can now pair with older database versions, we need to be able to handle an IoT box that doesn't support WebRTC. This commit adds a check to the version field of the IoT box model, and if it matches the newer format used in 19.1+, WebRTC is skipped. task-5386539
This update corrects a bug in the Inventory at Date report that was preventing it from running correctly for certain products. The issue stemmed from the report incorrectly interpreting date inputs as strings, causing a comparison error. This change ensures the report accurately reflects inventory levels.
Original PR description
For products using lot valuation and real-time valuation, the Inventory at Date report may fail since the to_date value is provided as a string instead of a date or datetime object. This leads to a comparison error when generating the report. Steps to reproduce: - Create a product with lot tracking and real-time valuation, and lot valuated - Create and receive a purchase order for this product - Open Inventory > Reports > Inventory at Date - An error occurs due to a comparison between a string and a date opw-5362378
This update resolves a crash that occurred when users clicked the GIF picker within knowledge article comments. The fix adjusts how the composer picker identifies action placement, ensuring it correctly recognizes buttons within 'extra actions' like those found in chatter. This prevents the application from unexpectedly closing.
Original PR description
Before this commit, opening gif picker in a comment of a knowledge article would lead to crash. This happens because composer uses chatter visual, and pickers in composer picks either the quick or more node element as anchor of picker, depending on whether the action is in the quick or more action. In the case of knowledge article, the buttons are placed in extra actions like in chatter. However the picker placement was not taking into account this place, thus it fails to find action placement. This commit fixes the issue by adding support of extra actions as anchor for composer picker. Task-5163888
This update corrects a warning message related to date and duration calculations for work entries, specifically those linked to holidays. The change ensures that the system accurately prevents overlapping work entries, addressing a potential data inconsistency. This resolves a technical issue that could have impacted reporting accuracy.
Original PR description
Problem ---------- This warning message doesn't make sens with the transformation of work entries date_start/stop in date+duration. No overlap is possible. task-5349515
This update resolves an issue where the SHA512 hashing process in the Swedish SE-SIE import module was not correctly implemented. The fix ensures accurate data integrity for tax reporting, preventing potential errors and compliance issues. This update improves the reliability of the import process for Swedish businesses.
Original PR description
Forward-Port-Of: odoo/enterprise#101511
This update fixes an issue where form fields without labels weren't being submitted. Now, all form fields, even those without labels, are correctly transmitted when the 'send' button is clicked. Additionally, the system now prevents users from removing labels, ensuring data integrity.
Original PR description
Before this commit, a form input without a label would not send its data when clicking send. Steps to reproduce - go to the website editor - add a form - choose any field - delete the field label - save and exit the editor - now in the website, fill the form and click send => the fields without a name label are not sent After this commit fields without a label get sent with a placeholder "unknown_field" task-5062575 Forward-Port-Of: odoo/odoo#237805 Forward-Port-Of: odoo/odoo#225545
This update corrects a bug where work entry durations were not accurately calculated, leading to potential conflicts when editing or adding entries on the same day. The fix ensures that the system correctly sums the duration of all work entries for a given day, regardless of whether they are new or existing, improving data accuracy.
Original PR description
Problem ---------- Work entries on the same day were in conflict only if a work entry was created with a duration > 1000h Even if we write an existing work entry with a duration > 1000h => no conflict. Event if we create multiple work entries, it will only make the sum of work entries created and not existing ones Solution ---------- Check the sum of duration for a day between 0 and 24 hours. Fetch all work entries matching the date of the check to make the sum of durations task-5349515
This update corrects a bug in Odoo 19.0 where setting an employee's timezone to 'None' would cause an error. Now, if the timezone field is left blank, Odoo will display a validation error, ensuring accurate data entry and preventing potential issues with employee records. This improves data integrity and reliability.
Original PR description
Description of the issue/feature this PR addresses: On Odoo 19.0 and master, setting an employee’s timezone to None would cause a traceback when creating or updating the employee. Current behavior before PR: a traceback when creating or updating the employee. Desired behavior after PR is merged: A Validation Error occurs because it missing required value for the field 'Timezone' (tz). Model: 'Resources' (resource.resource) task-5257749 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where inactive accounts were incorrectly displayed in financial reports. The change, related to a new 'active' field, prevents the system from processing inactive accounts in report calculations and auditing, ensuring accurate reporting. This improves data integrity and reporting reliability.
Original PR description
In replacing the deprecated field with the special `active` field the account_codes prefix engine no longer displays values for accounts that are inactive.
This disables the active test in:
- computing the domain for accounts
- auditing the value (since the domain is `('account_id.code', 'in'...)`
opw-5226153
Forward-Port-Of: odoo/enterprise#100885This update corrects an issue in the l10n_ar_stock delivery guide report where a critical message about invoice validity was missing. The fix also eliminates duplicate report names and numbers, ensuring consistent and accurate reporting. This improves the reliability of financial reports for Arabic-speaking customers.
Original PR description
The mention "Document not valid as an invoice" is missing in the delivery guide report. And we shouldn't duplicatethe report name and number. opw-5004345 Forward-Port-Of: odoo/odoo#234506
This update resolves an issue where clicking a record in the Field Service module's Kanban view with the middle mouse button opened the record in the same tab instead of a new one. The fix ensures that middle-mouse clicks correctly open records in new tabs, improving user workflow and efficiency.
Original PR description
Steps to reproduce: 1. Install `industry_fsm` 2. Open Field service module 3. In the kanban view, click a record with the middle mouse button Issue: - The record opens in the same tab instead of a new tab. Cause: - `FsmMyTaskKanbanRecord` overrides `onGlobalClick` without propagating the `newWindow` argument, preventing the expected new-tab behavior. Solution: - Forward the `newWindow` parameter to the parent implementation to restore the correct handling of the middle mouse click opw-5351842 Forward-Port-Of: odoo/enterprise#100926
This update fixes a bug that prevented invoices from being sent to Peppol when certain special characters were present in the data. The fix ensures that invoice data conforms to XML standards, preventing errors and ensuring successful Peppol communication. This improves the reliability of our Peppol integration.
Original PR description
## Issue: When a character that's not compatible with XML is in an invoice, and you send it to Peppol, a traceback was raised: `ValueError: All strings must be XML compatible: Unicode or ASCII, no NULL bytes or control characters` ## Cause: `dict_to_xml` converts each invoice field into XML, but certain control characters (e.g., `\x02`) are not allowed in XML according to the specification: https://www.w3.org/TR/xml/#charsets If such a character appears in the data (e.g., imported through a product CSV), the XML generation crashes ## Steps to produce: - Install `account_peppol` and `l10n_be` (to get the BE Company CoA) - Import a product containing a control character: `echo -e "name,default_code\nTest\x02Product,ABC123" > products.csv` - Create an invoice for the BE company using the product `Test\x02Product` - Send it via Send > by Peppol - A traceback is raised opw-5114648 Forward-Port-Of: odoo/odoo#239053 Forward-Port-Of: odoo/odoo#236836
This update fixes an issue where holiday pay recovery wasn't correctly applied to employees with older contracts. Previously, reopening contracts could incorrectly trigger the recovery process as if the employee was newly hired. This change ensures holiday pay recovery is applied accurately for all employees, regardless of contract history.
Original PR description
Purpose ======= Normally contracts start and end dates should be configured without being closed and reopened at each version date. But, if it is the case, holiday pay recovery could be applied on older employees because it is considered the employee just joined the company, and there is an amount to recover. Forward-Port-Of: odoo/enterprise#101564
This update resolves an issue preventing the payroll demo data installation from working correctly at the start of the year. The fix sets a fixed past year for Mitchell Admin's contract, ensuring the demo data aligns with current payroll calculations. This resolves a technical error reported by automated testing.
Original PR description
Before this commit, the relative date used to generate Mitchell Admin's contract was always at January 1st of the current year, making the payroll demo data install fail when at the start of the year. This commit sets a fixed year in the past for Mitchell's contract. runbot error 234623 and 234612 Forward-Port-Of: odoo/odoo#238711
This update fixes a technical issue within the HTML editor that caused a traceback when users selected a link and then applied a color. The fix ensures the editor correctly handles selections involving special characters like 'feff', preventing errors and improving the overall stability of the HTML editing functionality. This resolves a potential disruption for users.
Original PR description
Problem: When the user selects a link to color and the selection falls on a `feff` character, a traceback occurs. Cause: After commit 927f4b973932d14961c148e13473017651a60dc0, we preserve the…
Problem: When the user selects a link to color and the selection falls on a `feff` character, a traceback occurs. Cause: After commit 927f4b973932d14961c148e13473017651a60dc0, we preserve the selection at: https://github.com/odoo/odoo/blob/bee7fc1f955c52a88b527ad9a2ddf0021529bbc7/addons/html_editor/static/src/main/font/color_plugin.js#L247-L247 and then call `getFonts()`, which internally uses `this.dependencies.split.splitAroundUntil()`. If the selection is on a `feff` node, `splitAroundUntil()` can clear those nodes because `splitElement()` inside it dispatches to `clean_handlers` with the selected element containing the `feff`. Since the preserved cursor offset refers to the node before the `feff` was removed, restoring it throws: `The offset x is larger than the node's length (y).` Solution: After `splitAroundUntil()`, adjust the preserved cursor offsets if the nodes were mutated to ensure they remain valid. Steps to reproduce: It is difficult to reproduce manually, but the issue occurs when coloring a link with the selection on a `feff`. A test case replicating the situation can be based on the original failing template in the customer’s database. opw-4953943 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238922 Forward-Port-Of: odoo/odoo#234328
This update fixes an issue where timesheets weren't correctly reflecting new employee's time off requests. The change ensures that only global time off requests are considered, resolving a problem caused by incorrectly configured time-off records. This improves the accuracy of timesheet reporting.
Original PR description
**Steps to reproduce** 1. Have a future `resource.calendar.leaves` without a `calendar_id` but with a `resource_id`. To achieve this, you can for example install Payroll and Attendance, create a contract with the work entry source being attendances and with no working schedule. Then, create a time off in hours for that employee and validate it. In that case, the `hr.leave` has no `resource_calendar_id` as computed in `_compute_resource_calendar_id`. This leads to a `resource.calendar.leaves` record without a `calendar_id` once the time off is validated. 2. Create a new employee. A timesheet corresponding to the previously created time off is created. **Change** Make sure only global time offs are considered. opw-5248992 Forward-Port-Of: odoo/odoo#237773
This update resolves a technical issue where setting image field widths in list views caused a system crash. The change clarifies that image field widths should be controlled through list view configurations, not the image field itself, ensuring stability and proper functionality for image displays in lists.
Original PR description
Before this commit, if one set the `width` attribute on an image field in a list view arch, there was a props validation crash (in debug mode). The `width` attribute is relevant to be set in list view archs as it allows to specify the width of the column. That attribute isn't meant to be used by the image field itself, where the option `size` can be used to specify the size of the image as a pair `[width, height]`. opw~5392068 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#239069
This update resolves a visual bug where the version timeline in the HR module would disappear when zoomed below 100%. Now, all versions remain visible regardless of the zoom level, ensuring a consistent and user-friendly experience for managing employee timelines.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: . When you zoom below 100%, the other versions from the version bar disapear, leaving only the active one Desired behavior after PR is merged: . When you zoom below 100%, all versions on timeline appears normally task-5401380 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents misleading 'Duplicate' warnings when reverting a payslip in the HR payroll module. Previously, reverting a payslip created related payslips flagged as duplicates, causing confusion. Now, the system correctly identifies these as related and avoids the duplicate warning, streamlining the payroll process.
Original PR description
## Steps to Reproduce 1. Create a payslip and validate it. 2. Mark it as Paid. 3. Click on Revert and it will create a new payslips related to the other payslip. ## Issue When reverting a payslip, it is flagged as a "Duplicate". When there is a payslip that has "Related payslips", it should not be considered as a duplicate. ## Fix Duplicate warnings now ignore the original and refund payslips linked to each other (`origin_payslip_id/related_payslip_ids`) are removed from the duplicate recordset. task - [5240436](https://www.odoo.com/odoo/project/1251/tasks/5240436)
This update fixes a potential issue where test results in Odoo's sale stock module could be inconsistent due to timing differences. The change ensures tests run predictably regardless of the machine's speed, improving the reliability of test results. This enhances the overall stability of the sale stock functionality.
Original PR description
In the case the test runs a machine not fast enough, by the time we reach either assert, there could be at least a millisecond difference between the two dates. Now freeze the time to ensure the test doesn't fail depending on its running speed. runbot-233470 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A test related to date handling in the stock account module was failing in community builds. This change corrects the issue by aligning the test's date locking behavior with established practices in the account module, ensuring consistent test results. This resolves a technical impediment to the stock account functionality.
Original PR description
…test_backdate_picking_with_lock_date ### Issue: The test `test_backdate_picking_with_lock_date` added in https://github.com/odoo/odoo/commit/4ea1853108a73f3d6b593785432f10b41ccc0041 fails in community builds. ### Cause of the issue: The `account.change.lock.date` model is defined in `account_accountant`: https://github.com/odoo/enterprise/blob/b3679bc04d4fcef1da7251e5ca061dfeabe89eae/account_accountant/wizard/account_change_lock_date.py#L11-L16 However, this module is not a dependency of the `stock_account` module. ### Fix: We set the lock_dates directly just as in the `account` tests: https://github.com/odoo/odoo/blob/e91c3817574af8bd48a634e3fb0b2f0e08b21ee9/addons/account/tests/test_account_move_date_algorithm.py#L52-L53 runbot-234673 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects an issue where the payment term line name wasn't updated when changing the invoice's 'Customer Reference'. The fix addresses a technical detail within the system's calculations, ensuring consistent naming conventions for invoices and improving data accuracy. It resolves a discrepancy in how the system handles reference updates.
Original PR description
### Issue: When changing the "Customer Reference" on an invoice, the name of the payment term line is not updated. ### Steps to reproduce: - Create an invoice with payment terms, confirm it - Modify…
### Issue:
When changing the "Customer Reference" on an invoice, the name of the payment term line is not updated.
### Steps to reproduce:
- Create an invoice with payment terms, confirm it
- Modify its "Customer Reference" to 'test' for example
- In the page "Journal Items" the name of the terms line has been recomputed to "test - INV/2025/XXXXX"
- Modify again its "Customer Reference" to 'abcdef' for example
- In the page "Journal Items" the name of the terms line was not recomputed
### Cause:
In `_compute_name()` we only write the name if this condition is `True`:
```py
if n_terms > 1 or not line.name or line._origin.name == line._origin.move_id.payment_reference or (
line._origin.move_id.payment_reference and line._origin.move_id.ref
and line._origin.name == f'{line._origin.move_id.ref} - {line._origin.move_id.payment_reference}'
):
line.name = name
```
The purpose of this line is to keep the name of the line if it was manually inputted. So the logic is: we only write the computed name if the previous name was computed. To check this, we check if `line._origin.name == f'{line._origin.move_id.ref} - {line._origin.move_id.payment_reference}'`.
The issue comes from the use of `_origin` in a compute. `_origin` refers to the record before we make any change. But it is meant to be used for `onchange` methods, in these the values are not yet written so `_origin` refers to the record before saving.
Here, when saving, `line._origin` is the same as `line`, so
- `line._origin.move_id.ref` is the new ref.
- `line._origin.name` uses the old ref (it's currently being recomputed).
### Solution:
Unfortunately, in the compute, there are no trace left of what were the previous values as the write already occurred.
The initial complaint justifying to keep custom line names was that on bills, the line name is empty. So when inputting a custom line name, it was removed by the compute method. The previous fix wanted to be more general by always keeping custom line names.
Considering this, this commit removes part of the previous fix: Now we only keep the custom line name when the compute method wants to remove it. So we keep the previous fix for bills.
### Note
There was a test verifying exactly that when manually deleting the line name, in the end
the line does not have a name. This will no longer be the case but a decision must be made between:
1. updating the line name when changing the ref
2. not recomputing line name when it has been changed manually
3. removing the line name when it's manually deleted
We can have 2 and 3 but not with 1 afaik.
opw-5246917
Forward-Port-Of: odoo/odoo#237710This update fixes a limitation in how barcodes handle rental sales within Odoo. A new hook has been added, allowing businesses to customize barcode behavior specifically for rental transactions. This ensures accurate and consistent barcode scanning for both standard sales and rental operations.
Original PR description
Add a hook method to be used in barcode that can be overriden for `sale_stock_renting`. As there is no common module for these two module, this was put in their common ancestor. opw-5265874 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238753
This update fixes a visual issue where form fields, specifically those using 'Text' type, were displaying a placeholder of 'null' instead of an empty field. This change ensures that all form fields appear correctly, providing a consistent and user-friendly experience when editing website forms. It's a minor cosmetic fix that improves usability.
Original PR description
Steps to see the issue: - Open website and start editing - Drop a form - Add a new field, or click on an optional field, the type of which we can modify - Set the field type to 'Selection' or 'Radio Buttons' (or any other that does not have placeholders) - Set the field type back to 'Text' => Field's placeholder is `'null'`, but it should just be empty. task-5383835 Forward-Port-Of: odoo/odoo#238710
This update corrects a previous issue where employees working less than 6 months were incorrectly denied PFA (Pension Funds Agreement) eligibility. The change adjusts the system to verify an employee's start date is at least 6 months prior, rather than requiring a full 6-month employment period. This ensures accurate PFA calculations for all employees.
Original PR description
If you worked less than 6 months, you could have the right to the PFA. Instead of verifying that the employee worked for 6 full months, we should check that he started at least 6 months ago. task-5405293
This update corrects a display issue where single-value product attributes were appearing twice when the 'accordion' style was selected for product specifications. The fix utilizes a simple SCSS style adjustment, avoiding the need for complex view updates and ensuring consistent product display across the website.
Original PR description
### Issue: In this issue, when specification is set to accordion style, single value attributes is still displayed, making single value attributes duplicated. #### To reproduce: 1- Create a product…
### Issue: In this issue, when specification is set to accordion style, single value attributes is still displayed, making single value attributes duplicated. #### To reproduce: 1- Create a product with a multi-value and a single-value attribute. 2- Using editor on product website page, from style tab, change style of specification to `in accordion`. 3- As you see, single value-attribute is displayed twice. Once in accordion, and one in single-value attributes section. ### Cause: When `specification` is set to other than `None`, IMHO we need to not display `product_accordion` as single values are already displayed: https://github.com/odoo/odoo/blob/ea01165d9486572269c44597a1db49b31bf8aba3/addons/website_sale_comparison/views/website_sale_comparison_template.xml#L196-L209 When `specification` is set to `Bottom of Page`, this is already the case using xpath replace: https://github.com/odoo/odoo/blob/ea01165d9486572269c44597a1db49b31bf8aba3/addons/website_sale_comparison/views/website_sale_comparison_template.xml#L91-L94 However, we cannot do the same in `accordion_specs_item` as it is not inheriting `website_sale.product`. We can instead fix this using scss style, which also won't require updating views. opw-5365375
This update resolves a technical issue that prevented the correct extraction of invoice sequences, specifically when sequences didn't include spaces. The fix uses a regular expression to reliably identify the invoice number, regardless of the separator used (space, slash, or hyphen), ensuring accurate VAT processing.
Original PR description
Before this commit, the method `_get_last_sequence` assumed that the document sequence always contained a space separator (e.g., "INV 12345") It attempted to extract the folio number using `res.split(" ")[-1]`.
If the sequence format did not contain a space, such as the standard Odoo format `INV/2025/01234`, the split would return the entire string. This caused a `ValueError` when trying to cast the non-numeric string to an integer:
ValueError: invalid literal for int() with base 10: 'INV/2025/01234'
This commit fixes the issue by using a regular expression to extract the last group of digits from the sequence string. This ensures the folio number is correctly retrieved regardless of the separator used (slash, space, or hyphen).
opw-5401509
Forward-Port-Of: odoo/enterprise#101665