Wednesday, January 21, 2026
57 changes · saas-19.1
Enhancements to existing features
This update simplifies the process of generating consolidated invoices from Point of Sale orders. Previously, invalid orders (like those already invoiced) would halt the entire process. Now, any problematic orders are automatically ignored, allowing users to generate invoices for the valid orders efficiently. This enhances bulk invoice generation capabilities.
Original PR description
When trying to create a consolidated invoice in the POS from multiple orders, if any of them would not be valid (i.e. invoice already generated, or order still in draft), then Odoo would throw an error and not do anything. Now the orders for which invoices can't be generated will just be ignored, but for the rest of the orders the invoices will be generated as usual. This should make it easier to bulk select and generate invoices only where necessary. Task-[5491082](https://www.odoo.com/odoo/project/1737/tasks/5491082) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243851
This update enhances the restaurant POS system by automatically summing guest counts when multiple linked tables are used. Previously, each table was tracked separately. Now, when tables are linked, the system accurately reflects the total number of guests across all linked tables, providing a more complete picture of customer occupancy.
Original PR description
When two tables are linked in the pos, we would like to sum the guests. Here an example : If Table 1 has two guests and Table 2 has three guests, then Table 1&2 will have five guests. task: 5490906 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243726
Resolved issues and error corrections
This update fixes an error in the Point of Sale order report that incorrectly calculated margins for refunded orders. The fix ensures that refunds are properly accounted for, resulting in accurate margin figures displayed in the report. An app update is required to implement this change.
Original PR description
Step To Reproduce: - have a product with cost price - settle a order in pos with that product and refund it - go to reporting > orders > pivot view - check margin for that refund order Observation: -…
Step To Reproduce: - have a product with cost price - settle a order in pos with that product and refund it - go to reporting > orders > pivot view - check margin for that refund order Observation: - the margin is calculated wrong, as we do not consider order sign - as `margin = price_subtotal - total_cost` - so with price_subtotal `200` and total_cost `-100` margin becomes 300 Fix: - consider order sign i.e. -ve for refund order else +ve for `price_subtotal` - so with price_subtotal `-200` and total_cost `-100` margin becomes -100 **Before** <img width="317" alt="image" src="https://github.com/user-attachments/assets/9e23bc1c-363a-44dd-83c0-da478d9c73d0" /> **After:** <img width="343" alt="image" src="https://github.com/user-attachments/assets/56027cb4-a6c2-4b73-8db8-393e5af0b057" /> Note: for this to be applied, app update is needed opw-5418964 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241870
This update resolves an issue where the POS system in Ecuador would crash when a customer was removed from the partner list after selecting 'Consumidor Final'. The fix ensures a customer is always selected, either a specific customer or 'Consumidor Final', improving stability and compliance with Ecuadorian tax regulations.
Original PR description
Step to reproduce: - install `l10n_ec_edi_pos` - open pos - ensure "Consumidor Final" is selected as partner - open partner list and deselect the partner Observation: - we get a traceback Cause: - we try to set a partner, without proper checks - Also, in the Ecuadorian localization there should always be a customer selected Fix: - rewrote `selectPartner` function to allow following things for EC localization 1. ensure a customer is always selected, a specific one or "consumidor final" 2. when refunding with "consumidor final" customer, changing partner is allowed opw-5350570 Forward-Port-Of: odoo/enterprise#104049 Forward-Port-Of: odoo/enterprise#102221
This update removes a redundant 'OK' button from form dialogs within the Point of Sale system. Previously, this change only applied when the 'pos_appointment' module was active. Now, the change is consistent across all POS form dialogs, providing a cleaner and more streamlined user experience.
Original PR description
Before this commit: =================== - The extra `OK` button in form view dialogs was removed only when the `pos_appointment` module was installed. After this commit: ================== - The CSS to remove the extra `OK` button has been moved from `pos_appointment` to the base `point_of_sale` module, ensuring consistent behavior across POS form dialogs. Task:5406858 Related Enterprise PR: https://github.com/odoo/enterprise/pull/102197 Forward-Port-Of: odoo/odoo#240165
This update removes a redundant 'OK' button from POS form dialogs, ensuring a cleaner and more consistent user experience across all Point of Sale operations. The change was made to standardize the styling across the entire POS module, previously the removal was only applied when the `pos_appointment` module was installed.
Original PR description
Before this commit: =================== - The extra `OK` button in form view dialogs was removed only when the `pos_appointment` module was installed. After this commit: ================== - The CSS to remove the extra `OK` button has been moved from `pos_appointment` to the base `point_of_sale` module, ensuring consistent behavior across POS form dialogs. Task: 5406858 Related Community PR: https://github.com/odoo/odoo/pull/240165 Forward-Port-Of: odoo/enterprise#102197
This update resolves a potential issue where the website editor could fail due to timing problems when opening. By ensuring the editor waits for the iframe to fully load, the editor now works consistently and reliably, especially on slower network connections. This improves the user experience for creating and editing website content.
Original PR description
Steps to reproduce: 1. Set network speed to 3G 2. Create website Page from the systry new menu 3. click on edit button You'll face the traceback. The website editor could try to open before the iframe finished loading, leading to non-deterministic behavior. This commit ensures the editor initializes only after the iframe load event, making the edit action consistent and reliable. Erlier fixed was not covering the all the cases. PR: https://github.com/odoo/odoo/pull/238054 runbot-233039 Forward-Port-Of: odoo/odoo#243256
This update simplifies the process of managing product pricing tags. The 'update all' button has been removed, and now only the buttons for products that have been edited will function. This change streamlines the workflow for pricing adjustments.
Original PR description
To ease update of pricer tags, we removed the "update all" button to only have the one that update edited products. Task: 5380332 Forward-Port-Of: odoo/enterprise#103114
This update fixes a technical issue that could cause list views to crash when aggregating data from certain financial fields. The change ensures that the system gracefully handles situations where currency information isn't automatically provided, preventing errors and improving data reliability in reports and dashboards.
Original PR description
This commit resolves a traceback during list view aggregation when the view is grouped. The crash occurred specifically when aggregating a `float` field that uses the `monetary` widget. Unlike true `monetary` fields, the server does not automatically send a `currency_id` aggregate for `float` fields. The aggregation logic previously failed when this data was missing; it now handles the case by ignoring it since it's not supported. opw-5725692 Forward-Port-Of: odoo/odoo#244548
This update resolves a test failure related to marking inbox messages as read when opening a channel in Odoo. Previously, the test was unreliable due to messages being fetched before the expected RPC call. This change ensures the initial fetch occurs first, guaranteeing the test's consistent results.
Original PR description
The `Opening thread with needaction messages should mark all messages of thread as read` ensures that opening a channel marks the related inbox messages as read. However, this test can fail in a non-deterministic fashion. There are two flows that can mark inbox messages as read: fetching the messages or a manual request after opening the channel. The test expects the rpc to be issued, but if the messages are fetched before, it won't happen thus making the test fail. This commit awaits the initial fetch to prevent this issue. As a bonus, the second flow is also tested. runbot-237970 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#244693
This update fixes a visual issue where the 'Invite a User' dialog in the discuss app didn't fully utilize the available screen space. The fix ensures the dialog expands to the full width of the modal window, regardless of screen size. This improves the user experience and ensures consistent appearance.
Original PR description
Before this commit, the channel invitation dialog had its content not taking the whole width of modal. Steps to reproduce: - Have window take about half size of a 1080p monitor - Open "General" in…
Before this commit, the channel invitation dialog had its content not taking the whole width of modal. Steps to reproduce: - Have window take about half size of a 1080p monitor - Open "General" in discuss app - Open the Member list - Click on "Invite a User" => Invitation dialog takes about half of the width of modal. This happens because the channel invitation was wrongly assumed to be inside a resizable panel, and thus the size was limited by the max width when in resizable panel. The rule to determine whether the action is in a resizable panel was poor: any action panel in discuss app was considered as resizable. This commit fixes the issue by limiting the responsive sizing, intended only for resizable panel, only when the action panel has the `.o_resizable_panel`, which is specific to when action panel is being used inside resizable panel. Task-5804100 Before / After <img width="625" height="231" alt="Screenshot 2026-01-20 at 16 12 31" src="https://github.com/user-attachments/assets/10c02939-c4c1-47fa-82f8-4d8d037d3f0c" /> <img width="621" height="231" alt="Screenshot 2026-01-20 at 16 12 18" src="https://github.com/user-attachments/assets/eec1447c-cb42-4751-b17a-ff7b2e70b8e9" />
This update resolves an issue where the employee presence status widget incorrectly displayed for archived employees. The code has been updated to hide this widget when an employee record is marked as inactive, improving the user experience and ensuring consistent data presentation.
Original PR description
**Steps to reproduce:** Navigate to Employees -> Open an archived employee -> the presence status appears below the Archived banner **Solution:** Hide the presense status widget when the employee is inactive Task: 5350479 Forward-Port-Of: odoo/odoo#236947
This update ensures that eWaybill invoices for Indian exports accurately reflect reverse charge GST amounts. Previously, these amounts were missing, causing discrepancies between Odoo and the government's eWaybill system. This fix aligns the eWaybill data with the correct values, simplifying compliance and avoiding potential issues with tax authorities.
Original PR description
For export invoices, the total invoice value in the eWaybill JSON did not include reverse charge amounts for GST, leading to a mismatch with the value shown in Odoo and the eWaybill generated by the Indian government system. This commit adjusts the JSON computation to include the reverse charge amounts in the total invoice value for exports, aligning it with the government-generated eWaybill, while preserving the existing reverse charge flow. task-5068199 Forward-Port-Of: odoo/odoo#243802 Forward-Port-Of: odoo/odoo#241852
This update ensures that vendor bills with slightly different VAT number formats (with or without dots) are correctly linked to the same contact in Odoo. Previously, variations in VAT number formatting caused duplicate contact creation, leading to data inconsistencies. This change improves data accuracy and simplifies vendor management.
Original PR description
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time)…
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time) where the first bill has these details: - VAT number: `BE0477472701` - Name: `Odoo` And the second bill (e.g three months later) has these details: - VAT number: `BE0477.472.701` - Name: `Odoo S.A` Odoo will do something interesting and will create a second new contact. The reason is because the fallback on `name` from `res.partner` fails (since "Odoo S.A" is not equal to "Odoo". However, the `vat` number matching also fails! Since the VAT number "BE0477.472.701" is not identical to "BE0477472701". Throughout Odoo however VAT numbers are parsed and stored without dots in it. The function `_retrieve_partner_with_vat` however is an exception because the `vat` number here is sanitized for spaces but not for dots. Because of the combination of no exact match on neither `name` nor `vat` it now creates a second contact although the VAT number is technically the same. Desired behavior after PR is merged: Both an incoming vendor bill with `0477.472.701` and `0477472701` match to the same contact even if there are dots in it and if the name of the company is different. P.S: please find two sample XML's here: [sample_odoo_sa_bill.xml](https://github.com/user-attachments/files/24718225/sample_odoo_sa_bill.xml) [sample_odoo_bill.xml](https://github.com/user-attachments/files/24718226/sample_odoo_bill.xml) If you upload both back to back on a default V19 you will see two contacts. After this code change you will only see one contact where both bills are mapped to the same contacts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244572
This update corrects a visual bug where an 'Add Item' button incorrectly remained visible when no topics were present in a web page snippet. The fix ensures the button disappears when there are no topics, preventing a technical error. This improves the user experience by removing unnecessary elements.
Original PR description
Steps to reproduce: - Drag and drop a "Topics List" snippet onto a web page. - Remove all "Topic" items from the snippet so that none remain. - Click the "Add New" button. - A traceback occurs. This bug is caused by the fact that the "Add item" option is defined in the "Options" section of the parent element of the topics. As a result, the option button remains visible even when no topics exist anymore. Clicking it then triggers a traceback because the option attempts to duplicate an element that does not exist. In this commit, we fix the issue by adding an "applyTo" on the option, targeting the topics, so that the "Add New" button no longer appears when no topic is present. Note that the same bug exists for other snippets, and this commit fixes them as well. task-5462596 Forward-Port-Of: odoo/odoo#244126 Forward-Port-Of: odoo/odoo#244034
This update resolves an issue preventing users with the Romanian language pack installed for the l10n_ro_edi_stock module from accessing the settings app. The fix corrects a mismatch in the system's search for translated text, ensuring proper functionality in Romanian.
Original PR description
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module…
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module `l10n_ro_edi_stock` - Select a Romanian company - In Profile > My Preferences > select Romanian language - Try to access the settings -> A traceback occurs **Cause**: The error is caused by this XPath: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi_stock/views/res_config_settings_views.xml#L9C13-L11C21 Specifically, the `'select the option'` part. The XPath tries to replace this line in the parent view: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi/views/res_config_settings_views.xml#L39 but fails to find it because the source text has already been translated at that point, so `'select the option'` no longer matches: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/odoo/tools/template_inheritance.py#L154 **Solution** Only rely on strings that are translation-invariant. opw-5490346 Forward-Port-Of: odoo/odoo#244313
This update resolves an issue where government entities using TAN instead of PAN for their GSTINs were incorrectly flagged with a validation error. The fix adjusts the system to properly handle GSTINs based on TAN, ensuring accurate partner data creation for these important customers. This improves the usability of the system for government clients.
Original PR description
### Issue: When using a GSTIN belonging to a government institution, saving the partner raises a ValidationError This happens because these entities often use a TAN (Tax Deduction and Collection…
### Issue: When using a GSTIN belonging to a government institution, saving the partner raises a ValidationError This happens because these entities often use a TAN (Tax Deduction and Collection Account Number) instead of a PAN as the base for their GSTIN ### Cause: In 19.0, PAN handling was refactored using the new `pan_entity` mechanism With this change, PAN values are validated through `_check_pan_name()`, which incorrectly raises a `ValidationError` for GSTINs that rely on a TAN instead of a PAN: `The entered PAN seems invalid. Please enter a valid PAN.` The PAN entity shouldn't be created for non PAN number ### Steps to reproduce: - Install `l10n_in` and `contacts`, then switch to IN Company - Create a new contact with GSTIN: `07DELN10357E1DH` - Save and the Error is raised ### Notes: At the same time, we'll set the TAN if the GSTIN is based on it The documentation for the TAN structure: https://incometaxindia.gov.in/tutorials/23.%20tan.pdf opw-5461356 Forward-Port-Of: odoo/odoo#243737
This update corrects a calculation error in the fleet module related to the initial date of vehicle acquisition. By setting a default acquisition date, the system now accurately calculates baseline ATN (Activity Tracking Network) metrics, leading to more reliable fleet performance reporting. This ensures better insights into vehicle usage and operational efficiency.
Original PR description
Forward-Port-Of: odoo/odoo#244705
This update resolves a technical issue where a default rate was incorrectly overriding the rate used in delivery FedEx test scenarios. By clearing the existing rate, the tests now accurately reflect the intended rate configurations, ensuring reliable test results. This improves the stability of the delivery FedEx module.
Original PR description
Issue ----- There is some existing rate that takes precedence over the one specified in the test. Rates should be unlinked for safety. ----- Runbot error 237965 Forward-Port-Of: odoo/enterprise#104779
This update fixes a misleading message related to part-time salary calculations. Previously, the system was displaying information based on full-time gross pay, which is no longer accurate due to the change in calculating part-time gross pay. This ensures the system correctly reflects the new part-time salary figures.
Original PR description
Since we are now setting the part-time gross and not the full time gross, this message is misleading. Forward-Port-Of: odoo/enterprise#104877
This update resolves a bug where the link popover would incorrectly appear on input fields within protected nodes. Previously, focusing an input inside a link would trigger the popover. Now, the popover only appears when the input itself is the active element, ensuring a smoother and more predictable user experience when editing content.
Original PR description
Problem: When the previous focus was on a link, then focusing an input inside a non-editable protected node shows the link popover on the input. Cause: Given the following structure: `<a>a</a><span…
Problem: When the previous focus was on a link, then focusing an input inside a non-editable protected node shows the link popover on the input. Cause: Given the following structure: `<a>a</a><span protected non-editable><input></span>` If the selection is inside the link and the link preview popover is visible, clicking on the input triggers a selection change. Since the input is inside a protected node, the editor keeps the previous editable selection. As a result, `LinkPlugin.handleSelectionChange` still treats the selection as being inside the link and reopens the link popover. Solution: Only show the link popover when the `activeElement` is the editable element. Steps to reproduce: - Add a link. - Upload a file. - Place the selection on the link. - Focus the file name input to rename it. - Observe that the link popover is shown on the file name input. opw-5414078 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240016
This update resolves a bug where changing an inactive currency on invoices and bills caused display errors and crashes in the invoice/bill list views. The fix ensures the front-end correctly receives and uses currency data, preventing these issues and improving the user experience when working with multiple currencies.
Original PR description
In the form view of invoices and bills, if the currency is changed to an inactive one, an option to activate it from the form view was available, but when the button is pressed the front-end doesn't receive the new data related to the currency which resulted in unexpected errors when trying to view the invoice/bill or the list of invoices/bills task-5412003
This update prevents users from misconfiguring the category snippet within the website builder. Previously, users could unintentionally change the snippet's content to display products or blogs instead of categories, resulting in empty blocks. This fix ensures the snippet functions as intended for category listings.
Original PR description
Steps to reproduce: ==================== 1- Go to any product and in the tab Sales add some accessory products 2- Go to the website and edit a page 3- Add a category list block 4- Change category list filter to "Accessories for product" 5- Save -> The block is empty Cause: ====== The category snippet was meant to be used only for categories. The problem is that its possible to change from "Categories List" to anything else. When the user makes the choice to add a categories snippet he shouldn't be able to change the content of the snippet from categories to products, blogs, etc.. Solution: ========== Prevent replacing the category snippet to anything else. opw-5497284 Forward-Port-Of: odoo/odoo#244053
The picking operations report was incorrectly printing all deliveries on a single page when multiple deliveries were selected. This change addresses a layout update that removed automatic page breaks, now forcing the report to split across multiple pages for better readability and printing. This ensures reports are easier to manage and print effectively.
Original PR description
When printing several picking operation at once, they are all in the same page. Steps to reproduce: ------------------- * Inventory>Operations>Deliveries * Create several Deliveries * Open list view to see all the deliveries * Select several deliveries * Print > Picking Operations -> All the picking operation report are on the same page. Observation: ------------- Since the change on the picking report layout https://github.com/odoo/odoo/pull/152280/changes#diff-7542c191def78bd64f54f1c33fde2c73e19e4d27f92b195c464d1d84e55b682fL6-R8 the report now uses a single article container for all records, this don't trigger automatic page break. opw-5481034 Forward-Port-Of: odoo/odoo#243817
This update enhances the security of user profile editing by utilizing a new internal function, '_can_edit_country()', to determine if a user is authorized to change their country setting. This change, following a previous update, ensures that only permitted users can modify their profile information, improving data integrity and security.
Original PR description
In 'save_edited_profile()', we check that the user can edit his country_id if he tries. As from saas-18.4, a new helper '_can_edit_country()' is available. This commit uses that helper to perform the check. Follow-up of #239789 Task-5331916 Forward-Port-Of: odoo/odoo#244694
This update resolves an issue where registration emails for events were displaying duplicate headers and footers. The fix removed an unnecessary email layout setting that was causing this duplication. This ensures a cleaner and more professional email experience for event attendees.
Original PR description
**Steps to reproduce:** - Go to Event module - Go to an open event - Register for the event - Go to the Attendees of the event - On the attendee record, click `Send by Email` - The received email shows twice the header and footer **Issue:** Encapsulating notification layout was applied with `default_email_layout_xmlid` but the main template used is `event_registration_mail_template_badge` which already has its own header and footer. **Fix:** Removed the `default_email_layout_xmlid` opw-5032767 Forward-Port-Of: odoo/odoo#236667
This update fixes a visual glitch in the spreadsheet edition where the chart's data source selection panel didn't update correctly after linking a datasource. Users could link a datasource, but the interface would still display the previously linked one. This ensures a smoother and more accurate data source selection experience.
Original PR description
Currently, when a user links a chart to an odoo datasource, the sidepanel is not updated properly when the user tries to select a datasource from the same type as the one already selected. How to reproduce: - In a spreadsheet, insert a chart and a list datasource - duplicate the list datasource - in the chart sidepanel, select list#1 as link - now try to select list#2 -> the model update the link to list#2 but the interface still shows list#1. Task-5725964
This update resolves an issue where the partner ID wasn't correctly passed through stock move processes, particularly in multi-step delivery scenarios. The fix harmonizes how partner information is set within procurement records, ensuring accurate customer association for shipments. This prevents incorrect customer assignments during order fulfillment.
Original PR description
*mrp{,_subcontracting_dropshipping}, point_of_sale, sale_purchase, {purchase_,sale_,}stock ### Issue: The partner_id (contact field) of stock move is no longer propagated in pull chain since the…
*mrp{,_subcontracting_dropshipping}, point_of_sale, sale_purchase, {purchase_,sale_,}stock
### Issue:
The partner_id (contact field) of stock move is no longer propagated in pull chain since the procurement/reference refactoring of 19.0 see 2713876dbc70d3984e584a9037a2206dcda4e84a
#### Steps to reproduce:
- In the settings enable Multi-Steps routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Set your warehouse in two step deliveries
- Modify the routes to have two pull rules: Stock -> Out -> Customer
- Create and confirm an SO, 1 unit of a storable product for a customer
#### > While the customer is set on the ship move and picking it is not on the pick move and picking.
### Cause of the issue:
Due to the configuration, the ship move is created by the `action_launch_stock_rule` and linked to the customer via the procurement created from the sale order line:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/sale_stock/models/sale_order_line.py#L295 Then, the confirmation of the ship move generates a second procurement for the pick move creation. Prior to 19.0, the partner_id of this second procurement was set to the customer via the procurement group: https://github.com/odoo/odoo/blob/712cd806c38e193acdb966e4d3b339ab780f158e/addons/stock/models/stock_rule.py#L333 However, since procurement groups have been removed by the reference refactor 2713876dbc70d3984e584a9037a2206dcda4e84a, the partner id is now expected to be set from the procurement values:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/stock/models/stock_rule.py#L332 As it is not set by any mean in this procurement values it will therefore not be propagated.
### Additional changes:
1. The `partner_id` of the procurement values needs to be harmonized are some methods set a recordset and others a record id:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/point_of_sale/models/pos_order.py#L1707
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/mrp_subcontracting_dropshipping/models/stock_orderpoint.py#L10-L13
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/sale_stock/models/sale_order_line.py#L295
The correct behavior is to set an id since the `partner_id` value of the procurement group is used in the `_get_stock_move_values` and written in its "raw state" as the `partner_id` values for the stock move for creation (when sale_stock is installed):
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/sale_stock/models/stock.py#L171-L174
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/stock/models/stock_rule.py#L378-L381
2. The `partner` key of the procurement values is set by to `partner_id` in every overrides but since 2713876dbc70d3984e584a9037a2206dcda4e84 was incorrectly cahnged to `partner`:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/stock/models/stock_rule.py#L332
We change back this key to the expected `partner_id` and revert the associated pos fix 203f807a2b764821ec4673515dd29f392ec37b3a using the changed `_get_partner_id` method.
3. In certain use cases, such as inter-warehouse transfer the the `partner_id` should not be propagated by the pull chain as it is expected to be set by the `_get_stock_move_values`:
https://github.com/odoo/odoo/blob/df01277bc053218dda6157f2f0657432e91e1d58/addons/stock/models/stock_rule.py#L339-L346
4. Since the `partner_id` is used to set the `dest_address_id` here:
https://github.com/odoo/odoo/blob/92486bab9b73f4370629452c454c25371d5063ac/addons/purchase_stock/models/stock_rule.py#L350
But is suppose to be reset for non dropshipping use case:
https://github.com/odoo/odoo/blob/df01277bc053218dda6157f2f0657432e91e1d58/addons/purchase_stock/models/purchase_order.py#L80-L82
We need to modify the fix of 3fb81df557553d471ff72998200097b3a0ea666f in order for the value set by th epartner_id to be reset in case we are not in a dropshipping use case.
Similarly, we should only add the `partner_id` of the procurement value as a possible `dest_address_id` in the dropship use case:
https://github.com/odoo/odoo/blob/2c0c26e6cc61f70c91617617ef77f23cfaa1dde6/addons/mrp_subcontracting_dropshipping/models/stock_rule.py#L19-L23
5. Since we are setting a default falsy 'partner_id' values in the `_prepare_procurement_values` of stock moves (e.g.`self.partner_id.id`) we needed to slightly alter the `_prepare_purchase_order` of the `mrp_subcontracting_dropshipping` module so that it sets the partner of the subcontractor when the move sets it to `False` rather than unset:
https://github.com/odoo/odoo/blob/1ac7834a9b9d07760700f6d7c73dfe270a247752/addons/mrp_subcontracting_dropshipping/models/stock_rule.py#L10-L11
opw-5428063
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#243028This update fixes a problem where canceled orders and their items persisted in the system, leading to incorrect order displays. Now, when an order is canceled and a new one is created, the system accurately reflects the changes, ensuring correct quantities and totals are shown. This improves the user experience for self-order functionality.
Original PR description
`point_of_sale`, `pos_self_order` ### step to reproduce: - Configure self order with online payment. - Open POS Self Order. - Add some products to the cart. - Cancel the order. - Create a new order and pay it via an "online payment" method. - Click on "Order Now". ### issue: - Previously cancelled products reappear as selected in the new order. ### reason: - Cancelled orders and orderlines were not removed from IndexedDB. - With Pay after Meal, a second order on the same table reused the existing one, causing the product card, order widget, and cart to show quantity and total from the old order instead of the new changes. ### fix: - Ensure both the order and its orderlines are removed from indexeddb when cancelling an order. - Product/cart page must show changed quantity and amount. task: 5005174 Forward-Port-Of: odoo/odoo#243971 Forward-Port-Of: odoo/odoo#224918
This update resolves an error that appeared when users set their timezone to "localtime" in Odoo, causing the Avatar card to display an "Invalid DateTime" message. The fix converts "localtime" to the browser's timezone and adds a validation check to ensure time formatting only occurs with valid timezones, improving the user experience.
Original PR description
Purpose of commit: Avatar cards displays “Invalid DateTime local time” when a user’s tz was stored as the literal “localtime”, which Luxon can’t resolve. Add a helper to resolve “localtime” to the browser zone and keep a validity guard so formatting only runs with valid timezones. Steps to reproduce: - Login with user A change the timezone of the user A from the preferences tab. Change it to "localtime" - Login with user B, open avatar card of user A, the below error is shown. <img width="200" height="200" alt="image" src="https://github.com/user-attachments/assets/bd0ad9dd-619f-41dc-bdf1-0a111e2a8862" /> task-5477788
This update resolves a technical issue where assets components were missing from the merged account_batch_payment module. This ensures the module functions correctly and avoids potential performance problems. The fix was implemented as a routine maintenance update.
Original PR description
During the merge of the module account_accountant_batch_payment and account_batch_payment, we forgot to add the components to the assets of the merged module cfr: https://github.com/odoo/enterprise/pull/97544/files#diff-59095aa2812fc8b48436f7aaf3416dc40bb273c7d234ec18a37ac1576d0643e4
A bug preventing the Gantt view from opening has been fixed. This issue occurred when the system couldn't properly access project data, resulting in an error. This update ensures the Gantt view functions correctly for all users.
Original PR description
Currently, an error occurs when the user opens the Gantt view. **Steps to Reproduce:** - Install `timesheet_grid` without demo data. - Go to `Settings` and enable `Project Stages`. - Go to `Projects` and switch to the `Gantt view`. `UnboundLocalError: cannot access local variable 'project' where it is not associated with a value` This error occurs because, in [this commit], line [1] is mistakenly placed outside the loop. If self has no records, project is not defined, and accessing project.date_start raises an error. This commit moves the line inside the loop. [1]: https://github.com/odoo/enterprise/blob/34feeda7d0835d8c65d91493314133b8e83610d1/timesheet_grid/models/project_project.py#L50 [this commit]: https://github.com/odoo/enterprise/commit/c3296d1441400d20e3815207baa1188b5cb8fd93#diff-59e7d75aff5c1e890cd536834137eac5cd3ad185cb45ee1e157be15402cbc90fR50 sentry-7204644855
This update adds a 'Reload Data' button to error dialogs in the Point of Sale system, providing users with a simple way to resolve common issues. Previously, users only had an 'Ok' button, making it difficult to recover from errors. This change reduces downtime and improves the overall user experience for restaurant and online payment operations.
Original PR description
Purpose: ------------ - On Error dialogs, users only had "Ok" or could close the dialog, with no guidance on what to do next. - Many blocking issues are resolved simply by reloading POS data. Before this commit: ----------- - Error dialogs only had an "Ok" button. After this commit: ------------------ - Added a "Reload Data" button for quick recovery of common blocking issues. - Added a warning message in the reload data popup - For POS Restaurant, orders will attempt to sync before reloading data, reducing the risk of data loss. Task-5353590 Forward-Port-Of: odoo/odoo#243863 Forward-Port-Of: odoo/odoo#238112
This update resolves a bug where combo choices weren't displaying correctly in the self-order kiosk and online ordering systems. Previously, users had to reconfigure combo choices after selection. This fix ensures combo choices are displayed correctly without requiring manual reconfigurations, improving the user experience.
Original PR description
Before the fix, when we set a product variant as combo choice. In self/kiosk, we'll see the product template instead of the product itself. And we need to configure it again. It occured because for all of the products in the kiosk/self, we display the product template. The expected behavior if we set a product variant as combo choice is to have the product variant in the combo directly without having to reconfigure it. The bug occurs only since 19.0 because a fix was already done from 18.3 to 18.4 in this pr : #219908 but the fwport for 19.0 has never been merged. task: 5493798 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244055
This update resolves an issue where invoices sent to Viettel's SInvoice system were failing due to incorrect decimal formatting. The change ensures the tax amount is calculated using the currency's rounding rules, preventing these errors and improving invoice processing with SInvoice.
Original PR description
When sending an invoice to SInvoice (Viettel), the API raises an `INVALID_DECIMAL_POINT_TAX_MONEY` error if the tax amount contains excessive decimal places (e.g., 100.02999999999997). This occurs because the tax amount is currently calculated using simple subtraction (`total - subtotal`). Due to standard floating-point precision issues, this can result in unrounded values that the API rejects. The tax amount calculation is now updated to explicitly use the currency's rounding method, ensuring the value is accepted by SInvoice. task-[5484845](https://www.odoo.com/odoo/project/967/tasks/5484845) Forward-Port-Of: odoo/odoo#244647
This update corrects a bug where the 'Import Bank Statement' action incorrectly selected a journal in multi-company Odoo setups. The fix ensures the action filters by the currently chosen company, preventing errors and ensuring accurate bank statement encoding. A new test confirms the fix's reliability under sudo rights.
Original PR description
Issue: when using the server action 'Import Bank Statement' the code would not filter on the currently selected company for choosing the journal on which to encode the bank statement and simply take the first result. Because the server action is running with sudo rights, in a multi-company environment more then one journals are found and the selected one is often wrong. Solution: filter on company during the selection of the journal. Note: a test was added in which we run the function with sudo rights to ensure an error is raised when the journal does not exist on the currently selected company, even if it is present on another company. Task-5494685 Forward-Port-Of: odoo/enterprise#104970 Forward-Port-Of: odoo/enterprise#104326
This update fixes an issue where employees on leave were incorrectly flagged for overtime. Now, when an employee is on a full day of leave, all hours worked are treated as overtime, without considering breaks. This ensures accurate overtime calculations for all employees.
Original PR description
This PR aims to fix how the overtime is being calculated with quantity based rules : - The expected _hours didn't take into account the leaves of the day , so if the user was on a leave, it would considered him absent ( give him negative overtime) , because he has no attendances that day. - if the employee took a whole day off, and decided to work on it, all the hours should be considered as overtime, the brake shouldn't be included (ex : his normal work sched is morning (9h-12h) , break(12h-13h), afternoon(13-17h) , he's already getting paid for that time , so every single hour worked that day from 12am to 12 pm is added time , and there is no break in added time) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244048
This update fixes tests related to overtime calculations based on quantity. The changes reflect a recent update to the overtime calculation logic, ensuring the tests accurately reflect the new system. This improves the reliability of our overtime tracking processes.
Original PR description
this PR made some changes to how overtime is calculated by quantity based rules. This PR aims to adapt the test to the new calculation logic Forward-Port-Of: odoo/enterprise#104607
This update resolves a bug where the column layout within the HTML editor would break after performing undo operations. Specifically, changing the number of columns using Powerbox would corrupt the column structure. This change ensures the column layout remains consistent and functional after undoing changes.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Create 3 columns using powerbox - Convert it into 4 columns - Press ctrl + z to make it 3 columns - Convert it into 4 columns again using powerbox Notice that column structure is broken. This happens because after undo operation, in `changeColumnsNumber` the regex replaces column div className incorrectly leading to invalid colund structure. **Desired behavior after PR is merged:** This PR ensures that column structure doesn't break. task-5468578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242500
This update resolves an issue where a system error prevented users from selecting the Auto-Complete field in the Bills module when a Vendor wasn't initially chosen. The fix hides this field until a vendor is selected, preventing the error and ensuring a smoother user experience. This improves usability within the invoicing process.
Original PR description
Currently, an exception is generated when the user tries to select `Auto-Complete` without selecting `Vendor`. Steps to produce an error - Go to Invoicing > Vendors > Bills > Click New - Try…
Currently, an exception is generated when the user tries to select `Auto-Complete` without selecting `Vendor`. Steps to produce an error - Go to Invoicing > Vendors > Bills > Click New - Try selecting `Auto-Complete` >>> Error occurs Error `AssertionError: Invalid falsy real id` This error occurs because, after the recent refactoring in commit [1], falsy ids are no longer allowed in domains. In the `Account Entry` view `[partner_id]` (see [2]) is passed as part of the domain. When the user has not selected a vendor (partner_id) it evaluates to False, which results in [False] being passed and triggers the error introduced by commit [1]. This commit will fix the above issue by hiding the `Auto-Complete` field when `Vendor` is not selected. [1]: https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f [2]: https://github.com/odoo/odoo/blob/7b288aa436f669d8c8e2ddac5277bb98321a390e/addons/account/views/account_move_views.xml#L1067 Sentry-7201563878
This update corrects a technical error in the IoT drivers that prevented proper data processing. The system was incorrectly interpreting pin data as a dictionary, leading to a system crash. This fix ensures data is handled correctly, improving stability and reliability of IoT integrations.
Original PR description
Batch action provides only the pin as a string. We had a traceback when trying to get `high_level_message` as if the data provided was a dict.
This update prevents the API documentation endpoint from crashing when encountering models not currently defined in the Odoo system. The fix addresses a technical issue where the system would fail to load documentation due to missing model definitions, ensuring the endpoint is consistently available. This improves the reliability of the API documentation for users.
Original PR description
When accessing the API documentation endpoint (`/doc`), the server could crash with an Internal Server Error if the database contained ir.model records for models that are not loaded in the current registry. Steps to reproduce: 1. Insert a record into `ir_model` with `model='ghost.model'` and `state='base'`. 2. Open `/doc`. 3. The server raises a `KeyError: 'ghost.model'`. Root Cause: The `/doc` endpoint iterates over all records in `ir.model`. For each record, it attempts to resolve the Python class using `self.env[ir_model.model]` to check access rights. If a model exists in the database with `state='base'`, Odoo expects it to be defined in the Python source code and does not generate it dynamically. If the corresponding Python class is missing (e.g., from an old module), it is never added to the registry, causing the lookup to fail with a `KeyError`. opw-5401782 Forward-Port-Of: odoo/odoo#241483
This update fixes an issue where employee names were being incorrectly formatted in payroll reports. The change ensures that employee names are consistently displayed as 'First Name Last Name,' aligning with Swiss regulations and improving data accuracy. This resolves a previous reporting error and enhances the reliability of payroll information.
Original PR description
* Fix _compute_l10n_ch_legal_name method to correctly assign first_name and last_name from employee name (was previously reversed) * Update all SwissDEC test data to use correct "FirstName LastName" format instead of "LastName FirstName" to match the corrected computation logic task-5102851 Forward-Port-Of: odoo/enterprise#104067 Forward-Port-Of: odoo/enterprise#95252
This update fixes an issue where changing the rental period of an order didn't automatically update the associated rental transfers. The fix mimics the rescheduling behavior of purchase orders, ensuring that rental transfers are accurately reflected after a rental period adjustment. This improves the reliability of rental order management.
Original PR description
### Steps to reproduce: - In the settings enable "Rental Transfers" - Create a storable and rentable product P - Create and confirm a rental order for 1 unit of P - Change the rental period to 10 days in the future #### > The rental tranfers were not updated accordingly ### Cause of the issue: Nothing is currently implemented to reschedule the rental transfers. ### Fix: We somewhat mimic the reschedule purchase behavior: https://github.com/odoo/odoo/blob/6ca34a0f5347e0611cde95453119dda8b40fa589/addons/purchase_stock/models/purchase_order_line.py#L98-L101 But we rely on the order itself rather than its order lines since the `start_date` and the `return_date` are related fields so that no `write` is triggered when the order is rescheduled: https://github.com/odoo/enterprise/blob/96a80f583a0ca502ff06bc05d03775c76c6a7537/sale_renting/models/sale_order_line.py#L18-L19 opw-5158508 Forward-Port-Of: odoo/enterprise#103602 Forward-Port-Of: odoo/enterprise#101334
This update removes unnecessary integer rounding from monthly Italian VAT reports. Previously, rounding was incorrectly applied, causing discrepancies in reporting. This change ensures accurate and consistent monthly VAT reporting for Italian businesses using Odoo.
Original PR description
**Description of the issue/feature this PR addresses**: Integer rounding is only required on annual l10n_it VAT reports. It appears that it was incorrectly added to the monthly report when the two were split in #193662. **Current behavior before PR**: Integer rounding on monthly l10n_it tax reports. **Desired behavior after PR is merged**: No more integer rounding on monthly l10n_it tax reports. [opw-5292310](https://www.odoo.com/odoo/project.task/project.task/5292310) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244389 Forward-Port-Of: odoo/odoo#243100
This update removes unnecessary integer rounding from the monthly Italian VAT reports. The rounding, which was incorrectly applied due to a previous split of reporting functionality, has been corrected. This ensures accurate VAT reporting for Italian businesses using the Enterprise module.
Original PR description
Integer rounding is only required on annual l10n_it VAT reports. It appears that it was incorrectly added to the monthly report when the two were split in [#193662](https://github.com/odoo/odoo/pull/193662). [opw-5292310](https://www.odoo.com/odoo/project.task/project.task/5292310) Forward-Port-Of: odoo/enterprise#104679 Forward-Port-Of: odoo/enterprise#103852
This update resolves an issue that prevented upgrading the HR module after deleting overtime rules. The fix disables a constraint that caused errors during upgrades, ensuring smoother module updates and preventing disruptions to attendance management. This improves stability and reduces potential upgrade complications.
Original PR description
**Steps to reproduce** - Install `hr_work_entry_attendance` - Delete one of the overtime rules from the "Default Ruleset", e.g. "Employee Schedule Rule" - Upgrade the `hr` module - Traceback: `psycopg2.errors.CheckViolation: new row for relation "hr_attendance_overtime_rule" violates check constraint "hr_attendance_overtime_rule_if_paid_work_entry_type_defined"` **Cause** The `_if_paid_work_entry_type_defined` constraint added by the `hr_work_entry_attendance` module on overtime rule records will fail when re-creating an overtime rule record when upgrading another module than `hr_work_entry_attendance`, since the module is not loaded and we don't get a default value for the `work_entry_type_id` field. **Fix** Since the ORM cannot manage that, disable forcecreate for these records. Related: https://github.com/odoo/enterprise/commit/f935e62bae7f204ea3f6db8f08b173bdf011c0d2 opw-5428542 Forward-Port-Of: odoo/odoo#244333
This update addresses several minor bugs and performance improvements within the o_spreadsheet component. It includes fixes related to data export, cell alignment, and spreadsheet evaluation, ensuring a smoother and more reliable spreadsheet experience for users. The changes enhance the overall stability and efficiency of the spreadsheet functionality.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/ceae12a2c7 [REL] 19.1.4 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/ceae12a2c7 [REL] 19.1.4 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/2c591c567a [IMP] xlsx: export clip [Task: 5368130](https://www.odoo.com/odoo/2328/tasks/5368130) https://github.com/odoo/o-spreadsheet/commit/9d219632d5 [IMP] export: export align left when the cell content is a number; [Task: 5368130](https://www.odoo.com/odoo/2328/tasks/5368130) https://github.com/odoo/o-spreadsheet/commit/d19cfe01d6 [PERF] evaluation: fast predicate path for empty strings [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/5a50436e1e [FIX] range: add result changeType [Task: 5095364](https://www.odoo.com/odoo/2328/tasks/5095364) https://github.com/odoo/o-spreadsheet/commit/a03d6a506f [FIX] range: adapt string XC on sheet rename [Task: 5095364](https://www.odoo.com/odoo/2328/tasks/5095364) https://github.com/odoo/o-spreadsheet/commit/2507cde16d [FIX] range: rename parameter [Task: 5095364](https://www.odoo.com/odoo/2328/tasks/5095364) https://github.com/odoo/o-spreadsheet/commit/1d76d8a84a [FIX] range: add range to NONE [Task: 5095364](https://www.odoo.com/odoo/2328/tasks/5095364) https://github.com/odoo/o-spreadsheet/commit/c823920117 [FIX] Actions: ensure the sequence is applied on action children [Task: 5452669](https://www.odoo.com/odoo/2328/tasks/5452669) https://github.com/odoo/o-spreadsheet/commit/748c536d03 [FIX] helpers: export chart check type from runtime config [Task: 5446988](https://www.odoo.com/odoo/2328/tasks/5446988) https://github.com/odoo/o-spreadsheet/commit/5019c8bf33 [PERF] evaluation: don't spread single element matrix [Task: 5491138](https://www.odoo.com/odoo/2328/tasks/5491138) https://github.com/odoo/o-spreadsheet/commit/45609432a1 [FIX] evaluation: remove spread relation [Task: 5491138](https://www.odoo.com/odoo/2328/tasks/5491138) https://github.com/odoo/o-spreadsheet/commit/806aa67d31 [FIX] composer: prevent autocomplete from closing on grid icon drag [Task: 5392156](https://www.odoo.com/odoo/2328/tasks/5392156) https://github.com/odoo/o-spreadsheet/commit/eb5b04a454 [FIX] vectorization: fix error message on size mismatch [Task: 5331324](https://www.odoo.com/odoo/2328/tasks/5331324) https://github.com/odoo/o-spreadsheet/commit/4c021d2564 [FIX] chart: ignore NoChanges in gauge/scorecard side panel errors [Task: 5478288](https://www.odoo.com/odoo/2328/tasks/5478288) https://github.com/odoo/o-spreadsheet/commit/849d2dec16 [FIX] header_size: wrong row size from wrapped number [Task: 4878338](https://www.odoo.com/odoo/2328/tasks/4878338) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update resolves a technical issue within the Odoo spreadsheet plugin, specifically impacting the quality control and sales management modules. The change adjusts arguments used in a key function, ensuring the spreadsheet correctly processes data and improves overall plugin performance. This ensures accurate data synchronization within these core business processes.
Original PR description
…s args See https://github.com/odoo/o-spreadsheet/commit/6533266efa Task: 5095364
This update fixes a critical issue with how strings are processed in Odoo's web framework, ensuring accurate template rendering and test results. The changes also streamline translation management and improve code clarity, leading to more reliable and maintainable applications.
Original PR description
### [[FIX] web: cleanup string-related utils](https://github.com/odoo/odoo/pull/241068/changes) This commit cleans up several utility files relating to string-parsing and translations. Main changes…
### [[FIX] web: cleanup string-related utils](https://github.com/odoo/odoo/pull/241068/changes) This commit cleans up several utility files relating to string-parsing and translations. Main changes are: - fixed `sprintf` and related functions: before this commmit, string substitutions were incorrectly inserted in the template string, and it was actually reflected in a test (template : `"<p>%s</p>%s"` => test incorrectly asserted that both strings were inserted in the first "%s" and "undefined" was inserted in the second); - to replicate the Python homonymous behaviour: "%s" characters can now be escaped in "sprintf-ed" strings by adding an additional "%" sign before the expression; - unification of translations via a TranslatedString class (which will also simplify external overrides); - unified API for some utility functions sharing the same purpose (typically: accepting an iterable instead of a list, etc.); - filling missing docstring, re-ordering functions and constants for clarity; - added "headless" tag to some utility functions' tests, when UI is not needed. Enterprise: https://github.com/odoo/enterprise/pull/104939 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241068
This update resolves a stability issue in the IoT testing environment. The test previously relied on an internal detail of the translation system, which could cause failures. Now, translations are fully loaded into the test, ensuring reliable and consistent results.
Original PR description
Before this commit, a test in iot was looking at the 'values' key of a LazyTranslatedString to make an assertion. This is not robust, as this is an implementation detail internal to the translation system. To fix this, the translations have been "allowed" (i.e. loaded) in the test, ensuring that the returned value is a string and not a lazy-translated string. Community: https://github.com/odoo/odoo/pull/244588
This update fixes an issue where product standard prices weren't correctly converted to the Point of Sale currency, leading to incorrect pricing calculations when using pricelists. The fix ensures all product prices are consistently converted, guaranteeing accurate pricing in the PoS system and preventing pricing discrepancies.
Original PR description
The standard price of the products were not converted to the currency of the PoS journal, which could lead to issues when creating pricelist items based on the standard price. Steps to reproduce: ------------------- * Change the currency of any PoS journal to a different currency than the company currency. * Create a product with a standard price > 0. * Create a pricelist that uses the standard price as a base price. (e.g. price = standard price * 2) * Add this product to a PoS order > Observation: The price is not correctly computed according to the pricelist, because the standard price was not converted to the PoS currency. Why the fix: ------------ We just make sure to convert the standard price of the products when loading the products in the PoS session the same way as we do it for the list price. opw-5124388 Forward-Port-Of: odoo/odoo#244147 Forward-Port-Of: odoo/odoo#241168
This update resolves an issue where customizing the 'Sales: Order Confirmation' email template would trigger a validation error if the 'website_sale' module wasn't installed. The fix ensures the template handles missing 'website_id' fields safely, preventing crashes and allowing users to customize this key sales communication without requiring the additional module.
Original PR description
**Issue** When customizing the *Sales: Order Confirmation* mail template, a validation error appeared if the `website_sale` module was not installed. **Steps to Reproduce** 1. Go to *Settings → Technical → Email Templates* 2. Open *Sales: Order Confirmation* 3. Make inline changes and save each time → A validation error is raised. **Root Cause** The template referenced `website_id` on `sale.order`, which only exists when the `website_sale` module is installed. QWeb pre-evaluates expressions inside `<t t-if="...">` blocks, so even with `hasattr(object, 'website_id')`, the engine still tried to access `object.website_id`, causing the crash. **Fix** Guard all `website_id` usages with explicit checks: `hasattr(object, 'website_id') and object.website_id`, ensuring safe evaluation when the field is missing. opw-5180725 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233825
This update fixes an issue where the VAT summary report for Argentinian invoices was incorrectly calculating totals when multiple IIBB taxes were applied. The fix ensures that VAT amounts are counted accurately, matching the totals displayed in the accounting form, resolving an inflated total calculation.
Original PR description
**Issue** When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is…
**Issue** When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is counted multiple times, once for each IIBB tax, leading to an inflated total. **Steps to Reproduce** 1. Install the Accounting app and the Argentinian localization (l10n_ar) 2. Set the 21% VAT Purchase tax as Included in Price 3. Create a vendor bill applying the 21% VAT tax and at least two IIBB taxes 4. Open the VAT summary report for that bill Expected Behaviour: The total in the VAT summary should match the total shown in the accounting form view, with each tax counted only once. **Root Cause** The VAT summary report in the Argentinian localization relies on an SQL query to aggregate tax information for each `account.move`. The query joins `account_move_line` with `account_tax`, `account_tax_group`, and the many-to-many relation table `account_move_line_account_tax_rel`. Each `account_move_line` related to a VAT tax line (via `tax_line_id`) is joined with the `account_move_line_account_tax_rel` table. If that base line is related to multiple IIBB taxes, the join multiplies the VAT line once per IIBB tax since multiple matching rows exist. **Fix** The solution separates the logic for computing tax lines and base lines into two distinct subqueries. Each is aggregated independently to prevent duplication caused by one-to-many and many-to-many joins. The results are then joined using the unique `account_move_line.id`, ensuring each tax amount is counted exactly once in the final totals. opw-4776861 Forward-Port-Of: odoo/enterprise#98933 Forward-Port-Of: odoo/enterprise#85873
This update resolves a technical issue that was preventing the employee version timeline from automatically saving. The fix involved updating the test code to use a reliable time freezing method, ensuring data is saved correctly. This improves the stability and reliability of the employee version timeline feature.
Original PR description
As runbot faketimes test fail because the usage of dynamic dates now the test uses freeze_time Task#5717031 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244540
This update resolves an issue where clicking links within the Odoo chat window on mobile devices would cause the window to remain open and block the new page from being visible. The fix automatically folds the chat window after a link click, ensuring users can seamlessly access the linked page. This enhances usability and prevents a frustrating user experience.
Original PR description
Clicking on an odoo link in the chat window will take the user to the related page in odoo. However, in mobile view, the chat window remains unfolded and covers the entire page, so the user can't see the newly opened page below the chat window unless they fold the chat window. This change fixes this by folding the chat window in mobile view when clicking an odoo link inside the chat window. task-4762503 Forward-Port-Of: odoo/odoo#244549 Forward-Port-Of: odoo/odoo#208440
Features or functions removed from Odoo
This pull request removes a no-longer-used folder within the Odoo Enterprise software. The folder, related to Indonesian tax reporting ('l10n_in'), was identified as inactive and has been removed to streamline the codebase. This change improves the overall efficiency of the system.
Original PR description
ref - https://github.com/odoo/enterprise/commit/ea7893a978c408e5d4437070ae7a6c7a7fbf7167 Forward-Port-Of: odoo/enterprise#104882