Daily updates from Odoo
Thursday, April 23, 2026
276 changes
25 changes
Resolved issues and error corrections
This update ensures vehicle license plate information is consistently included in XML export files for invoices, regardless of whether the 'account_accountant_fleet' module is installed. This improves data accuracy and consistency across all Odoo environments, particularly those using community databases. It addresses a previous issue where community databases were missing this critical vehicle data.
Original PR description
[FIX] account_fleet: vehicle sent in XML when an invoice line has a vehicle linked, the vehicle license plate will be in the export XML file only if the enterprise module `account_accountant_fleet` is installed. Any community db will then not have the ref included This commit moves the vehicle data in `account_fleet` to expose it to community dbs runbot-242562
This update ensures that vehicle information is correctly included in XML export files for community database versions of Odoo Enterprise. Previously, vehicle data was only included when the 'account_accountant_fleet' module was installed. This change expands the data available in community databases, improving reporting and data consistency.
Original PR description
[FIX] account_accountant_fleet: vehicle sent in XML when an invoice line has a vehicle linked, the vehicle license plate will be in the export XML file only if the enterprise module `account_accountant_fleet` is installed. Any community db will then not have the ref included This commit moves the vehicle data in `account_fleet` to expose it to community dbs runbot-242562
This update corrects a visual issue where the timesheet display overlapped records when scrolling on smaller screens. The changes expand the timesheet layout and adjust its height to prevent double-scrolling, ensuring a smoother and more user-friendly experience for timesheet management.
Original PR description
Before: The systray overlaps the records when scrolling on small screens Changes: - Expands the record list to avoid scrolling overlaps - Make the timesheet list expand before the checkout button to ensure no overlap - Restrict the height of the timesheet list to avoid the double-scrolling problem --- task: 6115674 Forward-Port-Of: odoo/enterprise#114093
This update adjusts how Odoo counts database queries when using its demo data. This optimization improves the speed and efficiency of the demo environment, making it faster to test and understand Odoo's features. The change ensures a smoother experience when working with the demo data.
Original PR description
Query counts were updated for demo data. runbot-242325 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260442 Forward-Port-Of: odoo/odoo#260297
This update fixes an issue where dropdown labels in the bottom sheet would sometimes overflow or overlap with the checkmark icon, particularly on smaller screens. The changes ensure labels wrap correctly and consistently reserve space for the checkmark, resulting in a cleaner and more user-friendly experience.
Original PR description
**Purpose of this PR:**
Before this commit, in the bottom sheet, dropdown labels could overflow their active container or overlap with the checkmark icon when selected.
This commit:
- Allows dropdown labels in bottom sheets to wrap on small screens.
- Reserves space for the checkmark icon in all bottom sheet dropdowns if any item is selected, ensuring consistent alignment.
<table>
<tr>
<td><b>Before</b></td>
<td><b>After</b></td>
</tr>
<tr>
<td><img src="https://github.com/user-attachments/assets/8f347abc-fe26-427a-95ec-97ace3a0c5a2" width="300"/></td>
<td><img src="https://github.com/user-attachments/assets/6d6104b5-46c3-404b-be09-1cfa55209a96" width="300"/></td>
</tr>
</table>
task-[6095602](https://www.odoo.com/odoo/project/1519/tasks/6095602)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#257572The progress bars should show the rate of reviewed and supervised balances/checks. Currently, the bars are too short, and the rate displays None. task-5246850
Original PR description
The progress bars should show the rate of reviewed and supervised balances/checks. Currently, the bars are too short, and the rate displays None. task-5246850
This update resolves an error that occurred when users removed the dismissal date from the 'End of Collaboration' form. The fix adds a check to ensure the dismissal date is valid before performing date comparisons, preventing a type error. This ensures the form functions correctly regardless of whether the dismissal date is set.
Original PR description
Currently, an error occurs when user removes dismissal date on `End of Collaboration` form. Steps to replicate: - Install `hr` with demo. - Open any employee (e.g.- Abigail Peterson) > Click on cog…
Currently, an error occurs when user removes dismissal date on `End of Collaboration` form.
Steps to replicate:
- Install `hr` with demo.
- Open any employee (e.g.- Abigail Peterson) > Click on cog button > End of Collaboration.
- Remove value from `Dismissal date` and click else where.
Error:
```
File "/home/odoo/odoo19/community/addons/hr/models/hr_employee_departure.py", line 56, in _compute_action_date
if departure.action_date and departure.action_date < departure.departure_date:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<' not supported between instances of 'datetime.date' and 'bool'
```
Cause:
- As dismissal date is assigned from departure date [here] and the user removed the value from dismissal date so we receive it as false.
- So, we receive the error from [this] line, as `departure.departure_date` is received as False.
Solution:
- Added a conditional check for `departure_date` before the date comparison.
[here]: https://github.com/odoo/odoo/blob/a9d1b7ad18cfbc90fa415af6675518d687f072f9/addons/hr/models/hr_employee_departure.py#L51
[this]: https://github.com/odoo/odoo/blob/a9d1b7ad18cfbc90fa415af6675518d687f072f9/addons/hr/models/hr_employee_departure.py#L56
No ID
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update corrects a recent change that introduced extra whitespace into our translation files, causing problems with exporting and using existing translations. The fix restores the original process of removing whitespace, ensuring accurate and consistent translations across the Odoo platform. This prevents translation errors and maintains the quality of our software.
Original PR description
Due to the refactor in this commit[^1], we lost the stripping of whitespace from QWeb translations, which caused a lot of whitespace to be included in the exported POT files, invalidating existing translations. This commit restores the stripping of whitespace from QWeb translations. [^1]: https://github.com/odoo/odoo/commit/9eac755406028496375025c8c7fe4128c8740079
This update corrects a technical issue in the IoT setup process that was causing an error. The change ensures the correct default value is used, aligning with Odoo's standard practices and preventing the setup from failing. This improves the stability and reliability of the IoT functionality.
Original PR description
Due to the refactoring in odoo/enterprise#111457, the empty string was removed as an option from the IoT subtype selection. However, in the `/iot/setup` controller the empty string was explicitly used as the default value, which now causes an error due to it not being a valid option. This commit fixes the issue by instead using `False` as the default value, as is standard for Odoo fields.
This update adjusts how social media links are managed within Odoo Enterprise. Following a recent change, social media fields were removed from the website, and this update moves those links to the company record for consistency. This ensures all relevant company information, including social media presence, is accurately reflected.
Original PR description
Since https://github.com/odoo/odoo/pull/236918, there is no more social media fields on website so we move them to res company to comply with website.
This update resolves an issue where Odoo tests were unreliable due to fluctuating timezone settings. Specifically, the rental testing environment was previously dependent on demo data, causing inconsistent results. This change ensures a consistent UTC timezone for all tests, improving stability and reliability.
Original PR description
When demo data is installed, Robodoo's timezone is set to Europe/Brussels. Rental tests expect the environment timezone (`self.env.tz`) to be UTC. However, if Robodoo is the current user and no timezone is set in the context, the environment falls back to the user's timezone. Because Robodoo's timezone changes depending on whether demo data is installed, tests can become unstable. This commit updates the renting app's common test setup to ensure a stable timezone. runbot-242821
A test within the Indian payroll module (l10n_in_payroll) was failing due to a missing employee type ID. This update correctly assigned the necessary employee type ID, resolving the test failure and ensuring proper payroll calculations. This fix improves the stability of the payroll functionality.
Original PR description
[FIX] l10n_in_payroll: fix missing employee type id
Bug reproduction: Go to master and try to run test_in_hr_version_percentage_computation test by installing l10n_in_hr_payroll only. It fails and throws an error.
Bug cause: The employee has not employee_type_id and when with Form is used, employee_type_id is a required field and must be filled in.
Bug solution: I assigned the Indian employee type as a employee_type_id
Runbot Error:
Link 1: https://runbot.odoo.com/odoo/error/241955
Link 2: https://runbot.odoo.com/odoo/error/242490
task - 6117742This update resolves an issue preventing users from increasing the quantity of combo products with 'Sell when Out-of-Stock' disabled. The system now correctly limits the quantity to 1, ensuring accurate inventory tracking and preventing over-ordering. This change was triggered by a recent code update.
Original PR description
You cannot increase the quantity of a combo product that has options with Sell when Out-of-Stock disabled Steps to reproduce: 1. Install Inventory and eCommerce 2. Go to Website > eCommerce >…
You cannot increase the quantity of a combo product that has options with Sell when Out-of-Stock disabled Steps to reproduce: 1. Install Inventory and eCommerce 2. Go to Website > eCommerce > Products and create a new product "Combo" 3. Set the Product Type to Combo, create and edit a Combo Choice "test" with two options "test 1" and "test 2". Both have Track Inventory enabled, 5 Quantity On Hand and Sell when Out-of-Stock disabled 4. Publish product "Combo" to the website 5. Click on smart button "Go to Website" to open the shop page of product "Combo" 6. Try to increase the quantity 7. The quantity is limited to 1 Solution: Always set the quantity input's maximum when `has_max_combo_quantity` is true Issue: We only set the quantity input's maximum if `allow_out_of_stock_order` is false This error was introduced in https://github.com/odoo/odoo/commit/0247538efe788a9ff9a4d58f64470325348a4eaa opw-6050876 Forward-Port-Of: odoo/odoo#260523 Forward-Port-Of: odoo/odoo#257386
This update fixes a bug that prevented users from using keyboard shortcuts (like Tab and Enter) to select values within selection fields in list views. Previously, these shortcuts were blocked, limiting usability. Now, selection fields function correctly with standard keyboard navigation.
Original PR description
Steps: - Open any editable list view (for example sub-list view in sales) - Either it has a selection field or you add it via studio - With two values (for example "true" and "false") - Add a record to your list view - Try to edit the selection field - Popover is opened - You can select any value with a mouse click - You can navigate through values with arrows - You can't select values with `Enter` and `Tab` So list cell in edit mode has a function for all theses hotkeys: - `tab` - `shift+tab` - `enter` - `escape` Because `ListRenderer.onCellKeydown` is called before `hotkeyService.onKeyDown`, if any hotkeys is handled in cell edit mode it will be prevented and the hotkeyService will not propagate it to `select_menu`. That's why arrows are working, because there are not listed in cell edit mode keys. opw-6025476 Forward-Port-Of: odoo/odoo#259699 Forward-Port-Of: odoo/odoo#255029
This update fixes a minor usability issue where the button to add a photo to a contact was too small. The change moves the image upload logic to JavaScript, making it easier to maintain and ensuring a consistent user experience when adding images to contact records. This improves the overall user experience for contact management.
Original PR description
This PR aims to fix an issue where the click zone for `.o_image_uploader_container` doesn't take the appropriate space when adding a new photo to a contact. task-5100043 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228330
This update resolves an issue where opening salary adjustments on mobile devices caused a crash. The fix involved adding a basic kanban view and removing unnecessary overrides related to delete actions, ensuring the feature functions correctly across all device types.
Original PR description
Steps to reproduce ================== - Install hr_payroll - Use a mobile viewport - Go to Employees - Open a record - Switch to the Salary Adjustments notebook tab => TypeError: undefined is not an…
Steps to reproduce ================== - Install hr_payroll - Use a mobile viewport - Go to Employees - Open a record - Switch to the Salary Adjustments notebook tab => TypeError: undefined is not an object (evaluating 'props.activeActions.onDelete=this.onDelete.bind(this)' Cause of the issue ================== The SalaryAttachment2ManyField widget overrides the rendererProps to handle the delete action, but this isn't defined on mobile (because a kanban view is used) See https://github.com/odoo/odoo/blob/9f93f22ed5f6d5dbbafeb0a8c6fababdc2a65d45/addons/web/static/src/views/fields/x2many/x2many_field.js#L196-L212 Solution ======== Since there is no delete action on the kanban view, there is no need for an override. While we are at it, there was no kanban view defined. Thus a default view was used https://github.com/odoo/odoo/blob/138fad6d54a0b59885b1e5c712beb8f581c9555c/odoo/addons/base/models/ir_ui_view.py#L2835-L2846 It only contained the field description. Since that one is optional, records without a description were almost invisible.. Thus we also add a basic kanban view opw-6047295 Forward-Port-Of: odoo/enterprise#114464 Forward-Port-Of: odoo/enterprise#113317
A recent update resolved a bug that caused reports to crash when comparing data containing text. This issue occurred when the report included a string value, leading to an incorrect evaluation of comparison conditions. The fix ensures reports function correctly regardless of the data types within the report.
Original PR description
To reproduce: - Create a company in LU - Open the annual tax report for LU - Click on the comparison filter, compare with 1 period in the past ==> Traceback. This happens because that report contains a string value (an editable one, but it's not important here). Since there are only 2 comparison periods, we try creating the "%" column, comparing their amounts. The condition checking whether or not to display "N/A" was wrong, as it considered the values could only be int/float or None. Here, they are strings, so we don't enter that condition and crash when trying to evaluate float_is_zero on a string. Forward-Port-Of: odoo/enterprise#114296 Forward-Port-Of: odoo/enterprise#112619
This update resolves an issue where the 'Time Off Type' dropdown was empty when creating time off entries via the Gantt view. The fix prevents a technical glitch that was skipping field changes, ensuring computed values are correctly displayed and the dropdown functions as expected. This improves the user experience for time off management.
Original PR description
**Steps to Reproduce:** 1. Open Time Off App->Management->Time Off->Gantt View 2. Highlight multiple dates/cells to trigger the multi-create popover, then click "Set". 3. Open the "Time Off Type"…
**Steps to Reproduce:**
1. Open Time Off App->Management->Time Off->Gantt View
2. Highlight multiple dates/cells to trigger the multi-create popover, then click "Set".
3. Open the "Time Off Type" dropdown. The dropdown appears empty.
**Bug Cause:**
When forceFullDuration is true and request_duration is pre-populated in initial values, the form detects no field changes and skips triggering onchange. This prevents computed fields like allowed_work_entry_type_ids from being evaluated, resulting in an empty domain filter ('id', 'in', []).
**Solution:**
Remove the pre-population of request_duration in initial values when forceFullDuration is true. The context value force_full_duration is sufficient to filter the request_duration field to show only "full" option.
By not pre-setting the value, the form detects a field change and properly triggers onchange, allowing computed fields to evaluate and populate the Remove the pre-population of request_duration in initial values when forceFullDuration is true. The context value force_full_duration is sufficient to filter the request_duration field to show only "full" option. By not pre-setting the value, the form detects a field change and properly triggers onchange, allowing computed fields to evaluate and populate the allowed_work_entry_type_ids correctly.
**Task:** 6109569
Forward-Port-Of: odoo/enterprise#114050This update fixes an issue where invoices generated from KSeF bills weren't correctly processing gross unit prices. The system now properly handles both net and gross unit price options provided by vendors, ensuring accurate invoice generation and compliance with Polish tax regulations. This prevents incorrect invoices and potential tax discrepancies.
Original PR description
**PROBLEM** When receiving bills from KSeF, we don't handle gross unit price and default to a price_unit of 0.0. Leading to an incorrect invoice. When generating the bill, the vendor can choose to report the net unit price (P_9A) or gross unit price (P_9B). We need to handle both cases. opw-6066027 Forward-Port-Of: odoo/odoo#260314
This update prevents email notifications from being sent when generating test payslips. This change improves the testing process by reducing unnecessary email traffic and ensuring consistent test results. It addresses a potential issue where test emails could be generated during development.
Original PR description
In this commit, we prevented email sending during test print payslips. task-6147651 Forward-Port-Of: odoo/enterprise#114593
This update fixes an issue where complex emojis were being incorrectly split into individual characters in the Odoo Discuss messaging platform. The change improves emoji rendering, ensuring that emojis like ❤️🔥 are displayed correctly. This ensures a better user experience for all users sending and receiving messages.
Original PR description
Prior to this commit, emoji sequences were rendered incorrectly in Discuss. The existing regex failed to match multi-codepoint sequences, splitting complex emojis (like ❤️🔥) into separate individual emojis (❤️ and 🔥). Steps to reproduce: 1. Post a message in Discuss containing "🤷♂️" 2. Notice the message displays "🤷♂" instead This commit refines `EMOJI_REGEX` to match complete emoji sequences. [Task-6128638](https://www.odoo.com/odoo/project/1519/tasks/6128638) Forward-Port-Of: odoo/odoo#259829
This update resolves a bug in the overtime calculation process for employees with specific attendance settings. Previously, an empty intervals object caused errors when updating overtime records. This fix ensures intervals are properly populated, preventing crashes and ensuring accurate overtime calculations are performed.
Original PR description
**Context** - "Absence Management" is enabled in the database settings - Employee has an overtime ruleset selected in their employee settings - That overtime ruleset has a rule with a non-zero `expected_hours` - That employee has 1 or more attendance records that start or end at midnight in their timezone. **Before this commit** When updating overtime records, either via the "Regenerate overtimes" button on the overtime rule, or by simply creating a new attendance record, we'll end up passing around an intervals object that contains no intervals. Then, when we later assume this object will have at least one element, we crash. **After this commit** Guarantee that intervals objects are populated before assuming they are. Further, we remove the opportunity to create an empty intervals object that was exposing this bug. opw-6035270 Forward-Port-Of: odoo/odoo#260772 Forward-Port-Of: odoo/odoo#257986
This update ensures delivery carrier availability accurately reflects employee leave, including public holidays. Previously, the system only considered calendar availability. Now, it incorporates leave types for more precise scheduling, improving delivery planning.
Original PR description
before we used attendance_intervals_batch to consider available days but it only considered available days in the calendar, to also consider types of leaves like public holidays we need to use the _work_intervals_batch instead. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes an outdated requirement to specify a country for payment tokens used on subscription invoices. Previously, this caused issues with invoice processing, particularly with certain payment providers. This change simplifies the process and aligns with current payment provider requirements.
Original PR description
Before this commit, a country was mantadory on the payment token when it was used to pay invoices of subscriptions. This behavior was fetched back from internal code in 15.3. This issue was not visible until recently. Some token are fine without country, the provider allows it but the cron fails to process the sale order when the contract is processed. THis commit remove that old constraint. opw-5268156 task-5349998 Forward-Port-Of: odoo/enterprise#113715 Forward-Port-Of: odoo/enterprise#100166
This update resolves a recurring test failure (runbot error 242012) related to product imports. The fix ensures the tests no longer rely on demo data, making them more reliable and consistent. This improves the overall stability of the product import process.
Original PR description
runbot error: 242012 (lasted error in `Post install tests for pos_restaurant -> !sale`: resolved) Forward-Port-Of: odoo/odoo#255497
8 changes
Resolved issues and error corrections
This update fixes a minor visual issue where buttons within the call layout (like Fullscreen) didn't have reduced opacity when not hovered. The fix adjusts the opacity to 75% for non-hover states, ensuring consistent visual feedback and a slightly refined user experience. This improves the clarity of options within the call view.
Original PR description
Recent commit fixes an issue where items like Fullscreen in call menu had reduced opacity when this should only affect layout buttons in call view [1]. To do so it limits the opacity to the layout…
Recent commit fixes an issue where items like Fullscreen in call menu had reduced opacity when this should only affect layout buttons in call view [1]. To do so it limits the opacity to the layout actions, but the style was not applied because ActionList has more CSS specificity that requires using `--o-mail-ActionList-Button-opacity` variable for the non-hover opacity value. Since this was not defined, this default to opacity 100%, thus not applying the reduced opacity when not mouse-hovering. This commit fixes the issue with `--o-mail-ActionList-Button-opacity` of `.75`, so that opacity is slightly reduced when no mouse-hovering. [1]: https://github.com/odoo/odoo/pull/259866 Before / After (mouse-hover on "Picture-in-Picture", see lack of visual distinction) <img width="58" height="32" alt="Screenshot 2026-04-22 at 11 21 47" src="https://github.com/user-attachments/assets/e04b0f8c-c754-4ea4-8870-752610418587" /> <img width="57" height="28" alt="Screenshot 2026-04-22 at 11 21 25" src="https://github.com/user-attachments/assets/a5aa9987-ddaf-45f8-9e2a-260fd04dcfb9" /> Forward-Port-Of: odoo/odoo#260599
This update resolves a visual bug affecting the display of offline status icons on Discuss avatars in Safari. The fix addresses a Safari-specific CSS issue that caused misaligned positioning, ensuring the offline status is correctly shown. This improves the user experience for all users.
Original PR description
IM status on avatars in Discuss have been improved to properly mask the image [1]. To do so, this uses SVG and ForeignObject on top of mask, so that it can uses font-awesome icons such as `fa…
IM status on avatars in Discuss have been improved to properly mask the image [1]. To do so, this uses SVG and ForeignObject on top of mask, so that it can uses font-awesome icons such as `fa fa-circle` for online status. This change introduced an accidental regression in Safari, where position of the offline status is wrong. This comes from a bug in Safari where some CSS inside foreignObject resets the position of the element to position 0, 0 on the global SVG [2] [3]. This affects offline status because this IM status has an `opacity-75`, intended to reduce distraction from the offline, but since this changes opacity this introduce the bug in Safari of mis-position. This commit fixes the issue by moving the applied CSS to change opacity from `opacity-X` rules inside foreignObject to the parent `g` tag above `foreignObject`. That way, the element inside `foreignObject` has no change of opacity but instead the `g` has it, which is ok for Safari. Note that this implementation assumes that change of opacity inside `foreignObject` is made only once and with `opacity-X` classnames. [1]: https://github.com/odoo/odoo/pull/246182 [2]: https://github.com/bkrem/react-d3-tree/issues/284 [3]: https://bugs.webkit.org/show_bug.cgi?id=23113 Task-6143646 Before / After <img width="308" height="579" alt="Screenshot 2026-04-21 at 12 51 52" src="https://github.com/user-attachments/assets/41596916-f371-407e-acb1-eb097c497360" /> <img width="310" height="584" alt="Screenshot 2026-04-21 at 12 51 20" src="https://github.com/user-attachments/assets/513df1f5-4cde-4cb7-8769-d6264dfb36a0" />
This update fixes a bug that occurred when rescheduling work orders in the Gantt view, specifically when dependent operations lacked start or end dates. The fix ensures that date comparisons are only performed when dates are actually defined, preventing a technical error and improving the stability of the Gantt scheduling feature.
Original PR description
Currently, an error occurs when rescheduling work orders in the Gantt view if a dependent operation has no start or end date. **Steps to Reproduce:** - Install the MRP module (with demo data). -…
Currently, an error occurs when rescheduling work orders in the Gantt view if a dependent operation has no start or end date. **Steps to Reproduce:** - Install the MRP module (with demo data). - Activate "**Custom Work Order Dependencies**". - Create a new MO for the _Drawer_ product with _SEC-ASSEM_ BoM. - Confirm and plan the MO. - Remove both start and end dates of any dependent operation. - Manufacturing > Planning > Work Orders > Gantt - Enable **Auto-Reschedule (Keep Buffer)** and reschedule the first operation (in 'Drill 1'). **Error:** `TypeError - '>' not supported between instances of 'bool' and 'datetime.datetime'` **Cause:** At [1], `date_start` and `date_finished` can both be set to False because a condition that bypasses the UserError when both dates are empty (unlike earlier versions). As a result, during rescheduling, a False value is compared with a datetime, leading to a TypeError at [2]. Fix: This commit adds a condition before date comparisons to ensure the dates are defined. [1]: https://github.com/odoo/odoo/blob/3f256437a7e6c124affca8d5304476a67375753f/addons/mrp/models/mrp_workorder.py#L281-L284 [2]: https://github.com/odoo/enterprise/blob/ef2efe113684104032d798b5aa237c67a3bc240a/web_gantt/models/models.py#L484-L491 sentry-7377739830
A recent change in how receipts are printed caused Swedish tax data to disappear from the receipt footer. This fix corrects the receipt template and data generation, ensuring that all Swedish blackbox receipts now accurately display the required fiscal information. This resolves a printing error impacting users of the Swedish POS module.
Original PR description
Since the receipt printing refactor that allowed printing receipts from either the frontend or backend, the fiscal data for Swedish blackbox receipts has been broken. In the frontend, the receipt prints but the blackbox data is missing from the footer. In the backend, attempting to print the receipt gives a 500 error. This commit fixes both these issues by correcting the receipt template and data generation. Community - https://github.com/odoo/odoo/pull/260587
This update resolves an issue where the salary amount wasn't correctly displayed on the Employee Offer form when opened from the employee record. The fix involves adding the necessary context to ensure the correct salary information is populated, improving the user experience for setting up employee offers.
Original PR description
task-5979287
This update fixes an issue where adding a new vehicle (car or bike) would incorrectly make all vehicles available. The change ensures that only vehicles of the same type are made available, maintaining consistent and accurate vehicle tracking. This prevents confusion and ensures data integrity.
Original PR description
When you are getting a new car or a new bike, it'll make available all the your vehicle whatever is the type of vechicle. To keep consistent behaviour, we are only make available vahicle of same type Bug introduced in refactoring: https://github.com/odoo/odoo/pull/220160 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where deleting a document from a sign request would cause the system to crash. The fix ensures the system handles deleted documents gracefully by redirecting the user to a safe view, improving stability and user experience. This addresses a critical bug impacting sign request functionality.
Original PR description
Steps to reproduce: - Open a sign request - Go to Details - Delete the document from the form view - The UI tries to reload the document Issue: The system tries to load a document that has already been deleted. Current behavior: An error is shown and the page crashes when trying to reload the deleted document. Expected behavior: The system should handle the missing document gracefully and redirect the user to a safe view. Fix: Handled the deleted document case properly by returning a valid response and redirecting the user instead of trying to load the removed document. task id- 6095120
This update corrects a visual issue on the subscription portal where product lines weren't correctly aligned with calculated tax totals. The change ensures that only invoiceable product lines are displayed, resolving a discrepancy between the portal view and the underlying financial data. This improves the accuracy and clarity of subscription information for users.
Original PR description
Previously, the portal view for subscriptions displayed all un-collapsed products from the sales order, ignoring whether they were actually invoiceable lines. This caused a visual mismatch where the displayed lines did not correspond to the calculated tax totals at the bottom of the view. This commit updates the visibility logic to ensure that product lines are only included if they are invoiceable. task-6128619 Forward-Port-Of: odoo/enterprise#114088
4 changes
Resolved issues and error corrections
This update resolves a problem where activity updates weren't reliably shared between Odoo tabs. The issue stemmed from interference with a specific internal route (`/mail/data`) during testing. This fix ensures activity updates function consistently, improving the reliability of testing and the overall user experience.
Original PR description
The `@mail/activity/activity/activity updates are shared between tabs` fails in a non-deterministic fashion. It occurs because the `/mail/data` route can interfere with the test. runbot-242616 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#260529 Forward-Port-Of: odoo/odoo#260265
This update resolves a bug where users with limited permissions were encountering errors when accessing task details within subscription orders. The fix involves simplifying data retrieval to prevent privilege-related access issues, ensuring smoother operation for all users.
Original PR description
The change in e75bc6a1fac056d72fe9e73513635f9e0ba7db22 may cause some access errors when the user don't have the proper privileges. STR: 1. Having a user (demo) with minimal permissions: sales own documents, timesheets and project user 2. Having a sales order for customer that demo user can read with services in it. 3. Having that customer a task with a sale that the demo user can't read. 4. When the user tries to change the line to one that he can actually read, an error raises. The display_name function tries to fetch data from the lines related order. Let's just sudo that fetch to avoid these kind of issues. A demo video: https://www.loom.com/share/ddd02d72bcea4652b79549aba47d5334 opw-5969767 cc @moduon MT-14483 Forward-Port-Of: odoo/enterprise#113996
This update streamlines the way Odoo processes XML reports within the l10n_sk_reports module. By using the standard XML parser, we've reduced unnecessary complexity and improved performance. This change ensures more efficient report generation and maintenance.
Original PR description
Removes the custom XMLParser configuration in favor of the default etree parser. This reduces unnecessary overhead and ensures we are using the standard library's recommended defaults for processing XML content.
This update ensures that service order line display names accurately show the price unit when requested, regardless of context. Previously, the display name was inconsistent, potentially omitting the price unit for service products. This fix corrects a bug related to how the 'with_price_unit' context flag is used, improving the clarity and accuracy of service order information.
Original PR description
Before this commit, when `formatted_display_name` is true in the context, the display name of `sale.order.line` records will always show the partner and the price unit if it contains a service product. The problem is `with_price_unit` is no longer checked in the context to really know if we want to display or not the price unit in the formatted display name. This commit checks `with_price_unit` in the context to display the price unit in the formatted display name if it is truly in the context.
3 changes
Resolved issues and error corrections
This update resolves an issue where the 'Time Remaining' value in the project timesheet view wasn't consistently displayed in red, even when the value was negative. The fix ensures that both the label and the numerical value are correctly highlighted in red for negative time remaining, improving clarity for users.
Original PR description
**Steps to reproduce:** - Open project shared form view. - Go to the Timesheets tab. - Observe the Time Remaining value. **Issue:** - The Time Remaining label is red properly but its value does not becomes red even when the value is negative. **Fix:** In hr_timesheet, the remaining_hours field has a decoration-danger applied In sale_timesheet_enterprise, this field is overridden as portal_remaining_hours So, Added the corresponding decoration-danger on portal_remaining_hours. task-5404009 Forward-Port-Of: odoo/enterprise#113632
This update resolves an issue where users with limited permissions were encountering errors when modifying subscription timesheets. The fix involves bypassing data fetching to prevent privilege-related access problems, ensuring smoother operation for users with restricted access.
Original PR description
The change in e75bc6a1fac056d72fe9e73513635f9e0ba7db22 may cause some access errors when the user don't have the proper privileges. STR: 1. Having a user (demo) with minimal permissions: sales own documents, timesheets and project user 2. Having a sales order for customer that demo user can read with services in it. 3. Having that customer a task with a sale that the demo user can't read. 4. When the user tries to change the line to one that he can actually read, an error raises. The display_name function tries to fetch data from the lines related order. Let's just sudo that fetch to avoid these kind of issues. A demo video: https://www.loom.com/share/ddd02d72bcea4652b79549aba47d5334 opw-5969767 cc @moduon MT-14483 Forward-Port-Of: odoo/enterprise#113996
This update resolves an issue where downloading attachments from Odoo's mobile apps (18.4+) was failing due to incorrect URL formatting. The fix ensures that attachment URLs are correctly handled, allowing users to download files as expected. This improves the mobile user experience and prevents download failures.
Original PR description
In Odoo 18.4+, downloading attachments from the chatter is broken.
See: https://github.com/odoo/odoo/pull/200099
The `onClickDownload` function now passes an absolute URL to `downloadFile`.
The download function is implemented natively in the mobile apps.
The Android implementation always prefixes the provided URL with the
database origin (i.e.: `https://example.odoo.com`).
`download({url: "https://example.odoo.com/web/content"})` will try to
download `https://example.odoo.comhttps://example.odoo.com/web/content`.
This results in an UnknownHostException.
We can remove the origin from the url before calling the native method.
By doing this on the JS side, there is no need to update the Android app.
opw-60331509 changes
Resolved issues and error corrections
This fix ensures that tax reports for international customers using foreign VAT IDs correctly utilize the customer's VAT number instead of the company's. Previously, the system incorrectly used the company's VAT, leading to inaccurate tax reporting. This update resolves a critical issue for businesses operating across borders.
Original PR description
### Issue: When a fiscal position defines a `foreign_vat`, tax reports generated for that country still use the company's VAT number instead For example, with a Belgian fiscal position using…
### Issue: When a fiscal position defines a `foreign_vat`, tax reports generated for that country still use the company's VAT number instead For example, with a Belgian fiscal position using `BE010203040`, the generated BE VAT report uses the company VAT instead of `010203040` ### Cause: The report generation did not check whether there is a fiscal position with a `foreign_vat` matching the country of the report ### Note: The example above uses a Belgian fiscal position to reproduce the issue Starting from 19.0, this specific flow is blocked because Intervat is enabled in production mode by default A related fix makes the Intervat settings available in that case Until then, the issue can be reproduced by temporarily commenting out: https://github.com/odoo/enterprise/blob/5fb58a9b7b3ae89f87e84d4ba1fa3a16237d80ac/l10n_be_intervat/models/account_return.py#L15 ### Steps to reproduce: - Disable demo data and install `accountant` - Create a Fiscal Position "Belgium" (Country: Belgium, Foreign Tax ID: BE010203040) - Click the alert to install the Belgian taxes - Create and confirm an invoice for a Belgian customer: - Fiscal Position: Belgium - Any product with a Belgian tax - Invoice Date: 01/01/2026 - Open the Tax Report and select `VAT Return (BE)` for January - Click `Returns` and select the full year - Mark the December return as Completed from the three-dot menu - Review January and fill the missing company data (TIN: 1111111, phone and email) - Click `Validate -> Lock -> Submit` ### Before the fix: The generated XML uses the company VAT number (`1111111`) instead of the fiscal position foreign VAT (`010203040`). opw-6076540
This update fixes a visual issue where the 'Time Remaining' value in the project timesheet view wasn't correctly highlighted in red when the value was negative. The fix ensures that negative time values are displayed in red, providing clearer visibility for project managers and team members.
Original PR description
**Steps to reproduce:** - Open project shared form view. - Go to the Timesheets tab. - Observe the Time Remaining value. **Issue:** - The Time Remaining label is red properly but its value does not becomes red even when the value is negative. **Fix:** - Adjusted the logic to ensure the Time Remaining value is highlighted in red when value is negative **Task-id: 5404009** Forward-Port-Of: odoo/odoo#240489
This update corrects a visual inconsistency in the project timesheet interface. Previously, the 'Time Remaining' value wasn't highlighted in red when negative, leading to a confusing display. The fix ensures that negative time remaining values are correctly indicated with a red color, improving clarity and accuracy for users.
Original PR description
**Steps to reproduce:** - Open project shared form view. - Go to the Timesheets tab. - Observe the Time Remaining value. **Issue:** - The Time Remaining label is red properly but its value does not becomes red even when the value is negative. **Fix:** In hr_timesheet, the remaining_hours field has a decoration-danger applied In sale_timesheet_enterprise, this field is overridden as portal_remaining_hours So, Added the corresponding decoration-danger on portal_remaining_hours. task-5404009 Forward-Port-Of: odoo/enterprise#113632
This update resolves an issue where users with limited permissions were encountering errors when modifying sales order lines within subscription timesheets. The fix involves simplifying data retrieval to prevent privilege-related access problems, ensuring smoother operation for all users.
Original PR description
The change in e75bc6a1fac056d72fe9e73513635f9e0ba7db22 may cause some access errors when the user don't have the proper privileges. STR: 1. Having a user (demo) with minimal permissions: sales own documents, timesheets and project user 2. Having a sales order for customer that demo user can read with services in it. 3. Having that customer a task with a sale that the demo user can't read. 4. When the user tries to change the line to one that he can actually read, an error raises. The display_name function tries to fetch data from the lines related order. Let's just sudo that fetch to avoid these kind of issues. A demo video: https://www.loom.com/share/ddd02d72bcea4652b79549aba47d5334 opw-5969767 cc @moduon MT-14483 Forward-Port-Of: odoo/enterprise#113996
This update fixes an error in how tax returns are calculated for companies with multiple branches. Previously, rounding adjustments were incorrectly applied, leading to inaccurate closing entries. The change ensures accurate tax return calculations by using company-specific data during the closing process.
Original PR description
Some countries lile Estonia, Nederlands or France apply a rounding from the tax report by adding a line to the end of the query results representing the sum of the roundings on each line of the tax…
Some countries lile Estonia, Nederlands or France apply a rounding from the tax report by adding a line to the end of the query results representing the sum of the roundings on each line of the tax report. When having a company with branches, the rounding is applying in each closing move (one per company/branch) but the value is coming from the aggregated report lines, this leads to wrong computation of the closing entries. Cause: In `_generate_tax_closing_entries` we loop over each company, therefore `_compute_tax_closing_entry` is called one time for each company, but it uses the report options containing all companies Fix: Use options with only the current company in `_compute_tax_closing_entry` Steps: - Install FR localisation - Select FR company and create two branches - Create, for last month: - 1 bill for parent company (100 with tax 20% G) - 1 invoice per branch (200 and 300 with tax 20% G) - Create a tax return with opining date at the beginning of the current month - Submit the last return and go to the created closing entries -> See that closing entries are wrong opw-5976359
This update resolves an issue where non-admin users accessing the Accounting Dashboard from a child company with a currency-set journal would encounter an access error. The fix bypasses specific record rules when a currency ID is present, allowing the dashboard to function correctly for all users and company setups. This ensures consistent access to financial data.
Original PR description
Backport of https://github.com/odoo/odoo/commit/e371eb4a1717bfeb65ad756287249a2fb3b13e4f Issue before this commit: Opening the Accounting Dashboard from a child company as a non-admin user raises an Access Error when the journal has a currency_id set. The error occurs with journal which currency id is set Steps to Reproduce: - Install the account module. - Create a child company - Create a journal with a currency set - Log in as a non-admin user. - Select only the child company - Open Accounting (Dashboard) Cause of the Issue: When the journal does not have a currency_id, the system reads company data using sudo(), so no access issue occurs. When the journal has a currency_id, sudo() is not used, and reading the company name triggers an Access Error. With This Commit: Bypass record rules when reading the company name if the journal has a currency_id. opw-6048025 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a technical issue in the French localization of Odoo where the "17" tax tag was incorrectly applied to service taxes, specifically the "8.5% EU Service" tax. This change ensures that tax tags are accurately assigned to goods and services, aligning with French tax regulations and improving financial reporting accuracy.
Original PR description
**Issue:** In French localization, a tax tag (i.e. "17") was wrongly added on "8.5% EU Service" tax. This tax tag should only be applied on taxes for goods, not service. opw-5871998 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260787 Forward-Port-Of: odoo/odoo#260641
This update resolves an issue where the 'cancel' button within the spreadsheet functionality didn't properly trigger the confirmation cancellation process. Now, clicking the cancel button will correctly halt the intended action, ensuring a smoother user experience. This improves data integrity and user satisfaction.
Original PR description
The `cancel` callback of the `env.askConfirmation` method was not called when the user clicked on the cancel button. task-6074948 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#260061
This update resolves an issue where the 'cancel' button within the documents spreadsheet functionality wasn't properly triggering the confirmation process. The fix ensures that clicking the cancel button now correctly halts the action, preventing unintended data changes. This improves user experience and data integrity.
Original PR description
The `cancel` callback of the `env.askConfirmation` method was not called when the user clicked on the cancel button. task-6074948 Forward-Port-Of: odoo/enterprise#112987 Forward-Port-Of: odoo/enterprise#112304
3 changes
Resolved issues and error corrections
This update fixes an issue where the namespace for DIAN credit notes was incorrectly configured, causing errors when submitting to the DIAN tax authority. The namespace has been standardized to ensure proper compliance with DIAN requirements. This resolves a recurring problem identified in a previous related issue.
Original PR description
Issue: Incorrect `sts` namespace raises several issues when sent to dian Steps to reproduce: - On a Colombian company - Create a credit note - Send to DIAN Current Behavior: - Credit note have `sts` namespace defined to `dian:gov:co:facturaelectronica:Structures-2-1` while their Extension node has another `sts` namespace to `http://www.dian.gov.co/contratos/facturaelectronica/v1/Structures` Expected Behavior: - Only the top level Node should have `sts` namespace defined to `dian:gov:co:facturaelectronica:Structures-2-1`. It was forgotten that Credit Note were part of the Invoices in the last refactor. As it's the second time(odoo/enterprise#68619 3rd commit) it happens, I updated the test. opw-6077050 Forward-Port-Of: odoo/enterprise#113643
This update removes automatic tracking of Sales Order status changes within Helpdesk Tickets' chatter. Previously, status updates would log messages, which has now been corrected by explicitly disabling tracking on linked Sales Orders. This improves the clarity and accuracy of chatter conversations.
Original PR description
Before this commit: - The chatter on Helpdesk Tickets tracked and logged changes to the linked Sales Order's status. After this commit: - Explicitly set `tracking=False` on the related `sale_order_state` field in `helpdesk.ticket`. - Status updates to linked SOs will no longer automatically post tracking messages in chatter. task-6079809 Forward-Port-Of: odoo/enterprise#114078
This update corrects a reporting error that incorrectly showed planned hours on public holiday days. The fix ensures the system accurately excludes public holidays from time sheet forecasts by considering timezone differences and handling general holiday calendars correctly. This improves the accuracy of time tracking reports.
Original PR description
### Steps to reproduce: - Install project_timesheet_forecast module - Configure your database to have a far timezone (Montevideo/Uruguay in my case) - Create a public holiday starts from 12AM to…
### Steps to reproduce: - Install project_timesheet_forecast module - Configure your database to have a far timezone (Montevideo/Uruguay in my case) - Create a public holiday starts from 12AM to 11:59PM with a calendar - Create a planning slot for a resource that overlap with the public holiday - Check the Timesheets / Planning analysis report - Group by employees > day **- Check the date of the public holiday and notice there are still planned hours shown** - Remove the calendar from the public holidays that we created previously - Check the report once again **- Notice the day of the public holiday and the day after has no planned hours** ### Cause: In the query we are using to exclude the leave days from the report we only exclude the ones that has calendar_id assigned, not taking into consideration that some of the public holiday are general and is not applied to just one working schedule. Also if we have a leave starting midnight to 11:59PM since we store dates in database as UTC for timezone like Uruguay's one it will shift the end with one day which will introduce inconsistencies ### Fix: We check if the calendar_id is null on the resource_calendar_leaves and make sure we take timezone of the resource into account when checking the dates of the leaves. opw-5027070 Forward-Port-Of: odoo/enterprise#111846
6 changes
Resolved issues and error corrections
This update corrects a minor issue in the journal audit report export template. Previously, the company logo wasn't appearing correctly due to a missing styling class. This fix ensures the logo is displayed as intended, maintaining a consistent and professional look for financial reports.
Original PR description
before this commit, the export template of the journal audit was missing the o_content and so the company logo class was not applied opw-6128819
This update adds 'survey' as a required dependency for the ESG module's automatic installation. Previously, users without 'survey' would incorrectly install it, leading to migration issues. Now, only instances with the necessary dependencies will automatically install 'survey', ensuring a stable and reliable upgrade process.
Original PR description
Description of the issue this commit addresses: As survey is a dependency but not an auto_install requirement of esg_csrd only from 19.0, when migrating to that version, users that don't have survey installed but do have esg will auto_install survey and pull a new computed stored field, ResUsers.karma which causes migrations issues as no script was made to account for that scenario. --- Desired behavior after this commit is merged: This commit adds survey in the auto_install requirements for the module so only instances that already have ResUsers.karma can auto_install esg_csrd --- runbot-238524
This update resolves a technical issue that prevented a key test from consistently failing, ensuring the stability of our reporting features. The change ensures tests are properly configured, preventing errors and improving the reliability of the account reports module. This contributes to more dependable financial reporting.
Original PR description
This test, when run alone, raised an error telling assigning directly self.env.companies was not the right way of doing this, and it was better to create a new env. For some reason, it didn't raise when run together with other tests ; so, runbot didn't see the issue. This commit aims at soothing the ire of Odoo's mighty tests spirits \o/
This update corrects a visual inconsistency in the project timesheet display. Previously, the 'Time Remaining' value wasn't highlighted in red when negative, leading to a confusing user experience. The fix ensures that negative time remaining values are correctly displayed with a red color, improving clarity and accuracy.
Original PR description
**Steps to reproduce:** - Open project shared form view. - Go to the Timesheets tab. - Observe the Time Remaining value. **Issue:** - The Time Remaining label is red properly but its value does not becomes red even when the value is negative. **Fix:** In hr_timesheet, the remaining_hours field has a decoration-danger applied In sale_timesheet_enterprise, this field is overridden as portal_remaining_hours So, Added the corresponding decoration-danger on portal_remaining_hours. task-5404009 Forward-Port-Of: odoo/enterprise#113632
This update corrects a display issue related to time zones, specifically when viewing invoices and purchase orders. Previously, invoices created in time zones ahead of UTC would not appear in reports due to date discrepancies. The fix uses the user's local date to ensure accurate reporting across different time zones.
Original PR description
Why this commit: When loading the 'bills to receive' or 'Invoices to be Issued' The time zones ahead of UTC will face the discrepancy in the view. e.g. etc/GMT-12 timezone is 12 hours ahead of UTC,…
Why this commit: When loading the 'bills to receive' or 'Invoices to be Issued' The time zones ahead of UTC will face the discrepancy in the view. e.g. etc/GMT-12 timezone is 12 hours ahead of UTC, So 12 AM UTC is 12 PM etc/GMT-12. So report view will not include the invoices/bill with order_date of current day till its 12 AM[next day] IN UTC, Meaning etc/GMT-12 will be seeing today's bills/invoices after 12 PM. After this commit: To resolve this discrepancy we use the context_today date to get the user local date. Which is required by the [domain sanitizer](https://github.com/odoo/odoo/blob/8bff78853f6ab8dc2cc951c03bb30181c0745834/odoo/orm/domains.py#L1572-L1574) too. Steps to reproduce (Possible in runbot) : 1. Select etc/GMT-12 timezone in preferences [when UTC is between 13:00-24:00 ~ 1:00-12:00 GMT-12(of next day)] 2. Create a PO and Validate the quantity received. 3. Go to accounting>review>bills to receive. 4. the newly created PO won't be listed here. OPW: 6083526
This update resolves a bug where users with limited permissions were encountering errors when modifying subscription timesheet lines. The fix involves simplifying data fetching to prevent privilege-related access issues, ensuring smoother operation for all users.
Original PR description
The change in e75bc6a1fac056d72fe9e73513635f9e0ba7db22 may cause some access errors when the user don't have the proper privileges. STR: 1. Having a user (demo) with minimal permissions: sales own documents, timesheets and project user 2. Having a sales order for customer that demo user can read with services in it. 3. Having that customer a task with a sale that the demo user can't read. 4. When the user tries to change the line to one that he can actually read, an error raises. The display_name function tries to fetch data from the lines related order. Let's just sudo that fetch to avoid these kind of issues. A demo video: https://www.loom.com/share/ddd02d72bcea4652b79549aba47d5334 opw-5969767 cc @moduon MT-14483 Forward-Port-Of: odoo/enterprise#113996
15 changes
Resolved issues and error corrections
This update ensures that invoices only include timesheets that have been fully validated within Odoo. Previously, the system incorrectly included non-validated timesheets in invoices, leading to inaccurate billing. This fix corrects a bug related to invoicing policies and ensures data integrity.
Original PR description
**Steps to reproduce** - Settings: Timesheets > Invoicing policy = only validated TS. - Have a service product with an invoicing policy based on timesheets. - Create a sales order using this product. - From the SO, click on the "Recorded" smart button and create 2 timesheets. Validate only one of them. - Invoice the SO, using a timesheets period that includes both TS. - Notice that the quantity of the invoice line includes the non-validated timesheet. **Cause** The domain excluding non-validated timesheets provided by `_timesheet_compute_delivered_quantity_domain` is not considered since c3b6053b09222d4bd2237e7de589a63fbef118f1 **Change** Since the purpose of the previous fix was to exclude timesheets linked to an invoice with a date before the "Invoicing Switch Threshold", this can be achieved by tweaking the `timesheet_domain` slightly, similar to the `_timesheet_domain_get_invoiced_lines` domain. opw-6116670
This update fixes a bug that occurred when restaurant orders with active Fiskaly transactions were opened on multiple devices. Without proper data persistence, the system would attempt to create duplicate transactions, leading to errors with the Fiskaly API. This ensures smoother order processing and prevents disruptions for restaurant operations.
Original PR description
In a restaurant POS, when an order with an active Fiskaly transaction is opened on a second device, `transactionState` and `tx_revision` were not available (uiState is not persisted to the server), causing the new device to attempt creating a duplicate transaction with a stale revision, which resulted in a Fiskaly API error. opw-6147654
This update resolves a bug where multiple users were incorrectly added to WhatsApp notification channels after a message exchange. The fix ensures that only the user who initiated the conversation is added, preventing unnecessary notifications and channel clutter. This improves the user experience and reduces potential confusion.
Original PR description
…ser sends a template message when creating discussion channels after the partner sends a message back. Issue: Currently, When there are multiple users listed under whatsapp.account.notify_user_ids no matter what, when creating a new discuss channel it will add all users in that list. Even when a single user inside that list initiated the conversation with a template. To replicate in runbot add multiple users to whatsapp.account.notify_user_ids, make a partner with a number, send a template, then have the partner send a message back. All users will be notified and added to the channel. There was an unformatted number being passed to a function that required the formatted number. This caused _find_active_channel to find 0 active channels. Fix: Format the number received from the message values inside WhatsAppAccount._process_messages opw-5349138
This update resolves an issue where the 'In a Budget' filter in the Odoo Enterprise accounting module wasn't accurately displaying budget records. The fix ensures the filter correctly identifies records associated with a valid budget analytic ID, improving the accuracy of budget reporting. This ensures users see the correct budget records when using this filter.
Original PR description
"In a budget" Filter is expected to show records with a related budget i.e. `'budget_analytic_id' != False`.
This update fixes an issue where the PDF sign panel was overlapping important elements like the 'Next' button, making it difficult to use. The panel has been moved to the right side of the viewer, improving the overall sign process and user experience. This ensures users can easily navigate the sign workflow.
Original PR description
The PDF sidebar is left-aligned, causing the panel to overlap sign guidance elements like the “Next” button when opened. This commit moves the sidebar to the right of the PDF viewer. task-6065586 Forward-Port-Of: odoo/enterprise#112722
This update fixes a visual issue in the Timesheets section of project shared views. Previously, the Time Remaining value wasn't highlighted in red when the value was negative, making it difficult to quickly identify over-estimated time. This change ensures the value is correctly colored red for negative values, improving clarity and accuracy.
Original PR description
**Steps to reproduce:** - Open project shared form view. - Go to the Timesheets tab. - Observe the Time Remaining value. **Issue:** - The Time Remaining label is red properly but its value does not becomes red even when the value is negative. **Fix:** - Adjusted the logic to ensure the Time Remaining value is highlighted in red when value is negative **Task-id: 5404009** Forward-Port-Of: odoo/odoo#240489
This update corrects a visual bug where the 'Time Remaining' value in project timesheets wasn't consistently displayed in red, even when the value was negative. The fix ensures that both the label and the numerical value are correctly highlighted in red for negative time remaining, improving clarity for users.
Original PR description
**Steps to reproduce:** - Open project shared form view. - Go to the Timesheets tab. - Observe the Time Remaining value. **Issue:** - The Time Remaining label is red properly but its value does not becomes red even when the value is negative. **Fix:** In hr_timesheet, the remaining_hours field has a decoration-danger applied In sale_timesheet_enterprise, this field is overridden as portal_remaining_hours So, Added the corresponding decoration-danger on portal_remaining_hours. task-5404009 Forward-Port-Of: odoo/enterprise#113632
This update resolves an issue where swiping between settings on mobile devices would sometimes cause a blank page. The fix ensures the settings page fully loads before transitioning, providing a smoother and more reliable user experience.
Original PR description
Before this commit, swiping between settings for different apps on mobile devices would often result in a blank page. This occurred because the swipe method did not wait for the target page to render completely before completing the transition. This commit ensures the swipe action waits for the rendering process, preventing the blank state during app navigation. Forward-Port-Of: odoo/odoo#260563
This update prevents portal users from seeing the 'View Timesheets' button on invoices when they don't have the necessary permissions. Previously, the system incorrectly displayed the button based on the presence of timesheets linked to the order, even if the user lacked access. This change ensures users only see timesheets they are authorized to view, improving data security and user experience.
Original PR description
sale: add sale order specific hook to extend page values ------ Allows adding custom data (e.g., timesheets) without overriding generic _get_page_view_values sale_timesheet: hide 'View Timesheets'…
sale: add sale order specific hook to extend page values
------
Allows adding custom data (e.g., timesheets) without overriding generic _get_page_view_values
sale_timesheet: hide 'View Timesheets' button for users without access
-------
Steps to Reproduce:
-----------------
- Create a product with the invoice policy set to Based on Timesheets
- Enable Project and Tasks on the order.
- Create and confirm a sale order using a portal user.
- Log timesheets on the related task.
- Create an invoice from the sale order.
- Log in as the portal user and open the invoice.
- Click the 'View Timesheets' button.
Issue:
-------------
The 'View Timesheets' button is shown to the portal user even though they don’t have access to view timesheets.
Root Cause:
------------
The timesheets are linked to the sale order, so the button appears based on the timesheet_count, but the portal user does not actually have permission to access those timesheets.
Fix:
-----------
We replaced the timesheet_count check with a check that verifies whether the user actually has access to any of the related timesheets.
task-4745519
Forward-Port-Of: odoo/odoo#209552A bug was preventing portal users from accessing timesheets. This update corrects a technical issue where the 'View Timesheets' button was incorrectly displayed to users without the necessary permissions. This ensures all users are presented with the correct access controls.
Original PR description
**Issue:** The 'View Timesheets' button is shown to the portal user even though they don’t have access to view timesheets. Currently, we have added _sale_order_get_page_view_values in the sale module, which is overridden in sale_timesheet. We are using it here. task-4745519 Forward-Port-Of: odoo/enterprise#113481
This update ensures that the TicketBai QR code is correctly generated and displayed when a paid order is reprinted after reloading the POS. Previously, the QR code was missing when historical orders were loaded. This fix improves the accuracy of order printing and streamlines the process for users.
Original PR description
When printing a paid order after reloading the POS, the TicketBai QR code was missing. The QR source (l10n_es_pos_tbai_qrsrc) was only set during _postPushOrderResolve after payment, but not when loading historical orders from the backend. opw-6068076 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where taxes were incorrectly removed from POS order lines during backend editing (returns/exchanges). The fix ensures that tax information is properly saved when a POS order is modified, preventing data loss and maintaining accurate tax calculations. This improves the reliability of the Point of Sale system.
Original PR description
The `tax_ids` field on `pos.order.line` is defined with `readonly=True`. When editing a POS order from the backend (e.g. during a return/exchange flow), the `_onchange_product_id` method correctly…
The `tax_ids` field on `pos.order.line` is defined with `readonly=True`. When editing a POS order from the backend (e.g. during a return/exchange flow), the `_onchange_product_id` method correctly sets `tax_ids` from the product, and the computed `tax_ids_after_fiscal_position` displays the mapped taxes in the UI. However, because `tax_ids` is readonly, the web client does not include it in the save payload. As a result, the taxes are silently dropped on save and `tax_ids_after_fiscal_position` recomputes to empty. Steps to reproduce: 1. Create and pay a POS order with a product that has taxes 2. Go to the backend (Point of Sale > Orders) and open that order 3. Initiate a return for the order 4. In the return order, add a new product (exchange scenario) 5. Observe that taxes are correctly shown on the new line 6. Click Save 7. The taxes disappear from the order line The fix adds `force_save="1"` to the `tax_ids` field in both the list and form views of `pos.order.line`, consistent with how `price_subtotal` and `price_subtotal_incl` are already handled in the same views. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a problem where the GSTR vendor invoice fetching cron job failed in multi-company Odoo environments. The fix ensures the cron job retrieves invoices from the correct company within each move, preventing errors and improving data accuracy. This improves reporting reliability.
Original PR description
In a multi-company context, the cron might be run with a user having a default company that is not the same as the target moves companies, maybe raising a `RedirectionWarning` (if the current company is not fully set-up). This commit ensure to fetch the invoice in move's target company. opw-5225553
This update fixes a minor display issue in the Helpdesk dashboard. Previously, the 7-day average rating was shown as a percentage, which was less intuitive for users. Now, the rating is displayed as a score out of 5, making it easier to understand performance.
Original PR description
Steps to reproduce: - Open the Helpdesk app with demo data. - Check the "My Performance" section of the dashboard. Current behavior: - "Avg Last 7 days" is shown as "3.50 %". Expected behavior: - "Avg Last 7 days" is shown as "3.5 / 5". Issue: The backend already computes `7days.rating` as a 0-to-5 average, but the frontend dashboard template appends a "%" suffix. Solution: Update the Helpdesk dashboard template to display the 7-day average as a score out of 5 instead of as a percentage. task-5998903
This update corrects a critical issue where the DIAN web service was incorrectly overwriting CRM contact information, leading to data loss and incorrect invoice delivery. The fix now intelligently handles email differences, preserving commercial contact details and giving users control over their data, preventing manual corrections.
Original PR description
The DIAN web service was overwriting partner names and emails with fiscal data, causing data loss for CRM contacts. The fiscal email often differs from the commercial one, and the overwrite broke the sales flow by sending invoices to the wrong address. Users had no standard workaround short of manually re-entering emails after every invoice generation. Instead of blindly overwriting, only update empty fields and create a child invoicing contact when the DIAN email differs from the existing one. Also remove the automatic onchange and periodic re-fetch triggers to leave existing data under user control. task-5912005
3 changes
Resolved issues and error corrections
This update removes a redundant process in the account_edi_ubl_cii module for Belgium (BE). Previously, the system was incorrectly switching between different data formats when determining the best EDI endpoint. Now that we consistently use the 0208 format, this unnecessary recomputation has been removed, streamlining the process.
Original PR description
When adding peppol, we didn't know if we needed to use the 9925:BE or 0208. Therefore, we switched between them if the endpoint was not found. This has no more use today as we use 0208. opw-5976574 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258297
This update fixes an issue where the 'Hide lines at 0' feature was removing the report-level total line from printed reports like the Trial Balance. The change ensures that total lines, including the main report total, are always displayed when this feature is enabled, improving report clarity and accuracy.
Original PR description
When "Hide lines at 0" is enabled, printing e.g. the Trial Balance will drop the report-level "Total" line when printing. This commit fixes that. The issue was introduced in this commit[^1], which didn't consider total lines without a parent (i.e. root total lines). [^1]: https://github.com/odoo/enterprise/commit/7fec18b99eb2aa5ebc357dcad5f95f234db5b7d8
This update enhances the Peppol deregistration process in Odoo 17.0. Previously, full deregistration stopped all Peppol sending. Now, users can disable reception while retaining the ability to send and update status, offering greater flexibility and control over their Peppol communications.
Original PR description
This commit backport the following: https://github.com/odoo/odoo/commit/2a808bdf5edee14f4f2a1e052ecff4b0aadb1d8d --- Description of the issue this commit addresses: In 17.0, deregistration resets Peppol fully, so users lose both reception and sending instead of only disabling reception. --- Desired behavior after this commit is merged: Users can switch to sender via unregister_to_sender: reception is disabled, but outbound Peppol sending and status updates keep working. --- task-6008121 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr