Daily updates from Odoo
Friday, January 10, 2025
27 changes · master
Enhancements to existing features
Field service users can now return directly from the product catalog to the task they came from. This reduces navigation friction and helps teams move between task details and related products more efficiently.
Original PR description
In field service, on task form, there is a stat button "n products". Clicking on it leads to the products catalog. In this PR, we add a button on that view to return to the task's form. task-4295982
The mobile project side panel now shows its caret more clearly, making it easier for users to notice and use the panel controls. Related project dashboard and task actions were also aligned across connected project modules for a more consistent experience.
Original PR description
Made the mobile Right side panel caret being barely visible. task-4190761
Rental schedule statuses now use distinct colors for late pickups and reserved orders. This makes it easier for users to quickly spot overdue pickups without confusing them with reservations.
Original PR description
Before this commit: - The colors assigned to late pickup and reserved status orders were the same, leading to confusion. After this commit: - Distinct colors have been assigned for late pickup and reserved status orders. Task-4154459
Helpdesk email-related tests have been reorganized into a dedicated area and enhanced to better verify generated email content and flows. This makes future changes to helpdesk email handling safer and easier to validate, with no direct user-facing behavior change.
Original PR description
Just to have them a bit more standard and in a specific file. This is going to ease future changes.
Resolved issues and error corrections
Restaurant staff will now see the correct booking time on the point-of-sale floor screen instead of an "Invalid time" message. This helps teams manage table reservations more accurately during service.
Original PR description
Steps:
===
- Install the pos_restaurant_appointment module.
- Open a session for the restaurant.
- Create a booking for a table.
- Open the floor screen and check the booked table.
- It shows "Invalid time" instead of the correct booking time.
Fix:
===
- Replaced deserializeDateTime(date) with direct date.toFormat("HH:mm") to correctly format and display the booking time.
To Be:
===
- Ensure that the booking time are displayed accurately on the floor screen.
task-4438700Miscellaneous changes
Before this commit: Post including long links were not truncated and will extend beyond the kanban card. This happen as the display CSS property is set to `inline` by default due to the <field> tag being transformed into a <span> tag in the HTML. <div> default display is `block` while <span> are `inline`. After this commit: The link truncate as intended with "..." Before:  After:  opw-4446906 Forward-Port-Of: odoo/enterprise#76719
Steps to reproduce: 1.) Create a trial db 18.0 2.) Install website and helpdesk 3.) Create a second company (two companies, one website, may have to delete a website) 4.) Navigate to a Team in 'Helpdesk / Teams' with company B 5.) Enable 'Website Form' 6.) Use 'Go to Website' smart button 7.) We get an access error - Remove multi_website group and add conditional to stat button Forward-Port-Of: odoo/enterprise#76268
Original PR description
Steps to reproduce: 1.) Create a trial db 18.0 2.) Install website and helpdesk 3.) Create a second company (two companies, one website, may have to delete a website) 4.) Navigate to a Team in 'Helpdesk / Teams' with company B 5.) Enable 'Website Form' 6.) Use 'Go to Website' smart button 7.) We get an access error - Remove multi_website group and add conditional to stat button Forward-Port-Of: odoo/enterprise#76268
### Before this PR: - The `Search in Sales Order` and `Sales Order` options were always visible in the Helpdesk ticket portal search bar, regardless of the configuration of the `use_helpdesk_sale_timesheet` field in the Helpdesk Team. - This led to confusion for users who did not utilize sales orders in their helpdesk workflows. ### After this PR: - The `Search in Sales Order` and `Sales Order` options are now only displayed when the `use_helpdesk_sale_timesheet` field is set to true in th
Original PR description
### Before this PR: - The `Search in Sales Order` and `Sales Order` options were always visible in the Helpdesk ticket portal search bar, regardless of the configuration of the `use_helpdesk_sale_timesheet` field in the Helpdesk Team. - This led to confusion for users who did not utilize sales orders in their helpdesk workflows. ### After this PR: - The `Search in Sales Order` and `Sales Order` options are now only displayed when the `use_helpdesk_sale_timesheet` field is set to true in the Helpdesk Team configuration. task-4224818 Forward-Port-Of: odoo/enterprise#76850 Forward-Port-Of: odoo/enterprise#71516
### Steps to reproduce: - Install "l10n_cl_edi" - Have a contact of company type with an email and a DTE email - Create a contact of individual type with an email and with the company as parent - In Accounting app create an invoice with the individual as customer - Confirm and open the generated XML - The field CorreoRecep is the individual's email but it should be the DTE of the company ### Cause: The order in the `t-esc` first display the emails before DTE emails. Order of priorit
Original PR description
### Steps to reproduce: - Install "l10n_cl_edi" - Have a contact of company type with an email and a DTE email - Create a contact of individual type with an email and with the company as parent - In Accounting app create an invoice with the individual as customer - Confirm and open the generated XML - The field CorreoRecep is the individual's email but it should be the DTE of the company ### Cause: The order in the `t-esc` first display the emails before DTE emails. Order of priority before this commit: partner email > parent partner email > partner DTE email > parent partner DTE email ### Solution: Change the order to display the DTE email if possible: Order of priority after this commit: partner DTE email > parent partner DTE email > partner email > parent partner email opw-4288781 Forward-Port-Of: odoo/enterprise#76600 Forward-Port-Of: odoo/enterprise#75917
Scenario: - Install l10n_pe_edi and switch to "PE Company" - Create a product with "Withhold Percentage" 20% - Create an invoice with operation type "[1001] Operation Subject to Detraction", the created product and USD currency. - Print the invoice as PDF => The "Withholding amount" in the PDF is correctly shown in the company currency, but the currency symbol is the one of the invoice ($) Issue: Amount is always in the company currency, and currency is the invoice currency th
Original PR description
Scenario: - Install l10n_pe_edi and switch to "PE Company" - Create a product with "Withhold Percentage" 20% - Create an invoice with operation type "[1001] Operation Subject to Detraction", the created product and USD currency. - Print the invoice as PDF => The "Withholding amount" in the PDF is correctly shown in the company currency, but the currency symbol is the one of the invoice ($) Issue: Amount is always in the company currency, and currency is the invoice currency that might be different. Fix: currency_id gotten from account.move()._l10n_pe_edi_get_spot is only used in this location where the amount should always be the company currency: so we modify it to be the company currency. opw-4292774 opw-4338728 Forward-Port-Of: odoo/enterprise#76334
steps: - create an invoice with a customer that has the `ref` set to some value - send this invoice to DIAN -> We get an error back saying the xml is incorrect Solution: Although DIAN accepts eInvoices based on UBL 2.1, it throws an error when it receives an xml file with a cbc:BuyerReference tag. To fix this we now just leave out the tag from the xml file ticket: 4367849 Forward-Port-Of: odoo/enterprise#76548
Original PR description
steps: - create an invoice with a customer that has the `ref` set to some value - send this invoice to DIAN -> We get an error back saying the xml is incorrect Solution: Although DIAN accepts eInvoices based on UBL 2.1, it throws an error when it receives an xml file with a cbc:BuyerReference tag. To fix this we now just leave out the tag from the xml file ticket: 4367849 Forward-Port-Of: odoo/enterprise#76548
With the changes done to `account.external.tax.mixin` the name of ir.logging is now the module name and not 'Avatax' anymore. So us logs resulted in Avatax US and were not shown by default when opening the window with the window actions. opw-4429151 Forward-Port-Of: odoo/enterprise#76749 Forward-Port-Of: odoo/enterprise#76557
Original PR description
With the changes done to `account.external.tax.mixin` the name of ir.logging is now the module name and not 'Avatax' anymore. So us logs resulted in Avatax US and were not shown by default when opening the window with the window actions. opw-4429151 Forward-Port-Of: odoo/enterprise#76749 Forward-Port-Of: odoo/enterprise#76557
[FIX] account_reports: sections tour The sections' tour was breaking with the change of year. We use the generic tax report for doing the testing. The generic tax report has a periodicity of 1 month and opens at the previous period. Our tests where based on the current date year. It works fine except on the change of year. Indeed, we will be on January of year XXXX but the report will open on December of year YYYY. Now, we correctly remove 1 month to our dates to make sure we have
Original PR description
[FIX] account_reports: sections tour The sections' tour was breaking with the change of year. We use the generic tax report for doing the testing. The generic tax report has a periodicity of 1 month and opens at the previous period. Our tests where based on the current date year. It works fine except on the change of year. Indeed, we will be on January of year XXXX but the report will open on December of year YYYY. Now, we correctly remove 1 month to our dates to make sure we have the correct year. We also took the time to replace the usage of Date of plain javascript with DateTime of the luxon library. Forward-Port-Of: odoo/enterprise#76645 Forward-Port-Of: odoo/enterprise#76606
Before this commit, when we did a search in the general ledger for an account code with alpha characters, (ex: `411EDP` in the search bar) the options resulted with `411edp`. It was changed to lowercase. And due to a change in the _name_search of account_account, it now uses like and not anymore ilike. Commit: https://github.com/odoo/odoo/commit/1f589682a9414312b8c15beec5a09e76b16c7c41 The fix is to provide to the options the original search query without lowercase. opw-4388517 Forw
Original PR description
Before this commit, when we did a search in the general ledger for an account code with alpha characters, (ex: `411EDP` in the search bar) the options resulted with `411edp`. It was changed to lowercase. And due to a change in the _name_search of account_account, it now uses like and not anymore ilike. Commit: https://github.com/odoo/odoo/commit/1f589682a9414312b8c15beec5a09e76b16c7c41 The fix is to provide to the options the original search query without lowercase. opw-4388517 Forward-Port-Of: odoo/enterprise#76660 Forward-Port-Of: odoo/enterprise#76524
## [FIX] knowledge: fix disappearing comments overlay This commit fixes an issue with the comments overlay when zooming and dezooming on the article. At certain sizes the overlay of the comment would disappear without reason. This is caused by the rect computations done to identify the correct overlay to draw. The target selected by the coordinates given to the `elementFromPoint` method would be incorrect. This happens because the coordinates weren't the center of the rectangle but the
Original PR description
## [FIX] knowledge: fix disappearing comments overlay This commit fixes an issue with the comments overlay when zooming and dezooming on the article. At certain sizes the overlay of the comment would…
## [FIX] knowledge: fix disappearing comments overlay This commit fixes an issue with the comments overlay when zooming and dezooming on the article. At certain sizes the overlay of the comment would disappear without reason. This is caused by the rect computations done to identify the correct overlay to draw. The target selected by the coordinates given to the `elementFromPoint` method would be incorrect. This happens because the coordinates weren't the center of the rectangle but the top. Which means that for certain resolutions the element selected is the whole body instead of the correct paragraph/text node. Now, the coordinates are computed so that we are indeed at the center of the rect. ## [FIX] knowledge: avoid opening new comments on click This commit fixes an issue with the knowledge comments small UI. When you create a comment in small UI and click on the overlay in the body of the article, the newly created comments open its popover. This behavior shouldn't happen in any circumstances except when in readonly mode. task-4463401 Forward-Port-Of: odoo/enterprise#76709
When we rename any doc without a name, it shows 'False' because the field isn't set as 'required.' Making it mandatory will trigger a red alert on save, ensuring a valid name is entered. Task-4367684 Forward-Port-Of: odoo/enterprise#76064
Original PR description
When we rename any doc without a name, it shows 'False' because the field isn't set as 'required.' Making it mandatory will trigger a red alert on save, ensuring a valid name is entered. Task-4367684 Forward-Port-Of: odoo/enterprise#76064
…to load Open a pivot view via an "anonymous" action, that is via a method of a model or something else. Open studio Close Studio Before this commit, we ended up with just an empty studio screen, obviously broken. This is the aftermath of odoo/enterprise@78599bd1b564fe0c64210ebcb90803b75f55755a where some use cases were left untreated. After this commit, use cases like this one fallback to either the closest action that has a chance to work -- this logic is driven by the action_serv
Original PR description
…to load Open a pivot view via an "anonymous" action, that is via a method of a model or something else. Open studio Close Studio Before this commit, we ended up with just an empty studio screen, obviously broken. This is the aftermath of odoo/enterprise@78599bd1b564fe0c64210ebcb90803b75f55755a where some use cases were left untreated. After this commit, use cases like this one fallback to either the closest action that has a chance to work -- this logic is driven by the action_service -- or to the home menu if really we did not guess hard enough. Forward-Port-Of: odoo/enterprise#76651
…on sell/dispose Steps to reproduce: - Create an asset with an acquisition date on the 1st of January, 2 years ago. - Set the depreciation method to "Declining" with a duration of 2 years. - Confirm it. - Click on "Modify depreciation". - Dispose it on the 1st of January of this year (i.e. after the asset's total duration). Observed behavior: You'll be met with a division by zero error. Solution: Prevent any unnecessary computations as well as unwanted division by zero errors by
Original PR description
…on sell/dispose Steps to reproduce: - Create an asset with an acquisition date on the 1st of January, 2 years ago. - Set the depreciation method to "Declining" with a duration of 2 years. - Confirm it. - Click on "Modify depreciation". - Dispose it on the 1st of January of this year (i.e. after the asset's total duration). Observed behavior: You'll be met with a division by zero error. Solution: Prevent any unnecessary computations as well as unwanted division by zero errors by simply returning early when the asset's residual amount is zero. A test is also added to cover this use case. opw-4411877 Forward-Port-Of: odoo/enterprise#76733 Forward-Port-Of: odoo/enterprise#76555
Adapt the `get_limited_partners_loading` method to the new API. Forward-Port-Of: odoo/enterprise#76821
Original PR description
Adapt the `get_limited_partners_loading` method to the new API. Forward-Port-Of: odoo/enterprise#76821
In some cases, the default currency is set to EUR, which makes the FedEx tests fail as they are coded to work for USD. Runbot Error 107969 Forward-Port-Of: odoo/enterprise#75271
Original PR description
In some cases, the default currency is set to EUR, which makes the FedEx tests fail as they are coded to work for USD. Runbot Error 107969 Forward-Port-Of: odoo/enterprise#75271
Steps to reproduce the bug: - Create a storable product “P1”: - Tracked with SN - Create a BoM: - no need to component - Add an operation “OP1” with steps - Control by product - Create a manufacturing order for one unit of P1 - Confirm the MO - Go to the shop floor and process “OP1” - Validate the MO - Go to the SN of P1 Problem: The quality checks are filtered using “search_default_lot_id = active_id”, which means only quality checks linked to th
Original PR description
Steps to reproduce the bug: - Create a storable product “P1”: - Tracked with SN - Create a BoM: - no need to component - Add an operation “OP1” with steps - Control by product - Create a…
Steps to reproduce the bug:
- Create a storable product “P1”:
- Tracked with SN
- Create a BoM:
- no need to component
- Add an operation “OP1” with steps
- Control by product
- Create a manufacturing order for one unit of P1
- Confirm the MO
- Go to the shop floor and process “OP1”
- Validate the MO
- Go to the SN of P1
Problem:
The quality checks are filtered using “search_default_lot_id = active_id”,
which means only quality checks linked to the “search_default_lot_id”
are displayed. However, in this usecase, the "lot_id” is not set.
Instead, the "finished_lot_id" is used, causing the quality checks to be
hidden unless the filter is removed.
Solution:
the domain is properly prepared so no longer needs this filter: https://github.com/odoo-dev/enterprise/blob/33de674651017a79e4d010b054dfb2ccaf8b744c/quality_control/models/stock_lot.py#L23-L27
https://github.com/odoo-dev/enterprise/blob/33de674651017a79e4d010b054dfb2ccaf8b744c/quality_control/models/stock_lot.py#L20-L21
https://github.com/odoo-dev/enterprise/blob/33de674651017a79e4d010b054dfb2ccaf8b744c/quality_mrp_workorder/models/stock_lot.py#L10-L13
opw-4361358
Forward-Port-Of: odoo/enterprise#76376After creating the tax closing, users attempting to create a foreign fiscal position will see a traceback Steps to reproduce: - Go to Accounting / Reporting / Statement Reports / Tax Return - Click 'Closing Entry' and generate the report - Go to Accounting / Configuration / Accounting / Fiscal Positions - Create a new Fiscal position with: - Detect Automatically: true - Country: Germany - Foreign Tax ID: DE123456789 - Save Issue: Traceback will raise `AttributeError: 'accoun
Original PR description
After creating the tax closing, users attempting to create a foreign fiscal position will see a traceback Steps to reproduce: - Go to Accounting / Reporting / Statement Reports / Tax Return - Click 'Closing Entry' and generate the report - Go to Accounting / Configuration / Accounting / Fiscal Positions - Create a new Fiscal position with: - Detect Automatically: true - Country: Germany - Foreign Tax ID: DE123456789 - Save Issue: Traceback will raise `AttributeError: 'account.fiscal.position' object has no attribute 'filter_multi_company'` opw-4376837 Forward-Port-Of: odoo/enterprise#76492
Before this commit, the transaction row was locked when payment was performed in the subscription invoice cron. Using `SELECT FOR UPDATE` locks the entire row, primary key included (id in our case). As a result, it could prevent insertion or update or other table refering to the id too. As it is not necessary and could trigger unnecessary deadlock, it is better to rely on `SELECT FOR NO KEY UPDATE` which allow the update of foreign keys. https://www.postgresql.org/docs/16/explicit-locking.ht
Original PR description
Before this commit, the transaction row was locked when payment was performed in the subscription invoice cron. Using `SELECT FOR UPDATE` locks the entire row, primary key included (id in our case). As a result, it could prevent insertion or update or other table refering to the id too. As it is not necessary and could trigger unnecessary deadlock, it is better to rely on `SELECT FOR NO KEY UPDATE` which allow the update of foreign keys. https://www.postgresql.org/docs/16/explicit-locking.html#LOCKING-ROWS See https://github.com/odoo/enterprise/pull/74078#discussion_r1873729342 taskid: 4391755 Forward-Port-Of: odoo/enterprise#76619
In this commit: ==================== - Adjusted the workflow to enable users to prepare manufacturing orders (MOs) for back-orders when clicking 'Produce All' for final products linked with serial numbers (SN), without blocking for quality checks when instructions are associated with any work order. task-4280758 Forward-Port-Of: odoo/enterprise#73886
Original PR description
In this commit: ==================== - Adjusted the workflow to enable users to prepare manufacturing orders (MOs) for back-orders when clicking 'Produce All' for final products linked with serial numbers (SN), without blocking for quality checks when instructions are associated with any work order. task-4280758 Forward-Port-Of: odoo/enterprise#73886
The fix previously done[^1] was always removing the BIC number because it is "optional". While it should be optional, some banks require it for payments done in EUR. The reason the previous fix was done was to avoid having the `Othr` tag, but that tag won't be used outside of methods returning `False` explicitly for `_skip_CdtrAgt`. opw-4423834 [^1]: 1a221f2f3160a48dc7ba08ea59c6781071b1adf3 Forward-Port-Of: odoo/enterprise#76558
Original PR description
The fix previously done[^1] was always removing the BIC number because it is "optional". While it should be optional, some banks require it for payments done in EUR. The reason the previous fix was done was to avoid having the `Othr` tag, but that tag won't be used outside of methods returning `False` explicitly for `_skip_CdtrAgt`. opw-4423834 [^1]: 1a221f2f3160a48dc7ba08ea59c6781071b1adf3 Forward-Port-Of: odoo/enterprise#76558
Since #76586 the tour checks for exact values, if a pricelist happens to apply, then the product value will be altered and not match expectations. Reset pricelists to ensure consistent execution environment. Forward-Port-Of: odoo/enterprise#76809
Original PR description
Since #76586 the tour checks for exact values, if a pricelist happens to apply, then the product value will be altered and not match expectations. Reset pricelists to ensure consistent execution environment. Forward-Port-Of: odoo/enterprise#76809
In this commit: - After accepting a delivery order, a countdown timer appears, indicating the preparation time. This timer counts down, providing the user with a timeline to prepare the order within the allotted time.  task-4049465 Forward-Port-Of: odoo/enterprise#76721 Forward-Port-Of: odoo/enterprise#73620
Original PR description
In this commit: - After accepting a delivery order, a countdown timer appears, indicating the preparation time. This timer counts down, providing the user with a timeline to prepare the order within the allotted time.  task-4049465 Forward-Port-Of: odoo/enterprise#76721 Forward-Port-Of: odoo/enterprise#73620