Saturday, May 10, 2025
14 changes · saas-18.3
Resolved issues and error corrections
This update prevents an error when users open the optional column menu in the “Blocked By” section of project tasks. It keeps task dependency views usable and avoids an interruption during project task management.
Original PR description
**Steps to reproduce:** - Install project - Enable task dependencies - Go to the blocked-by notebook - Click the optional column dropdown **Issue:** when clicking on optional column in blocked-by notebook a traceback occurs **Fix:** Used parent.has_template_ancestor instead of has_template_ancestor to explicitly access the field from the parent record . task-4764758 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an unreliable HR automated test by waiting for the new chat window to appear before checking the total number of open chats. The change helps reduce false test failures and improves confidence in the HR module's quality checks.
Original PR description
The test `@hr/m2x_avatar_employee/many2one in form view` was failing non-deterministically with the following error: ``` 9. [toHaveCount] found 1 element matching ".o-mail-ChatWindow" > Expected: 2 > Received: 1 > Elements: [ <div.o-mail-ChatWindow.fixed-bottom.overflow-hidden.d-flex.flex-column.shadow-sm.bg-100.rounded-4.border.border-dark.mb-2>, ] ``` This happens because it clicks on avatar card button to send a message, which opens a chat window. However the assertion is made synchronously after the `await contains().click()`, which is not necessarily enough time to ensure the chat window has been open. The next assertion is asserting asynchronously presence of new chat window with specific header, therefore this commit fixes the issue by swapping the assertion orders. When the new chat window with header is shown, then asserting synchronously there are 2 chat windows is correct (it opens new chat window, in addition to keeping previous one open). runbot-163001
The leave request form now behaves more clearly for managers. Action buttons only appear after a leave request is saved, and available hours are shown when the selected time off type can deduct extra hours.
Original PR description
With this commit, some elements in leave's form view are fixed :
- The buttons are only shown when the leave is saved.
- The available hours are displayed when a time off type with deduct extra hours are selected.
task-4756706This update fixes an error that appeared when users opened the optional column menu in sub-task or blocked-by sections of field service tasks. It helps users manage task details without interruptions or unexpected crash screens.
Original PR description
**Steps to reproduce:** - Install `project` and `industry_fsm_sale` modules - Open any task with subtasks - Go to the Sub-tasks notebook or blocked-by notebook - Click the optional column dropdown **Issue:** - when clicking on optional column in subtasks/blockedby notebook a traceback occurs **Fix:** - Used `parent.has_template_ancestor` instead of `has_template_ancestor` to explicitly access the field from the parent record . task-4764758
The live chat helpdesk report query was adjusted to match recent backend changes. This helps keep reporting reliable without changing how users interact with the helpdesk live chat feature.
Original PR description
Group by has been removed as there is only one channel per row, other tables are now joined with lateral. Enterprise counter-part. https://github.com/odoo/odoo/pull/209254
Miscellaneous changes
During this commit: https://github.com/odoo/odoo/commit/2f86fb973a426a4d6c10d41d61dc524955aebb6b we checked the tin1 twice instead of checking the second one task: 4743115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207181
Original PR description
During this commit: https://github.com/odoo/odoo/commit/2f86fb973a426a4d6c10d41d61dc524955aebb6b we checked the tin1 twice instead of checking the second one task: 4743115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207181
ISSUE: When you remove the user from an employee all the linked vehicles are removed as `work_contact_id` is written by the new value before updating the fleet model REPRODUCE: - create a vehicle and link it an employee with user - remove the user from the employee - employee and driver is removed from the vehicle As the issue of persistent 'work_contact_id' on employee has been fixed, all the updates are made auto and these extra code interduce the wrong behavior Task: 4680261 -
Original PR description
ISSUE: When you remove the user from an employee all the linked vehicles are removed as `work_contact_id` is written by the new value before updating the fleet model REPRODUCE: - create a vehicle and link it an employee with user - remove the user from the employee - employee and driver is removed from the vehicle As the issue of persistent 'work_contact_id' on employee has been fixed, all the updates are made auto and these extra code interduce the wrong behavior Task: 4680261 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209298 Forward-Port-Of: odoo/odoo#206396
Fixes two issue with EMV QR generation: - The regex applied on comments is wrong and actually does nothing. - VietQR allows less character than that general regex, so we filter it more. opw-4671523 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208956
Original PR description
Fixes two issue with EMV QR generation: - The regex applied on comments is wrong and actually does nothing. - VietQR allows less character than that general regex, so we filter it more. opw-4671523 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208956
**Steps to reproduce:** - Install account - Activate a foreign currency (e.g. EUR) - Set at least 2 different currency rates for date1 and date2 - Create an invoice: * Customer: [any] * Invoice Date: date1 * Currency: EUR * Invoice line: [any] - Save the invoice - Check debit and credit amounts in "Journal Items" tab - Change the price of the product and set "Invoice Date" to date2 - Save the invoice - Check debit and credit amounts in "Journal Items" tab **Issue:** The
Original PR description
**Steps to reproduce:** - Install account - Activate a foreign currency (e.g. EUR) - Set at least 2 different currency rates for date1 and date2 - Create an invoice: * Customer: [any] * Invoice Date:…
**Steps to reproduce:** - Install account - Activate a foreign currency (e.g. EUR) - Set at least 2 different currency rates for date1 and date2 - Create an invoice: * Customer: [any] * Invoice Date: date1 * Currency: EUR * Invoice line: [any] - Save the invoice - Check debit and credit amounts in "Journal Items" tab - Change the price of the product and set "Invoice Date" to date2 - Save the invoice - Check debit and credit amounts in "Journal Items" tab **Issue:** The debit and credit amounts have been recomputed with the new currency rate, but the conversion has been applied on the old price. **Cause:** In "_sync_invoice" method, when the currency rate has changed, balance (and subsequently debit/credit) is recomputed from amount_currency. However, in this case, balance should be recomputed completely because the line subtotal has changed and amount_currency is not up-to-date with it. **Solution:** Do not recompute balance based on amount_currency when price_subtotal of a line has changed. In that case, it will be recomputed anyway. opw-4658156 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207905
**Steps to reproduce:** - Install Accounting - Create a product: * Product Name: XYZ * Internal Reference: 1234 - Create a second product with the same name: * Product Name: XYZ * Internal Reference: 5678 - Go to "Accounting / Vendors / Bills" - Upload a Peppol BIS Billing 3.0 XML containing 2 invoice lines with the created products: `<cbc:Name>XYZ</cbc:Name>` `<cac:SellersItemIdentification><cbc:ID>1234</cbc:ID></cac:SellersItemIdentification>` and `<cbc:Name>XYZ</cbc:Name>`
Original PR description
**Steps to reproduce:** - Install Accounting - Create a product: * Product Name: XYZ * Internal Reference: 1234 - Create a second product with the same name: * Product Name: XYZ * Internal Reference:…
**Steps to reproduce:** - Install Accounting - Create a product: * Product Name: XYZ * Internal Reference: 1234 - Create a second product with the same name: * Product Name: XYZ * Internal Reference: 5678 - Go to "Accounting / Vendors / Bills" - Upload a Peppol BIS Billing 3.0 XML containing 2 invoice lines with the created products: `<cbc:Name>XYZ</cbc:Name>` `<cac:SellersItemIdentification><cbc:ID>1234</cbc:ID></cac:SellersItemIdentification>` and `<cbc:Name>XYZ</cbc:Name>` `<cac:SellersItemIdentification><cbc:ID>5678</cbc:ID></cac:SellersItemIdentification>` **Issue:** The 2 invoice lines of the generated bill have the same exact product, even when 2 different codes are provided for the products. **Cause:** In "_retrieve_product" method, a search is made on the name, the code and the barcode, but an "OR" operator is applied. Not an "AND". Several products may satisfy the domain but only the first one is returned. **Solution:** If several products matches the conditions, instead of directly returning the first one, try to select one based on the following priority: barcode, code, name. opw-4466322 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209048 Forward-Port-Of: odoo/odoo#205739
Before this commit, if the generic manufacture route was in a different company, the user won't be able to create a new warehouse. Steps to reproduce ----- 1. Set the company of the Manufacture route to company A 2. Switch to company B 3. Create a new warehouse 4. Access Error `Due to security restrictions, you are not allowed to access 'Inventory Routes' (stock.route) records.` Cause ----- There is an if-statement to check if the found global route is of the same company. https://g
Original PR description
Before this commit, if the generic manufacture route was in a different company, the user won't be able to create a new warehouse. Steps to reproduce ----- 1. Set the company of the Manufacture route to company A 2. Switch to company B 3. Create a new warehouse 4. Access Error `Due to security restrictions, you are not allowed to access 'Inventory Routes' (stock.route) records.` Cause ----- There is an if-statement to check if the found global route is of the same company. https://github.com/odoo/odoo/blob/856409a1fb35c6c49fe4c404931587a95d99d370/addons/stock/models/stock_warehouse.py#L385 But this conditional is likely to raise an access error if the route is in a different company, since we don't have read access to `route`. Solution ----- Use `route.sudo()` to read the route without an access error. opw-4725501 Forward-Port-Of: odoo/odoo#208686 Forward-Port-Of: odoo/odoo#208234
When a conversation is unread (and no important messages), the conversation in discuss sidebar has a small dot next to the item. In white theme its visibility is good, with `.opacity-50`. In dark theme however this indicator is hard to see. This commit fixes the issue by keeping 50% opacity in white theme but bumping to 75% in dark theme specifically. Forward-Port-Of: odoo/odoo#208993
Original PR description
When a conversation is unread (and no important messages), the conversation in discuss sidebar has a small dot next to the item. In white theme its visibility is good, with `.opacity-50`. In dark theme however this indicator is hard to see. This commit fixes the issue by keeping 50% opacity in white theme but bumping to 75% in dark theme specifically. Forward-Port-Of: odoo/odoo#208993
**Steps to reproduce:** - Install Accounting and l10n_lu_reports - Switch to a Luxembourgish company (e.g. LU Company) - Go to "Accounting / Reporting / Statement Reports / Profit and Loss" - Set custom date from "01/01/2025" to "31/12/2025" - Export XML **Issue:** In the exported XML, for "CA_BILAN" declaration section, the start date is set to "01/12/2025" instead of "01/01/2025". **Cause:** When generating the report values of that section, the options are recomputed with the co
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_lu_reports - Switch to a Luxembourgish company (e.g. LU Company) - Go to "Accounting / Reporting / Statement Reports / Profit and Loss" - Set custom date from "01/01/2025" to "31/12/2025" - Export XML **Issue:** In the exported XML, for "CA_BILAN" declaration section, the start date is set to "01/12/2025" instead of "01/01/2025". **Cause:** When generating the report values of that section, the options are recomputed with the comparison filter. This section is based on "Balance Sheet" report and recomputing the options of that report provides a different "from date" coming from "_init_options_date" method. **Solution:** Force the "from date" of the original options when using a custom range date. opw-4737810 Forward-Port-Of: odoo/enterprise#85025 Forward-Port-Of: odoo/enterprise#84672
A previous commit 9b133b2cd03a726d330c87a1227903fc925b0ed5 restricted the view and actions we had on the accounting dashboard for a bank journal from a branch company, if the journal belongs to the parent company. In Odoo 17 the fix made sense, but in Odoo 18, the dashboard data added conflicts with another one, resulting in no data being displayed at all when the journal is connected to an online account. This PR adapts the initial fix to use the existing data (deprecate `show_bank_connec
Original PR description
A previous commit 9b133b2cd03a726d330c87a1227903fc925b0ed5 restricted the view and actions we had on the accounting dashboard for a bank journal from a branch company, if the journal belongs to the parent company. In Odoo 17 the fix made sense, but in Odoo 18, the dashboard data added conflicts with another one, resulting in no data being displayed at all when the journal is connected to an online account. This PR adapts the initial fix to use the existing data (deprecate `show_bank_connect` in favor of `display_connect_bank_in_dashboard`) and adds the 'credit' type journal in the condition for `show_sync_action` to be used by the dashboard data. Forward-Port-Of: odoo/enterprise#84976