Daily updates from Odoo
Tuesday, March 3, 2026
51 changes · saas-19.1
Enhancements to existing features
This update enhances the Odoo system's ability to identify and correct issues with internationalized text. Specifically, the documentation for two error codes (E8502 and E8505) has been clarified with examples, making it easier for developers to ensure accurate translations and a consistent user experience across different languages.
Original PR description
- Update documentation link for E8502. - Clarify why E8505 is in place and give an example. Forward-Port-Of: odoo/odoo#251444
This update ensures the IEPS tax breakdown is correctly displayed on Mexican CFDI invoices, aligning with SAT regulations. Specifically, it now accurately shows IEPS based on whether the invoice is a 'global invoice' or uses tax object 07, resolving inconsistencies in previous behavior.
Original PR description
This commit targets to modify the behaviour of IEPS breakdown on CFDI to follow on what is specified on SAT cfdi Tax Object Catalog. Now the IEPS will be displayed only considering if the CFDI is a global invoice, the value of the tax object and whether the check is set. The general idea is: - Is a global invoice? -> show IEPS - Is tax object 07? -> show IEPS - Has ieps breakdown but is not tax object 08? -> show IEPS - Anything else, don't. task-5953499 target: saas-18.4 -> master Forward-Port-Of: odoo/enterprise#108555
Resolved issues and error corrections
This update resolves an issue where the system wasn't properly validating DIAN invoice settings. Specifically, if the DIAN operation mode doesn't match the company's configuration, a warning is now displayed to prevent incorrect invoice generation. This ensures compliance with Colombian regulations.
Original PR description
Steps to reproduce: - Install `l10n_co_dian` module(demo data) > Switch to `CO Company` - Settings > Colombian Electronic Invoicing > Change the Operation Mode: `DIAN 2.1: Support Documents`(eg:…
Steps to reproduce:
- Install `l10n_co_dian` module(demo data) > Switch to `CO Company`
- Settings > Colombian Electronic Invoicing > Change the Operation Mode: `DIAN 2.1: Support Documents`(eg: [Image](https://www.awesomescreenshot.com/image/58874464?key=0cb74e446dcdb0f087df6ed619f785c2))
- Vendors > Create a Bill > Confirm > `Acknowledge Reception`
Traceback:
```py
File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_move.py", line 293, in l10n_co_dian_send_event_update_status_received
self._l10n_co_dian_send_event_update_status('received')
File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_move.py", line 313, in _l10n_co_dian_send_event_update_status
document = self.env['l10n_co_dian.document']._send_commercial_event(self, commercial_state_next)
File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/l10n_co_dian_document.py", line 593, in _send_commercial_event
xml, errors = self.env['account.edi.xml.ubl_dian']._export_co_send_event_update_status_invoice(locked_move, commercial_state_next)
File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_edi_xml_ubl_dian.py", line 1208, in _export_co_send_event_update_status_invoice
return self.with_context(l10n_co_next_commercial_state=next_commercial_state)._dian_sign_xml(xml, invoice)
File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_edi_xml_ubl_dian.py", line 1524, in _dian_sign_xml
'software_security_code': self._dian_get_security_code(operation_mode, document_number),
File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_edi_xml_ubl_dian.py", line 1443, in _dian_get_security_code
operation_mode.dian_software_id
TypeError: unsupported operand type(s) for +: 'int' and 'str'
```
We are getting this error because `_dian_get_operation_mode` [returns] an empty `l10n_co_dian.operation_mode()` record. This happens when the `Operation modes` do not match. As a result, [operation_mode] also contains an empty record.
[operation_mode]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1432
[returns]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1394-L1400
sentry-7273771732
Forward-Port-Of: odoo/enterprise#107885This update resolves an issue where the 'Reset Selected Work Entries' button in the HR work entry Gantt view would fail if no employees were selected. The fix ensures the button functions correctly, preventing a data error related to missing employee IDs. This improves the reliability of the work entry management process.
Original PR description
This error occurs when clicking the `Reset Selected Work Entries` button while there are no employees in the work entries. Steps to reproduce: - Install `hr_payroll` module - Payroll > Work Entry >…
This error occurs when clicking the `Reset Selected Work Entries` button while there are no employees in the work entries. Steps to reproduce: - Install `hr_payroll` module - Payroll > Work Entry > Remove `Active` Filter - Select any cell and click on the reset button Traceback: `KeyError: 'employee_id'` This error occurs when the `Reset Selected Work Entries` button is clicked without an employee, causing `employee_id` to be missing at [1]. Solutions: - Raise a validation error when no employee is selected and the `Reset Selected Work Entries` button is clicked. - Fix the error that occurs when clicking the `Set` button to add or replace a work entry. - Fix the error that occurs when the `Active` filter is enabled and the `Reset` button is clicked. ``` Missing Record Record does not exist or has been deleted. (Record: hr.employee(2,), User: 2) ``` [1]: https://github.com/odoo/odoo/blob/4949a6272691c781d5ab5a8b06f88f58d5cea4df/addons/hr_work_entry/wizard/hr_work_entry_regeneration_wizard.py#L116 sentry-7140947833 Forward-Port-Of: odoo/enterprise#103162
This update resolves a test issue caused by relying on a real delay in the website URL picker. The fix now uses a controlled time advance within the test to ensure consistent results and prevent unpredictable test failures. This improves the reliability of our website functionality.
Original PR description
Issue: The websiteUrlPicker input has a 250ms debounce. The test was relying on a real 250ms delay to wait it out, creating a race condition that caused non-deterministic failures. Fix: The test now uses `advanceTime()` to advance the time to past the debounce. runbot-[241087](https://runbot.odoo.com/odoo/runbot.build.error/241087) Forward-Port-Of: odoo/odoo#251199
This update fixes a visual inconsistency in the discuss app and control panel during dark mode. The background colors for breadcrumbs and navbar buttons were previously mismatched, now they are synchronized for a more polished and professional user experience. This ensures a consistent look and feel across the Odoo platform.
Original PR description
The background color of navbar buttons and breadcrumbs in discuss app differed from that of control panel. This PR aligns and syncs these colors for a consistent UI. | Before | After | |--------|-------| |<img width="467" height="99" alt="image" src="https://github.com/user-attachments/assets/2def30f8-18aa-4399-a5d1-1cdc70b4cd81" /> |<img width="458" height="111" alt="image" src="https://github.com/user-attachments/assets/5578cd25-7686-4543-a8dc-3e0fe5aeb4fc" />| This PR contains backport of #217608 task-[4936733](https://www.odoo.com/odoo/project/1519/tasks/4936733) task-[5487197](https://www.odoo.com/odoo/project/1519/tasks/5487197) Forward-Port-Of: odoo/odoo#251360 Forward-Port-Of: odoo/odoo#250601
This update resolves an issue where posting a 'Miscellaneous' journal entry in the Chilean localization resulted in a validation error related to document numbers. The fix exempts these specific journal entries from the numeric folio validation rule, ensuring users can correctly modify and save them. This improves usability for Chilean accounting operations.
Original PR description
Currently, editing a posted `miscellaneous` journal entry in Chile localization incorrectly raises a validation error. **Steps to reproduce:** - Install the `l10n_cl` module and switch to the `CL…
Currently, editing a posted `miscellaneous` journal entry in Chile localization incorrectly raises a validation error. **Steps to reproduce:** - Install the `l10n_cl` module and switch to the `CL company`. - Go to Accounting > Accounting > Journal Entries. - Create a balanced entry using the `Miscellaneous journal `and `post` it. - Reset it to draft, modify the `name`, and try to `save` it. **Observation:** `Validation error`: `The DTE document number (folio) must contain only digits.` **Root cause:** At [1], the constraint validation is applied to all journal entries in Chilean companies, including `miscellaneous` journals. However, `miscellaneous journals (move_type = 'entry')` are not linked to Chilean electronic documents, so the numeric folio validation should not apply to them. **Fix:** This commit ensures that the validation is not raised for `miscellaneous` journal types by excluding miscellaneous journals from the numeric folio validation constraint. [1]: https://github.com/odoo/odoo/blob/f39785bcddd1eb5b7fb503d053c9bb66e2a0f15c/addons/l10n_cl/models/account_move.py#L20-L30 opw-5926773 Forward-Port-Of: odoo/odoo#248965
This update simplifies the salary configuration process by hiding temporary salary simulation offers from the user interface. These offers are automatically removed after a month by a scheduled task, so this change focuses on preventing user confusion and a cleaner experience. It ensures users only see relevant salary options.
Original PR description
The salary simulator creates temporary offers to compute salary configurations. These offers must still exist for backend computations, as the configurator relies on them when updating results. Simulation offers are already cleaned up by a cron job after one month, so this change simply hides them from the list view to avoid user confusion. task: 5498873 Forward-Port-Of: odoo/enterprise#107340
A technical issue preventing payrun creation for Hong Kong employees has been fixed. The problem stemmed from a missing function name within the HK localization, which caused errors during payrun generation. This update ensures payruns for Hong Kong employees now function correctly.
Original PR description
In the big commit adding eMPF to the hk localization, a function was miss named and was causing an error when trying to create a payrun. Steps to reproduce: - Install belgian localization - Install HK localization - Select the belgian company - Create a payslip for a belgian employee (works fine) - Create a payrun and select the same employee from the list - Get an error In this commit we fix the naming of the function and everything goes back to working. Task: 5960503 Forward-Port-Of: odoo/enterprise#109196
A recent update to the website's image gallery introduced a bug where clicking images would cause an error. This fix addresses a technical issue related to how image pop-ups are handled, ensuring the gallery slider functions correctly and reliably. This resolves a reported customer issue and improves the overall user experience.
Original PR description
From version 19.1, a new image pop-up functionality was introduced. Now, when an image is added to the website, and the pop-up image option is enabled, Clicking the image raises a traceback. To…
From version 19.1, a new image pop-up functionality was introduced. Now, when an image is added to the website, and the pop-up image option is enabled, Clicking the image raises a traceback. To reproduce the issue: - Connect to a saas~19.1 runbot, - open the website module, and enter edit mode. - Add an image, click it, and enable the pop-up image option. - Save the changes. - Clicking the image will display the pop-up, but a traceback will appear behind it. <img width="1920" height="931" alt="Home-Odoo-02-25-2026_05_43_PM" src="https://github.com/user-attachments/assets/73662dc7-cf0e-4246-b6cd-685c758fb4d7" /> This change reintroduces the check because `this.liEls` can be undefined when only one image is added, which was causing errors when the length check was performed without it. <img width="240" height="53" alt="2026-02-25_17-45" src="https://github.com/user-attachments/assets/daea05a4-3fc9-4208-aaa6-345bd62c27c6" /> [opw-5973719](https://www.odoo.com/odoo/project/974/tasks/5973719?debug=1) Customer reported issue [here](https://www.odoo.com/odoo/project/70/tasks/5962120?debug=1) 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
This update resolves a technical issue in the Hungarian tax audit export process. Previously, changes to invoice data were unintentionally saved to the database, despite attempts to roll them back. By ensuring the cache is flushed before and after savepoints, this fix prevents incorrect data updates and maintains data integrity.
Original PR description
At the moment, the Hungarian tax audit export wizard's `action_export` creates a savepoint with `flush=False`. The intention of this savepoint is to roll back the changes to `l10n_hu_edi_invoice_chain` once the savepoint exits. But because the changes to `l10n_hu_edi_invoice_chain` stay in cache, and the cache is not flushed before the savepoint is created nor cleared afterwards, those changes end up being committed to DB. Which is precisely what the savepoint was there to prevent. Solution: we use `flush=True` to make sure the cache is flushed before and cleared after the savepoint. task-none Forward-Port-Of: odoo/odoo#251322 Forward-Port-Of: odoo/odoo#250971
This update fixes an issue where the lot number for products tracked by lot wasn't consistently displayed in POS sales orders. The fix ensures that the correct lot number is accurately reflected for all product lines within the order, improving inventory accuracy during point-of-sale transactions. It also addresses a related issue with quantity processing during POS closing.
Original PR description
When opening an SO in POS that has a product tracked by lot that is split into several location, the lot number will only appear in one of the line and not the others Steps to reproduce:…
When opening an SO in POS that has a product tracked by lot that is split into several location, the lot number will only appear in one of the line and not the others Steps to reproduce: ------------------- 1. Create a Product A tracked by lot, create lot 111 and add 1 unit to location A and another one to location B 1. Create a sales order 2. Add two units of the product to the sale order 3. Confirm the sales order 4. Open the transfer, make the transfer retrieve the product from several location with the same lot. 5. Save the transfer 6. Open the sales order in POS 7. Load the SN/lots -> Two line of qty 1 appear for the product A but only the first one has the lot number Additional Issue: 8. Change the number of the product for the first line to 2 and erase the second line 9. Confirm and Pay 10. Close POS 11. Open move lines for this product (Inventory>product>In/out) -> It moves 2 product from one location (when there is only product) Observation: ------------- When loading the SO in POS, we will retrieve the SO: https://github.com/odoo/odoo/blob/cb1f5d9c6db64b9ace9b7aa46bd6f94e4462176b/addons/pos_sale/static/src/app/order_management_screen/sale_order_management_screen/sale_order_management_screen.js#L104 While retrieving the SO, we will also retrieve the SOL, with additional information: https://github.com/odoo/odoo/blob/d9b2e5ee730a4e79586bfd3f09adfb794d2dc1f3/addons/pos_sale/models/sale_order.py#L79 -> Issue is that when several moves_line have the sale lot_id.name, their quantity will be overwritten. Addition Issue : When closing pos, all the move will be processed, when processing those moves, the origin only check if the quantity is more than 0 and not if there is enought units. https://github.com/odoo/odoo/blob/cb1f5d9c6db64b9ace9b7aa46bd6f94e4462176b/addons/point_of_sale/models/stock_picking.py#L293-L297 opw-5347992 Forward-Port-Of: odoo/odoo#251270 Forward-Port-Of: odoo/odoo#243347
This update prevents the 'Custom Url' field in the website SEO settings from appearing when a page doesn't have a URL segment that can be edited. Previously, this field incorrectly displayed, leading to confusion. This change ensures a cleaner user experience and avoids unnecessary steps for users managing website URLs.
Original PR description
This PR hides the "Custom Url" field in the "Search Engine Optimization" when the URL of the current page do not contain any editable slug. Previously, this field could be filled when the URL did not…
This PR hides the "Custom Url" field in the "Search Engine Optimization" when the URL of the current page do not contain any editable slug. Previously, this field could be filled when the URL did not contain any modifiable slug. However, the value was not take into account since the route of the page did not expect slug. Reproduce: With an admin user, activate the website editor on an appointment page. Clicking on "Optimize SEO" in the "Site" dropdown menu, a form containing the "Cutsom Url" field is displayed. This field should represent the current page's URL but with fillable field instead of the editable URL part. In this case, this is not correct as the URL is repeated before and after the fillable field, which does not represent the current URL. Also, the URL is not modified with the value entered in the fillable field. After the fix: The "Custom Url" field must not be displayed when URL does not contain a customisable slug. Task-5114394 Forward-Port-Of: odoo/odoo#251294 Forward-Port-Of: odoo/odoo#231609
This update fixes an issue where the VAT exigibility mention was incorrectly shown on French invoices. The change ensures the mention appears only when required by French tax regulations – specifically, when a service VAT uses invoice-based tax exigibility, aligning with standard accounting practices.
Original PR description
The VAT exigibility mention on French invoices was incorrectly displayed. - For goods, VAT on debits is the default regime, therefore the mention is not mandatory and must not be shown. - For services, VAT is normally due on payment. The mention “TVA payée sur les débits” must be displayed only when a service VAT uses tax exigibility based on invoice. This commit updates the logic to display the mention only in this specific case and omits it otherwise. Task:5418502 Forward-Port-Of: odoo/odoo#248588
This update fixes a technical issue with the API documentation tooltips in Odoo. The changes ensure tooltips are properly aligned, hide correctly, and prevent empty content from appearing, resulting in a cleaner and more user-friendly documentation experience.
Original PR description
In api_doc, the method parameters tooltips were broken. This commit fixes them by: - aligning the text to the left - improving the hideTooltip behavior - preventing `undefined` tooltip content from being displayed task-5246075 Forward-Port-Of: odoo/odoo#248289
This update corrects a problem with how VAT tax schemes are calculated for Romanian customers. Previously, an empty company registry caused errors. The fix re-introduces the necessary logic to correctly determine VAT/non-EU VAT for Romanian invoices, ensuring accurate tax reporting.
Original PR description
Problem --------- If the customer has not VAT set up on it record, we use the DEFAULT_VAT value. However, the scheme to be used is computed using the partner company_registry (which might be empty), which fails. Secondly, the piece of logic that compute the VAT/NON_EU_VAT for the Tax Scheme node was removed during the refactor. However, this is needed in Romania. Solution --------- Compute the scheme using the DEFAULT_VAT and add back the VAT/NON_EU_VAT logic for the Romanian CIUSRO only. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251058 Forward-Port-Of: odoo/odoo#250110
This update fixes an issue where loyalty rewards disappeared from orders when loaded back through the TicketScreen. Previously, the system didn't properly refresh loyalty state after switching tables. Now, rewards are consistently applied when an order is loaded from the Orders tab, ensuring accurate reward tracking for customers.
Original PR description
Reward disappeared from an order when it was loaded from the Orders tab (TicketScreen) in restaurant mode after working on other tables. Steps to reproduce: ------------------- * Configure a Buy X Get Y (or similar) loyalty program and open a POS restaurant session. * On table A, create an order that triggers the program and confirm the reward line is applied. * Leave table A, create or edit another order on a different table (so another order becomes current). * Go to the Orders tab (TicketScreen), select the order from table A and click "Load Order". > Observation: The order from table A is loaded without its reward line, even though it was present when the order was first created. Why the fix: ------------ TicketScreen’s "Load Order" flow was only switching the current order without refreshing loyalty state, so after changing tables and coming back, later loyalty recomputations could drop the existing reward lines. opw-5909899 Forward-Port-Of: odoo/odoo#248000
This update resolves an issue where the system wasn't properly tracking its state during background processing for Nemhandel (the Danish payment system) within the l10n_dk module. This fix ensures accurate payment processing and reporting for Danish businesses using this integration. It's a critical update for compliance and reliable financial transactions.
Original PR description
State is not being correctly managed in case of background processing. task-5963885 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251219
This update fixes a visual issue where group names in grouped list views were being cropped due to incorrect column spanning. The change ensures group names have sufficient space, improving readability and the overall user experience. This resolves a minor aesthetic problem without impacting functionality.
Original PR description
Have a grouped list view with no aggregate fields. Before this commit, the colspan of the first `th` in group header rows wasn't optimally computed. These `th` can span to the very last cell…
Have a grouped list view with no aggregate fields. Before this commit, the colspan of the first `th` in group header rows wasn't optimally computed. These `th` can span to the very last cell (excluded), which may contain a cog menu. However, they only spanned to the second to last cell. As a consequence, in a list with only 2 columns, e.g. a handle and a name, the groups' name only got a few px available, and were hence cropped. The issue came from successive reworks of the group header row, leading to the pager being finally moved from its own column (after the last aggregate column), to the group name cell (with ms-auto). The logic is easier now, as a group header row looks like this: - a single `<th colspan="n">` (n >= 1) to display the group name: spans to the first aggregate column excluded or to the last cell excluded if no aggregate (colspan + 1 if rows have selectors) - one `<th colspan="1">` for each aggregate column - optionally one `<th colspan="m">` (m >= 1) for all columns after the last aggregate column - a single `<th colspan="1">` for the potential cog menu (optional dropdown column) opw~5730396 Before <img width="1918" height="471" alt="image" src="https://github.com/user-attachments/assets/8f55322b-1603-42cc-a48b-a2010ff12e25" /> After <img width="1909" height="423" alt="image" src="https://github.com/user-attachments/assets/0bca4865-88a1-424d-a1af-1523dbfa911c" /> Forward-Port-Of: odoo/odoo#251411
This update resolves an issue where the search bar on iOS devices with Korean keyboards would incorrectly clear the input while typing. The fix introduces a brief delay to account for iOS's IME behavior, ensuring the autocomplete remains open during Korean character composition. This improves the user experience for international customers.
Original PR description
Safari does not reliably set `KeyboardEvent.isComposing` during IME composition (e.g. Korean). As a result, the search value was processed too early and got cleared while composition was still in…
Safari does not reliably set `KeyboardEvent.isComposing` during IME composition (e.g. Korean). As a result, the search value was processed too early and got cleared while composition was still in progress. Interestingly, the issue could not be reproduced with the Japanese keyboard, which appeared to behave correctly. See [1]. This commit introduces a short delay before closing the autocomplete. On iOS, the IME temporarily triggers a Backspace event to remove the previously composed character before inserting the updated one. This Backspace incorrectly causes the autocomplete to close. With this change, we wait briefly (10ms) before closing it. If a new input event is received during that delay (corresponding to the newly composed character generated by the IME), the close action is cancelled. This ensures that the autocomplete remains open while the IME composition process completes. Steps to reproduce: - Configure a Korean keyboard on an iPhone - Open a Sale Order - Focus the search bar - Type a character, then type a second one to combine them - The search input value gets reset [1] #222151 opw-5448385 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#251141
This update fixes a problem where archived employee appraisal dates persisted, causing conflicts when managing appraisal plans. The change ensures that archived employees no longer appear in appraisal date calculations, preventing errors and ensuring accurate appraisal plan management within the system. This improves the stability and usability of the HR appraisal feature.
Original PR description
**Steps to reproduce:** Based on this feedback https://www.odoo.com/odoo/project.task/5270281 companies with archived employees face an issue when they try to toggle Appraisals Plans from Appraisls -> Configuration -> Settings -> Appraisals Plans **Issue:** The propblem is that when employees with next appraisal date are archived, their next appraisal date is not cleared which leads to past date conflicts upon trying to set the next appraisals dates for all the employees (which is done through toggling the Appraisals Plans checkbox) **Solution:** - Unset the next appraisal date upon archiving an employee - exclude archived employees from _compute_next_appraisal_date method Task: 5354002 Forward-Port-Of: odoo/enterprise#109115 Forward-Port-Of: odoo/enterprise#100437
This update corrects a bug where the removal date for products with expiration dates was incorrectly recalculated after modifications. The fix allows users to directly edit the removal date, ensuring accurate tracking of product expiration. This prevents data inconsistencies and improves the reliability of inventory management.
Original PR description
version : saas-18.4+e Steps to reproduce ------------------ Create a product tracked by lots and enable the expiration date use (use_expiration_date = True). Create a receipt with this product and mark it as to do. Open the stock.move.line list view using the "Details" button on the receipt form and try to modify expiration date, it should modify the removal date due to the compute method. Then, try to modify the removal date and save the modifications. If you reopen the list view, the removal date has been computed again and its value changed. The fix ------------------ We explicitly set the readonly field to False for the removal_date field from the stock.move.line model in product_expiry. opw-5368007 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251256 Forward-Port-Of: odoo/odoo#241659
This update corrects a display issue where vendor product names and codes were appearing twice in the delivery receipts for purchase orders. The problem stemmed from a system process adding vendor details to the description field, even when a product description was already defined. This change ensures accurate and consistent vendor information is shown in purchase receipts.
Original PR description
Version : saas-18.4+e Steps to reproduce ------------------ Create a product and add a line in the purchase tab with a “Vendor Product Name” and/or a “Vendor Product Code”. Create a purchase order…
Version : saas-18.4+e Steps to reproduce ------------------ Create a product and add a line in the purchase tab with a “Vendor Product Name” and/or a “Vendor Product Code”. Create a purchase order for this product with the right vendor and confirm it. Go to the delivery receipt, the vendor code and/or name are added twice in the description. Why is it happening ------------------ The _compute_description_picking method from stock.move, which is overridden in purchase_stock module, adds the vendor code and name to the description. However, if no description_picking has been set on the product, the description is already defined as the vendor code and name. Solution ------------------ I propose to remove the code and the name from the vendor_reference variable if the original description already contains them. opw-5392855 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251337 Forward-Port-Of: odoo/odoo#242075
This update resolves an issue preventing users from successfully submitting website forms with manually uploaded files. The fix adds a necessary attribute to the form processing logic, ensuring the file upload is properly recognized and submitted. This improves the functionality of contact forms that create opportunities.
Original PR description
Steps to reproduce: =================== 1. In CRM, use Studio to add a new File field to the lead form. 2. Go to website & Create a contact form that creates an opportunity 3. Add the studio field to the contact form created 4. Fill the form, upload the file and submit. -> An error has occured, the form has not been sent. Cause: ====== After this commit [1], `get_authorized_fields` calls `fields_get` with an explicit attributes list; 'manual' was not included in that list, so it was never returned, which causes the form submission to fail here: https://github.com/odoo/odoo/blob/242afb9ca3a76e3628260ac81a9f5ddcd5d445dd/addons/website/controllers/form.py#L194 Solution: ========= Add 'manual' to the attributes list in fields_get in website_form.py [1]: https://github.com/odoo/odoo/commit/bfae7140d3951bec93fb7f2e49018649045edd40 opw-5933992 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug in the stock barcode testing process. Previously, the tests didn't account for changes made through 'push rules' applied to move lines. Now, the tests accurately reflect how stock barcode functionality works when using move lines, ensuring proper tracking and reporting.
Original PR description
This commit is part of the community PR https://github.com/odoo/odoo/pull/239032. This commit fixes a test after making push rules work on move_lines instead of moves. Task-5212472
This update fixes a persistent warning appearing on payslips after deleting a related one. The fix involves canceling the payslip before deletion and then recomputing duplicate checks. This ensures accurate payroll processing and avoids unnecessary alerts for users.
Original PR description
### Steps to reproduce: - Create two payslips for the same employee for the same period. - Delete one of them; the duplicate warning still appears on the other payslip. ### Fix: - Before deleting a payslip, first cancel it so the current payslip can be skipped while checking for duplicate payslips. - Then trigger recompute _compute_issues for duplicates payslips task: 5427473
This update prevents a crash that occurred when users clicked images with the 'Pop-up on Click' feature in the website builder. The fix ensures that the image gallery functionality works reliably, regardless of whether the image is part of a carousel. Additionally, the popup setting has been restricted to product images.
Original PR description
Steps to produce: --- - Install `website_sale` module. - Go to website > open editor. - Add an image snippet to the homepage. - Click on the image and enable `Pop-up on Click`, then save. - Click on…
Steps to produce:
---
- Install `website_sale` module.
- Go to website > open editor.
- Add an image snippet to the homepage.
- Click on the image and enable `Pop-up on Click`, then save.
- Click on the image.
Traceback:
---
`TypeError: Cannot read properties of undefined (reading 'length')`
Root cause:
---
- In the `setup` method, when the image is not part of a carousel,
the element `.carousel-indicators` does not exist. As a result,
`indicatorEl` is null, and the guarded block(at [1]) is skipped.
Because of this, `this.liEls` is never initialized.
- Later, when the `onSlidCarousel` method is executed,
its internal condition evaluates and find `liEls` as null and
then `hide` method is called(see [2]).
- Inside the `hide` method, the code attempts to iterate
over `this.liEls`(see [3]).
Solution:
---
- Initialized `liEls` in `setup()` to ensure it is always defined.
- Added a length check in `onSlidCarousel()` to execute the logic
only when `liEls.length > 0`.
- This prevents this.page from being computed using invalid
values and avoids it being set to `NaN`.
- Additionally, as requested by the boje(po), hide the popup
on click setting on product images.
**Alternative approaches:**
1. We can also call the `onSlideCarousel` method from `setup`
when multiple images are present.
2. Also, we can add a simple check inside the `onSlideCarousel`
method to ensure that `liEls` is defined before proceeding.
[1]: https://github.com/odoo/odoo/blob/945f44e55f9a67b0744a183200de728b00202b1c/addons/website/static/src/snippets/s_image_gallery/gallery_slider.js#L31-L57
[2]: https://github.com/odoo/odoo/blob/945f44e55f9a67b0744a183200de728b00202b1c/addons/website/static/src/snippets/s_image_gallery/gallery_slider.js#L144-L152
[3]: https://github.com/odoo/odoo/blob/945f44e55f9a67b0744a183200de728b00202b1c/addons/website/static/src/snippets/s_image_gallery/gallery_slider.js#L119-L120
opw-5921123
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where rapidly clicking the 'Back' button during barcode internal transfer creation resulted in duplicated quantities being recorded. The fix prevents multiple 'save' calls, ensuring accurate inventory tracking. This improves the reliability of barcode-based stock transfers.
Original PR description
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By…
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By Quantity** and set some *barcode* * Update the on-hand quantity for the product and assign it to one packages. * Open *Barcode > Operations > Internal Transfer* and create a new transfer. * Click the *gear icon* in the top-right corner to open the barcode scanning flow. * manually enter the created product barcode and apply it. * Click the **Back** button multiple times in quick succession. * Go to the backend and open the created internal transfer. **Observed behavior:** * The internal transfer is created with *double quantities* compared to what was added in the barcode interface. **Cause:** * When clicking the *Back* button, the following flow is triggered: `exit()` → `beforeQuit()` → `save()`. https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/components/main.js#L406-L414 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L473-L475 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_picking_model.js#L828-L832 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L477-L483 * If the button is clicked multiple times rapidly, `exit()` is called again before the previous `save()` RPC completes. * This results in multiple `save()` calls being executed, causing duplicated quantities on the picking. reference - https://github.com/odoo/enterprise/pull/103999/changes/b791239c154deb6a25f85d65ebc72e3ac53b6c74 **Fix:** * Prevent rapidly clicking the Back button multiple times does not multiply quantities. --- opw-5375899 Forward-Port-Of: odoo/enterprise#109013 Forward-Port-Of: odoo/enterprise#103130
This update ensures that B2C customers in Taiwan requesting a paper invoice during guest checkouts correctly skip the 'Invoicing Info' step. Previously, a technical issue caused problems with saving the paper invoice preference. This change improves the checkout experience for Taiwanese customers and ensures compliance with e-invoicing regulations.
Original PR description
In Taiwan e-invoicing, B2C customers can request a paper copy of their invoice. When selected, the "Invoicing Info" step—which collects data like donation codes or carriers—should be skipped as it is…
In Taiwan e-invoicing, B2C customers can request a paper copy of their invoice. When selected, the "Invoicing Info" step—which collects data like donation codes or carriers—should be skipped as it is not applicable to physical copies. Previously, this logic failed during guest checkouts because the partner initially associated with the order is an archived public user. The persistent partner is only created/assigned after the address form is submitted. This commit: - Overrides `_create_or_update_address` instead of `_handle_extra_form_data` to ensure the paper format preference is saved on the correct, newly generated partner. - Updates `_prepare_address_form_values` to correctly load existing preferences from the partner for registered users. - Ensures the `l10n_tw_edi_is_print` flag on the Sales Order stays in sync with the partner's preference. Task-5912985 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247961
This update resolves an issue where planners couldn't see unscheduled shifts for resources with no existing bookings. The fix removes a filtering restriction in the scheduling dialog, ensuring all available shifts are displayed, allowing for more efficient resource allocation. This improves usability for sales and operations teams.
Original PR description
Steps to Reproduce ------------------ 1. Open the Planning Gantt view. 2. Click a cell that belongs to a resource with **no** scheduled shifts. 3. The Plan dialog opens with an empty list. Issue…
Steps to Reproduce ------------------ 1. Open the Planning Gantt view. 2. Click a cell that belongs to a resource with **no** scheduled shifts. 3. The Plan dialog opens with an empty list. Issue ----- A previous change keeps the clicked resource in the dialog context; the Gantt model turns it into a default search filter, so only shifts already linked to that resource are shown. Unassigned shifts are therefore hidden, preventing planners from assigning them by role or availability. Current Behaviour ----------------- The Plan dialog is always filtered by `resource_id`, which returns no results for unscheduled resources, even when they have the right roles. Expected Behaviour ------------------ The dialog should list all unscheduled shifts that match the resource’s roles, or every unscheduled shift if the resource has no roles, while still preserving full context for scheduling once a shift is selected. Fix --- Remove the automatic resource filter from the dialog context in `getSelectCreateDialogProps()`. This prevents the unwanted search restriction; role defaults remain, so the dialog now displays the correct shifts. Task-4922525 Issue – https://github.com/odoo/enterprise/pull/87424/commits/a218a7cedce61f992fbe76284c273be8f937d28d Forward-Port-Of: odoo/enterprise#92100
This update fixes an issue where Point of Sale session messages were consistently displayed in English, regardless of the user's selected language. The fix ensures that all chat messages related to cash transactions are translated accurately based on the user's language preference, improving the user experience for international customers.
Original PR description
**Problem:** When opening or closing a POS session, chatter messages display untranslated English text regardless of the user's language setting. **Steps to reproduce:** 1. Set user language to any non-English language (e.g., Spanish) 2. Open a POS session and register cash in/out operations 3. Close the session 4. Check the chatter messages - labels appear in English **Current behavior:** Messages display in English: "Opening cash difference", "Opening cash expected", "Opening cash counted", "Closing difference", etc. **Expected behavior:** Messages should be translated according to the user's language setting. **Cause of the issue:** The hardcoded strings were not wrapped in the translation function `_()`, preventing them from being translated. **Fix:** Wrap the concatenated strings with `_()` to enable proper translation of all cash details messages. opw-5185310 Forward-Port-Of: odoo/odoo#248982 Forward-Port-Of: odoo/odoo#244501
This update resolves an issue where Avatax taxes weren't being correctly calculated during Stripe Express Checkout, particularly when using Google Pay. The fix ensures that all applicable taxes, including those from Avatax, are accurately reflected in the order total, improving payment accuracy and preventing discrepancies between the displayed price and the final payment amount.
Original PR description
## Versions 17.0+ ## Issue Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes. ## Steps to reproduce…
## Versions
17.0+
## Issue
Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes.
## Steps to reproduce
*Ensure the Stripe account has activated Google Pay* *This requires a complete Google profile on Google Chrome (with a valid payment method)*
- Setup Stripe payment method in test mode with Express Checkout;
- In the Settings, in the Accounting section:
- Setup Avatax;
- Set main Sales/Purchase taxes to 0.
- Create a new product with 0% selling taxes and any Avatax category;
- Activate fiscal position and enable automatic detection;
- Open a Chrome session with the Google profile:
- Go to the shop;
- Add the product you created to the cart;
- Enter the cart;
- Click the "Buy with GPay" button:
- The amount is equal to the sales price excluding taxes.
- Go to the Sales app and open the newly created order:
- The total amount differs from the amount paid (cf. transaction).
opw-5020793
Forward-Port-Of: odoo/enterprise#108957
Forward-Port-Of: odoo/enterprise#101579This update fixes an issue where landed costs weren't correctly applied to subcontracted products, leading to inaccurate product valuations and missing journal entries. The fix ensures that landed costs are properly linked to the subcontracted manufacturing order, resulting in accurate valuation updates and the creation of necessary account move lines.
Original PR description
…bcontracted **Problem:** Landed cost added on the receipt of a subcontracted product do not increase the valuation of the product and do not create account move lines. **Steps to reproduce:** -…
…bcontracted **Problem:** Landed cost added on the receipt of a subcontracted product do not increase the valuation of the product and do not create account move lines. **Steps to reproduce:** - create a tracked product with avco perpetual category - create a subcontracted bom for this product with no comp - create and confirm a PO for 10 unit of this product at a unit price of 1$ with the same partner as the subcontractor of the bom - validate the receipt - navigate to inventory/operations/adjustments/landed costs - create a new landed cost - select the receipt from the PO - add a landed cost of 10$ and validate - navigate to inventory/reporting/stock - search for your product and click on the unit cost **Current behavior:** 1) the valuation of the product was not increased by the value of the landed cost 2) open journal items : no account move lines were created for the landed cost **Expected behavior:** 1) the valuation of the product should have been increased: in the unit cost view, the SBC move should have gone from a value of 10 to 20 2) account move lines should have been created with a value of 10 **Cause of the issue:** both issues come from the fact that when creating the stock valuation adjustment line, the move linked is the receipt move when it should be the move of the subcontracted MO linked to the receipt. **fix:** if we create the adjustement line with move_id as the move of the MO (instead of the move of the receipt as it is the case currently) : when button_validate is called on the landed cost : - when using the remaining quantity, it will be the correct one (in our case 10, instead of 0 for the move of the receipt because it's actually an internal move) so the account move line are going to be created https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_landed_cost.py#L129-L130 https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_landed_cost.py#L372-L373 which solves problem 2) - when calling _set_value on the move (which will be the move of the MO thanks to this fix), https://github.com/odoo/odoo/blob/064407d32f998ceb08601f9e0a6356c94ad10347/addons/stock_landed_costs/models/stock_landed_cost.py#L152 get_value_data will call _get_value_from_extra, https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_account/models/stock_move.py#L392 which uses _get_landed_cost to fetch the landed cost https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_move.py#L18 before this fix the landed cost created from the receipt were linked to the receipt move so they were not fetched inside _get_landed_cost which caused problem 1) but now the move_id of the adjustment lines is the move of the MO so they are fetched inside _get_landed_cost https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_move.py#L7-L12 So now the adjustment lines do impact the valuation of the move of the MO which solves problem 1) opw-5723126 Forward-Port-Of: odoo/odoo#248469
This update fixes a bug where users could cancel subscriptions even if they didn't have access to the associated invoices. Now, a user must view the invoice before they can cancel the subscription, ensuring accurate subscription management and preventing accidental cancellations. This improves data integrity and reduces potential revenue loss.
Original PR description
Before this commit, when a user had access to an invoiced subscription but not to the invoiced, he could cancel the subscription. Step to reproduce: - create a subscription in company A, with a pricelist available in company B. Sales person A belong to company A. - invoice the subscription and confirm the invoice - update the company (company B) and sales person of the subscription (B). The new salesperon don't see the invoice in the stat button. After this commit salesperson B can't cancel the subscription. task-5907345 Forward-Port-Of: odoo/enterprise#108550 Forward-Port-Of: odoo/enterprise#106441
This update addresses a potential issue in the Swiss payroll reporting process. Specifically, it now displays a warning instead of an error when the 'AVS' (Authorized Vendor System) value is negative, providing clearer guidance to users. This ensures accurate reporting and avoids potential disruptions to payroll calculations.
Original PR description
Forward-Port-Of: odoo/enterprise#109046
This update resolves a test failure caused by demo data interfering with the lot search functionality. The fix creates new data and adds safeguards to prevent the test from failing due to existing demo lots. This ensures the test runs reliably and accurately.
Original PR description
The `test_lot_search_partner_ids` expects a specific number of lots/SNs to exist in the database in order to ensure its custom `partner_ids` search works correctly. Because of this, the test fails if any lot demo data is installed. Therefore we create all new locations, products, lots and add extra search domain fields to avoid loading any of these demo data. Also add in extra long partner name to avoid conflicts with overlapping demo/test partner names. runbot error: 162921 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250783 Forward-Port-Of: odoo/odoo#220777
This update resolves a bug that prevented stock quantities from being correctly deleted when their quantity was set to zero, particularly within inventory mode. The fix ensures that the current user isn't incorrectly associated with the quantity, allowing the system to properly remove the record and maintain accurate stock levels. This improves data integrity and prevents potential discrepancies.
Original PR description
Steps to reproduce: - Create a storable product "P1" - Click on Quantity On Hand - Set the quantity to 10 and save - Set the quantity to 0 - Go back to the quant list view by clicking on Quantity On Hand - The quant is deleted by: https://github.com/odoo/odoo/blob/08015c2a15704b30c7815b62612b71b8970e3ac2/addons/stock/models/stock_quant.py#L1076-L1079 - Set the quantity to 10 again and save - Select the quant - Action > Set to 0 Problem: The function `action_set_inventory_quantity_zero` sets the current user on the quant even on inventory mode. This prevents the quant from being deleted when `_unlink_zero_quants` is called. opw-5906681 Forward-Port-Of: odoo/odoo#248881
This update fixes an issue where fiscal positions were incorrectly applied to Brazilian customers, leading to errors when creating tasks. The change ensures that each customer's fiscal position is correctly associated with the company they belong to, resolving inconsistencies and preventing errors.
Original PR description
Issue ===== The fiscal position defined on a partner was not properly isolated per company, leading to cross-company inconsistencies and errors. Steps to Reproduce ================== 1. Install…
Issue ===== The fiscal position defined on a partner was not properly isolated per company, leading to cross-company inconsistencies and errors. Steps to Reproduce ================== 1. Install `industry_fsm_sale` and `l10n_br`. 2. In the US company: - Create a Brazilian customer. - Set a fiscal position on the customer. 3. Switch to the Brazilian company: - Open the same customer. - Set a fiscal position on the customer. 4. Still in the Brazilian company: - Create a task for that customer in the Field Service app. - Add a product to the task. Result ====== An error is raised because the fiscal position from the US company is used, which is not valid for the Brazilian company. Root Cause ========== When reading the fiscal position from the partner, the value is fetched in the environment of the company in which the partner record was originally created (US company). If no company is explicitly specified, the fiscal position is read in that original environment, even when the user is operating under the Brazilian company. Solution ======== Explicitly enforce the current company context when reading the fiscal position from the partner to ensure the correct company-specific value is used. opw-5270522 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250115 Forward-Port-Of: odoo/odoo#249482
This update corrects an error that occurred when generating payslips for employees who had changed contracts within a pay period. The fix ensures accurate calculation of work years by using the employee's initial contract start date, preventing errors related to holiday table lookups. This improves the reliability of payroll processing.
Original PR description
An error is thrown when we try to generate a payslip for an employee that changed contract on a period before the contract change Steps to reproduce: 1. Install l10n_mx and l10n_mx_hr_payroll modules…
An error is thrown when we try to generate a payslip for an employee that changed contract on a period before the contract change
Steps to reproduce:
1. Install l10n_mx and l10n_mx_hr_payroll modules
2. Switch to INNOVACION VALOR... company
3. Go to Employees and open Cecilia Miranda Sanchez
4. Go to Payroll tab, set the end of the contract to Jan 31 and save
5. Create a new contract from Feb 1
6. Go to Payroll > Payslips > Payslips and create a new pay run
7. Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Bi-weekly' and Period 'Jan 1 -> Jan 15'
8. Click on Continue, select Cecilia and click on Select
9. An error is thrown
Problem:
In `_compute_integration_factor` we try to compute the number of years the employee has worked by accessing the start date on the employee but this date might be earlier than the start date of the employee's current contract if the employee has changed contract. This will throw an error when we try to access the holidays count for 0 year because `payslip._rule_parameter('l10n_mx_holiday_tables')` doesn't have an entry for 0
Solution:
Use the start date of the first contract of the employee, take gaps in between the employee's contracts into consideration to correctly compute the number of years worked
opw-5931355
Forward-Port-Of: odoo/enterprise#108495This pull request addresses several issues within the Hoot testing framework, focusing on improving test reliability and execution speed. Specifically, it fixes errors in test logging, ensures proper test failure reporting, and cleans up test environment setup to prevent issues between tests.
Original PR description
Fixes for tests and testing framework. See commit messages for details. Enterprise: https://github.com/odoo/enterprise/pull/107286 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251363 Forward-Port-Of: odoo/odoo#247137
This update resolves an issue where test scripts were incorrectly triggering events on elements, causing test failures. The fix ensures that test environments are properly cleaned up after each test run, preventing potential performance problems and ensuring the stability of the Odoo Enterprise system. This improves the reliability of our testing process.
Original PR description
Adapt tests failing due to keydown events being applied to the current active element. Community: https://github.com/odoo/odoo/pull/247137 Forward-Port-Of: odoo/enterprise#109149 Forward-Port-Of: odoo/enterprise#107286
This update resolves a technical issue that caused the Point of Sale system to hang during startup. Specifically, a race condition in the indexed database initialization process was corrected, preventing delays and ensuring a smoother POS launch. The fix also ensures the indexedDB is properly populated upon initialization.
Original PR description
There were 2 issues when `serverDateTime` was lower than `lastConfigChange` which triggered a reset on the indexedDB. The first issue was that we would try to await dbInstance.deleteDatabase request.…
There were 2 issues when `serverDateTime` was lower than `lastConfigChange` which triggered a reset on the indexedDB. The first issue was that we would try to await dbInstance.deleteDatabase request. But it returns a request object and then executes the delete asynchronously. This would cause a race condition on the init where we would trigger the init of the indexedDB at the same time as we were trying to delete it and it would hang for ~10 seconds before finally launching the POS.
The second more important issue is that after the reset there is a `localData = []`. This would cause the line in `synchronizeServerDataInIndexedDB` `JSON.parse(JSON.stringify(serverData));` to return an empty array so no new models would get created in the indexedDB and the POS would launch with an empty indexedDB.
This commit changes the `indexed_db.reset()` method to return a promise and awaits it before reinitialising the indexedDB. And resets the `localData` to `{}` which fixes the `synchronizeServerDataInIndexedDB`
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#246476This update fixes an issue where the 'Request Signature' option wasn't consistently appearing in the cog menu on certain task forms. The change ensures the menu item only shows when a chatter is present, improving the user experience and ensuring all users have access to this important feature.
Original PR description
****Behavior:**** **Current:** When selecting the cog menu on certain forms, the request signature item doesn't always show even though it should. The expected behavior of this menu item is to appear only on form views with a chatter, but the way the chatter's presence was verified is inconsistent. **Solution:** On form views with a chatter, we can check its presence directly from the viewArch using the selector from the compiler registry. **Steps to reproduce:** From Timesheets: - Go to Timesheets - Open a task - The cog menu will not contain "Request Signature" From Project: - Go to Project - Select a project and open a task - The cog menu will contain "Request Signature" opw-4817423 Forward-Port-Of: odoo/enterprise#108935 Forward-Port-Of: odoo/enterprise#97401
This update prevents tracebacks that occurred when users clicked on images configured to open in a popup. The fix addresses an issue where a specific slideshow component wasn't correctly initialized, leading to errors. Now, image popups function smoothly without causing technical problems.
Original PR description
Problem: Clicking on an image configured to open in a popup triggers a traceback. Cause: The `ImagePopUp` interaction renders `o_slideshow` without controls due to `shouldShowControls`. As a result, `carousel-indicators` and their children are not rendered. This makes `GallerySlider.liEls` `undefined`, which later causes a traceback in `hide`. Solution: Since `ImagePopUp` always displays a single image, `GallerySlider` is not needed in this case. Exclude `o_image_popup` from initializing `GallerySlider` to avoid accessing undefined elements. Steps to reproduce: - Drop an Image snippet. - Enable “popup on click”. - Save the page. - Click on the image. - Observe the traceback. opw-5974260 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where tip and discount amounts in the Point of Sale interface were not correctly formatted when using a different decimal separator. This change ensures that users see accurate tip and discount values, reducing potential confusion and improving the overall user experience. The fix addresses a minor usability concern.
Original PR description
Before this commit, when the decimal separator was not a dot, the amount in the tip and the discount number popup was not correctly formatted, which could lead to confusion for the user. opw-5921256 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that custom messages displayed in website shop pages are now retained after saving. Previously, a technical issue caused these messages to be overwritten with default ones. This change corrects a regression introduced during a recent update to the website builder, improving the user experience for customizing website content.
Original PR description
Steps to reproduce: - Open the website shop page in edit mode. - Drag and drop a block in the shop header dropzone. - Save the page and re-enter edit mode. - Check the shop header dropzone message.…
Steps to reproduce: - Open the website shop page in edit mode. - Drag and drop a block in the shop header dropzone. - Save the page and re-enter edit mode. - Check the shop header dropzone message. => The custom message is replaced by the default one. Before this commit, `SetupEditorPlugin.cleanForSave()` removed `data-editor-message` and `data-editor-message-default` on the saved HTML clone, including custom messages defined in website templates. This cleanup was originally introduced in `web_editor` in [1]. Since the builder refactor in [2], website page saves now use the shared `html_builder` save cleanup flow and wrongly inherited that behavior, which introduced this regression in website. This commit removes that cleanup from `html_builder`, as it does not provide useful value in this save flow and drops custom dropzone messages. After this commit, custom dropzone messages are preserved after saving website pages. [1]: bab673488e185ddd7792aedecc3870663290fed3 [2]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-5921283 Forward-Port-Of: odoo/odoo#250874
This update ensures that timesheet updates accurately reflect the cost of tasks associated with sales orders, regardless of the invoice policy used (ordered_prepaid, delivered_manual, or delivered_milestones). Previously, updates were prevented for 'ordered_prepaid' invoices, leading to incorrect cost calculations. This change improves the accuracy of sales order costing and reporting.
Original PR description
Originally, timesheet updates for tasks associated with sale order lines would cause the cost (purchase_price) to be recomputed. However, this was prevented if the invoice policy was 'ordered_prepaid.' This should also apply to 'delivered_manual' and 'delivered_milestones.' Otherwise, any timesheet updates will recompute the sales.order.line purchase_price field. Steps to reproduce: 1. Create a service product that creates a project/tasks 2. Create a sales order with the product and manually set the cost 3. Assign the timesheets of the task to an employee 4. Have the employee update their timesheet for the task 5. The cost on the sales order line gets recomputed to the default product price task-5902688 related-pr-205415 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250495
This update fixes a bug where multiple physical gift cards added to a single Point of Sale (PoS) order were not being created in the backend. The issue stemmed from a misidentification of the gift card code key, which has now been corrected. This ensures that all gift cards added to a PoS order are properly recorded.
Original PR description
When selling mutliple physical gift cards in the same PoS order, no gift cards were created. Steps to reproduce: ------------------- * Open PoS * Add a gift card to the order * Click on the gift card line and set a physical gift card with a value of 100€ * Add another gift card to the order * Click on the gift card line and set a physical gift card with a value of 50€ * Validate the order > Observation: No gift card is created in the backend Why the fix: ------------ When looking for the `oldChanges` we tried to retrieve the gift card code as `gift_code` but the key name is `code`. Because of this the `pointsCount` was wrong. opw-5928320 Forward-Port-Of: odoo/odoo#251339 Forward-Port-Of: odoo/odoo#249066
This update resolves an issue where the system was incorrectly checking user trust permissions on multiple records. The fix ensures that this check is performed accurately on a single record, improving the reliability of account-related processes. This change enhances data integrity and reduces potential errors.
Original PR description
In some cases, the check was done on multiple records, though the method should be called on one and only one record. Forward-Port-Of: odoo/odoo#251589 Forward-Port-Of: odoo/odoo#251457
This update simplifies the process of running Odoo tests by introducing an alias for the `--test-tags` command. Previously, users had to explicitly specify test tags, now they can use a simpler alias, streamlining the testing workflow and reducing potential errors. This change enhances the reliability and efficiency of our automated testing procedures.
Original PR description
Backport of https://github.com/odoo/odoo/pull/234287 <img width="408" height="151" alt="image" src="https://github.com/user-attachments/assets/7f22826f-6887-432b-8baf-8a6778b9cadf" /> Forward-Port-Of: odoo/odoo#250283 Forward-Port-Of: odoo/odoo#249123
This update resolves an issue where stock reporting (Inventory / Reporting / Stock) displayed incorrect values due to a lack of company filtering during last product value searches. Previously, all companies were considered, leading to inaccurate unit costs, total values, and on-hand quantities. This fix ensures accurate reporting by correctly filtering results based on the selected company.
Original PR description
Before this fix, when searching for the last product value, we don't check the company. We search for the last product.value among all companies, even when only one company is selected. As a result, we end up with strange values when going to Inventory / Reporting / Stock. For instance, we may end up with: unit cost 10, total value 100, on hand quantity 0. OPW-5957947 Forward-Port-Of: odoo/odoo#251413