Daily updates from Odoo
Navigate
Branch
Tuesday, July 30, 2024
49 changes
13 changes
Miscellaneous changes
In the current system, the order widget experienced undesired updates to all order lines when a new product with the same attribute was added. Our recent changes address this issue, ensuring that existing attribute values remain unaffected by the addition of new ones. Moreover, we've refined the display of attribute information. If an attribute is designated as "never," it will now be incorporated into the order line note. Conversely, attributes with different settings will continue to be dis
Original PR description
In the current system, the order widget experienced undesired updates to all order lines when a new product with the same attribute was added. Our recent changes address this issue, ensuring that existing attribute values remain unaffected by the addition of new ones. Moreover, we've refined the display of attribute information. If an attribute is designated as "never," it will now be incorporated into the order line note. Conversely, attributes with different settings will continue to be displayed in their usual format. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154175 Forward-Port-Of: odoo/odoo#152213
#### Commit 1 [FIX] sms, tools: prevent adding link references in sms This fix prevents the conversion of urls into reference footnotes in sent sms (adding characters and imparing readability) when coming from raw text (in opposition to html source). #### Commit 2 [FIX] mass_mailing_sms: fix characters count with (opt-out) links Also impacted: sms When adding opt-out link or any link in the text, the characters count was incorrect which made SMS campaigns more expensive than e
Original PR description
#### Commit 1 [FIX] sms, tools: prevent adding link references in sms This fix prevents the conversion of urls into reference footnotes in sent sms (adding characters and imparing readability) when…
#### Commit 1 [FIX] sms, tools: prevent adding link references in sms This fix prevents the conversion of urls into reference footnotes in sent sms (adding characters and imparing readability) when coming from raw text (in opposition to html source). #### Commit 2 [FIX] mass_mailing_sms: fix characters count with (opt-out) links Also impacted: sms When adding opt-out link or any link in the text, the characters count was incorrect which made SMS campaigns more expensive than expected when added characters meant more SMS to send for the message. #### Commit 3 [FIX] sms: fix disappearing sms counts To reproduce: 1. On a contact form view, click the `SMS` to send an SMS to a customer. 2. Enter some characters in the body textarea 3. Click outside the textarea At this point the count disappears and does not return on re-entering either. This solves it. (We keep jquery to keep this short and simple, as it will be obsolete with OWL in more recent versions anyway). Task-3502174 Forward-Port-Of: odoo/odoo#173285 Forward-Port-Of: odoo/odoo#140102
The test was failing because it tried to check the ZIP code of the partner. That was because the ZIP in the test was 99999, and another partner has a tax ID that contains 99999. The test was checking the first partner displayed on the list, and it was not the one with the ZIP but the one with the tax ID. This commit makes the ZIP code of the partner more long and unique to avoid this kind of issue. Runbot error: 72516, 72515, 72513 Forward-Port-Of: odoo/odoo#174806
Original PR description
The test was failing because it tried to check the ZIP code of the partner. That was because the ZIP in the test was 99999, and another partner has a tax ID that contains 99999. The test was checking the first partner displayed on the list, and it was not the one with the ZIP but the one with the tax ID. This commit makes the ZIP code of the partner more long and unique to avoid this kind of issue. Runbot error: 72516, 72515, 72513 Forward-Port-Of: odoo/odoo#174806
Current behavior: --- Israeli mobile phone numbers are composed as such: +972 55-295-1235 +972 country code, 5X mobile number indicator, X5-29 phone operator Only operators up to 5-28 were supported, recent library changes now support up to 5-29 (the next operator being 5-32) Steps to reproduce: --- parsed = phonenumbers.parse('055 294 1234', 'IL') is_valid = phonenumbers.is_valid_number(parsed) is_valid == False Cause of the issue: --- Old versions of phonenumbers (external lib
Original PR description
Current behavior:
---
Israeli mobile phone numbers are composed as such: +972 55-295-1235
+972 country code, 5X mobile number indicator, X5-29 phone operator
Only operators up to 5-28 were supported, recent library changes now support up to 5-29
(the next operator being 5-32)
Steps to reproduce:
---
parsed = phonenumbers.parse('055 294 1234', 'IL')
is_valid = phonenumbers.is_valid_number(parsed)
is_valid == False
Cause of the issue:
---
Old versions of phonenumbers (external library) are not up to date with the latest israeli phone system changes
Fix:
---
Monkey patched the library
Similar as: https://github.com/odoo/odoo/commit/b7878038e0aca885aa174ccd74be9ffd4b393a89
opw-3942014
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#174577
Forward-Port-Of: odoo/odoo#174425version - 16.0 Steps: -Install rental app. -Activate the date picker from the web-editor. -Add the start date and end date from that. -Select some attribute of the product. Issue: -When any user adds the start date and end date from the date picker and after that, the user adds the other attribute(filter) of the product, that s> Cause: -The selected rental period (start and end dates) is not persisted when the page refreshes or updates due to attribute selection. Fix: Get
Original PR description
version - 16.0 Steps: -Install rental app. -Activate the date picker from the web-editor. -Add the start date and end date from that. -Select some attribute of the product. Issue: -When any user adds the start date and end date from the date picker and after that, the user adds the other attribute(filter) of the product, that s> Cause: -The selected rental period (start and end dates) is not persisted when the page refreshes or updates due to attribute selection. Fix: Get the value of 'start_date' and 'end_date'. Update the hidden input fields for 'start_date' and 'end_date' with the values before applying the attribute changes. opw-3774060 Forward-Port-Of: odoo/odoo#174772 Forward-Port-Of: odoo/odoo#165068
Currently all moves are assumed to belong to the same company for the lock date computation. This commit fixes that issue. (no task) Forward-Port-Of: odoo/odoo#172275
Original PR description
Currently all moves are assumed to belong to the same company for the lock date computation. This commit fixes that issue. (no task) Forward-Port-Of: odoo/odoo#172275
To reproduce the issue: 1) Make an invoice using a tax impacting some tag 2) Add a tanslation to that tag 3) Switch the user language to the one you added a translation for 4) Open the tax report: the line the tag is linked to has a value of 0 ===> It should contain the value you added in 1) l10n_multilang makes the 'name' field of account.account.tag translatable. Because of that, it is important to always check the tags matching a report expression's formula using en_US as the language
Original PR description
To reproduce the issue: 1) Make an invoice using a tax impacting some tag 2) Add a tanslation to that tag 3) Switch the user language to the one you added a translation for 4) Open the tax report: the line the tag is linked to has a value of 0 ===> It should contain the value you added in 1) l10n_multilang makes the 'name' field of account.account.tag translatable. Because of that, it is important to always check the tags matching a report expression's formula using en_US as the language, to make sure the formula of the report expression matches the tag name (since that expression's formula is not translatable). enterprise: https://github.com/odoo/enterprise/pull/65030 Forward-Port-Of: odoo/odoo#173520 Forward-Port-Of: odoo/odoo#170041
Purchase IRPF 19% Spanish tax has 2 target models: 111 and 123. New law requires a more specific breakdown. Now, the tax for 111 is relabeled as "Retenciones IRPF 19% (Compra consejero de persona física)" to be more accurate, and the new one for model 123 is named "Retenciones IRPF 19% (Compra consejero de sociedad)". Since Odoo doesn't implement model 123 yet, that new tax includes no repartition lines. See https://github.com/OCA/l10n-spain/issues/3520 for more context. ---
Original PR description
Purchase IRPF 19% Spanish tax has 2 target models: 111 and 123. New law requires a more specific breakdown. Now, the tax for 111 is relabeled as "Retenciones IRPF 19% (Compra consejero de persona física)" to be more accurate, and the new one for model 123 is named "Retenciones IRPF 19% (Compra consejero de sociedad)". Since Odoo doesn't implement model 123 yet, that new tax includes no repartition lines. See https://github.com/OCA/l10n-spain/issues/3520 for more context. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr @moduon MT-5767 Ticket link: https://www.odoo.com/web#model=project.task&id=3864840 opw-3864840 Forward-Port-Of: odoo/odoo#173531 Forward-Port-Of: odoo/odoo#161633
Issue ----- Events displayed on website are not correctly indexed by Google. This results in events not being displayed in the "Rich Results" format and simply as links in Google searches. Cause ----- The start date is a required field for proper indexation and is missing from the registration page of the event. Fix ----- Add information in Microdata format. opw-3993758 Forward-Port-Of: odoo/odoo#174445 Forward-Port-Of: odoo/odoo#172104
Original PR description
Issue ----- Events displayed on website are not correctly indexed by Google. This results in events not being displayed in the "Rich Results" format and simply as links in Google searches. Cause ----- The start date is a required field for proper indexation and is missing from the registration page of the event. Fix ----- Add information in Microdata format. opw-3993758 Forward-Port-Of: odoo/odoo#174445 Forward-Port-Of: odoo/odoo#172104
When the audit trail feature was enabled, it was impossible to merge the partners. Since we don't lose any information, we allow that action specifically. Because it should never be allowed in non controlled settings, we use a python token so that the context key cannot be used with RPC calls. Forward-Port-Of: odoo/odoo#174533
Original PR description
When the audit trail feature was enabled, it was impossible to merge the partners. Since we don't lose any information, we allow that action specifically. Because it should never be allowed in non controlled settings, we use a python token so that the context key cannot be used with RPC calls. Forward-Port-Of: odoo/odoo#174533
Current behavior: When a combo product is on the order and the user change the fiscal position, the prices of the lines of the combo change to get there original prices rather than the price of the combo Steps to reproduce: - Install "Point of Sale" app - Enable "Flexible Taxes" in the shop settings and allow 2 fiscal positions - Start a session, select one of the fp click on a combo product - Change the fp, the prices of the orderlines are now the prices of the products themselves and n
Original PR description
Current behavior: When a combo product is on the order and the user change the fiscal position, the prices of the lines of the combo change to get there original prices rather than the price of the combo Steps to reproduce: - Install "Point of Sale" app - Enable "Flexible Taxes" in the shop settings and allow 2 fiscal positions - Start a session, select one of the fp click on a combo product - Change the fp, the prices of the orderlines are now the prices of the products themselves and not the prices of the combo Cause: After changing the fp, the quantity of al the orderlines are reset Solution: After changing the fp, call the function which update the pricelist which update all the prices correctly opw-4027186 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174834 Forward-Port-Of: odoo/odoo#173770
When having a sale/purchase journal in foreign currency, the late bills and bills to pay valuess are not displayed on the journal dashboard. opw-4048325 Forward-Port-Of: odoo/odoo#173514
Original PR description
When having a sale/purchase journal in foreign currency, the late bills and bills to pay valuess are not displayed on the journal dashboard. opw-4048325 Forward-Port-Of: odoo/odoo#173514
Usecase to reproduce: - Create a product and put 1 units in 3 different packs - Enable move entire package on the delivery order picking type - Reserve - Add the missing pack and remove one of the other - Remove the associated stock.move.line - Reserve Current behavior: Object `stock.package.level` with id x do not exists. Expected behavior: The pack removed is added again. (we can't force the reservation of a specific pack that way) It's due to commit [1] that remove the done a
Original PR description
Usecase to reproduce: - Create a product and put 1 units in 3 different packs - Enable move entire package on the delivery order picking type - Reserve - Add the missing pack and remove one of the other - Remove the associated stock.move.line - Reserve Current behavior: Object `stock.package.level` with id x do not exists. Expected behavior: The pack removed is added again. (we can't force the reservation of a specific pack that way) It's due to commit [1] that remove the done and rewrite it after reservation. Since the code changed a lot, removing the is_done will remove the stock.move.line in it and deleting all the stock.move.line in a package.level will unlink it. We don't do that trick since the stock.move.line are picked and the reservation won't touch it [1] commit 03384e3fc991ddd8f026ca7527c4add1fb1c70cc Forward-Port-Of: odoo/odoo#166041 Forward-Port-Of: odoo/odoo#164512
22 changes
Enhancements to existing features
The Helpdesk website page now uses an updated call-to-action design that matches the broader Odoo 18 website snippet refresh. This keeps the customer-facing helpdesk experience visually consistent with the rest of the website.
Original PR description
- Requires : https://github.com/odoo/odoo/pull/172728 https://github.com/odoo/design-themes/pull/823 task-3670312 ------------ This PR introduces some small design adaptations to the `call to action` snippet used in `website_helpdesk`. As all the snippets are being redesigned for Odoo 18, these changes need to be applied to all the occurrences of these snippets across the front-end.
Account report actions such as Excel download and document copy are now grouped in a settings-style menu next to the report title, making the report toolbar less cluttered. Labels were made clearer, and the document copy option now only appears when the Documents app is installed.
Original PR description
Current behavior: Currently, there is a dropdown button next to the first button visible in account reports, where buttons like 'XLSX' and 'Save' are displayed. Buttons with always_show are displayed next to the first button. Also, 'Save' is displayed even when Documents is not installed. Desired behavior: - The buttons displayed inside the button dropdown should be moved to a cog dropdown to the right of the title instead. - 'XLSX' should be renamed to 'Download Excel' and 'Save' should be renamed to 'Copy to Documents'. - 'Copy to Documents' should only be displayed if the module Documents is installed. Approach: A new component AccountReportCogMenu was created. The buttons bar only displays the first button and always_show buttons (singleButtons) while the cog menu displays the groupedButtons. Before adding 'Copy to Documents' to options['buttons'], we check if 'documents.document' is in self.env. A few tests were also updated to reflect the change. task-3986441
Users can now download Mexican CFDI XML invoice files directly from the invoice Download button, making it easier to retrieve required tax documents. The update also streamlines invoice download handling for Chilean point-of-sale electronic invoicing to make downloads more reliable.
Original PR description
Add the possibility to download XML CFDI files from the "Download" button of invoice(s). task-id: 3761762
Marketing campaign email templates can no longer be deleted while they are still used by an automated marketing activity. This prevents broken or unexpected campaign behavior and helps keep active automation flows reliable.
Original PR description
This commit prevents the user to delete a `mailing.mailing` if it's linked to a `marketing.activity`. The deletion of such records led to weird behaviors in automated marketing campaigns, so we now block their deletion. task-4014585
This update reorganizes how tax calculations are handled so the logic is simpler, more consistent, and easier to maintain across accounting, localization, and point-of-sale areas. Business users should see little direct change, but it reduces the risk of inconsistencies and makes future tax-related updates easier to deliver.
Original PR description
- merge '_prepare' and '_eval' methods all together - keep records in python code - remove the accounting-specific code from the main taxes computation method
This update replaces older behind-the-scenes website Helpdesk code with a more modern approach. It reduces reliance on an extra software library, helping keep the product simpler to maintain without changing the visible Helpdesk experience.
Original PR description
This PR aim to convert all jQuery code into Vanilla JS in website_helpdesk, this way we will reduce the dependency of jQuery in Odoo codebase. task-3770362
The public Knowledge website code was updated to rely less on older supporting technology. This helps keep the platform easier to maintain and supports ongoing modernization without changing the user-facing experience.
Original PR description
This PR aim to convert all jQuery code into Vanilla JS in website_knowledge, this way we will reduce the dependency of jQuery in Odoo codebase. task-3770362
This update modernizes how several Odoo apps recognize and handle database errors. It should make the affected processes more reliable and easier to maintain, with no expected change to day-to-day workflows.
Resolved issues and error corrections
A bug in Odoo Studio prevented newly added datetime fields from properly applying the setting that hides seconds. This fix ensures business users can change the seconds display option immediately without needing to reset the field widget.
Original PR description
After making changes in community PR: https://github.com/odoo/odoo/pull/162373 The datetime widget was not being applied when we dragged and dropped a datetime field from the studio. Steps to reproduce: - Open the Sales module and toggle Studio. - Drag and drop a datetime field into the list view. - Try to tick and untick the showSeconds option. Observed behavior: When ticking and unticking the showSeconds option, the seconds are not hiding before resetting the widget. Expected behavior: The seconds should be hidden when we tick and untick the showSeconds option without resetting the widget. After this commit, the datetime widget will be applied when we drag and drop a datetime field from the studio and untick the showSeconds boolean. Task-2517675
This update fixes an intermittent failure in an automated accounting test by ensuring a deleted transaction is fully removed before the next action starts. It helps keep validation checks stable without changing customer-facing accounting behavior.
Original PR description
The tour test_tour_invoice_creation_from_reco_model fails sometimes. The issue is that we try to click on the action to open the move before the previous deletion has been in effect. It seems a step_delay was introduced to mitigate the issue, but it wasn't the right way. We should instead ensure that the move is indeed deleted before clicking on the next action. runbot-72323
This fix prevents the WhatsApp module from depending on an optional website routing component when creating template-related links or identifiers. It improves reliability for businesses using WhatsApp without installing extra website features.
Original PR description
Steps to reproduce: install whatsapp without http_routing and run the test "test_member_creation". Use _slug instead of _slugify. _slug comes with base and is overriden in http_routing to use _slugify.
Code cleanup and technical improvements
This update centralizes how browser tabs communicate with each other, making the behavior easier to maintain and more consistent across Odoo. It is an internal cleanup with minimal direct impact on day-to-day users, but it supports reliability for features that work across multiple open tabs.
Original PR description
The BroadcastChannel browser API is now used in multiple places, it makes sense to centralize the logic within the existing multiTabService. Task-3244140 [Community PR](https://github.com/odoo/odoo/pull/134666)
Miscellaneous changes
task-3373525 Forward-Port-Of: odoo/enterprise#67569 Forward-Port-Of: odoo/enterprise#45062
Original PR description
task-3373525 Forward-Port-Of: odoo/enterprise#67569 Forward-Port-Of: odoo/enterprise#45062
Reason for failure: - Here when we create the task we try to send mail to users attached to the task (a Signup Mail) where a hash is generated. - Unix dates start from ```1970-1-1 00:00:00(epoch date)```. When we try to generate timestamp to the pre-epoch dates we get a negative number. In hashing process we convert timestamp into bytes using ```into_bytes```. - In the test case we have use ```fakegun``` to freeze time to 1900. While converting this negative number we get an ```Overflow Err
Original PR description
Reason for failure: - Here when we create the task we try to send mail to users attached to the task (a Signup Mail) where a hash is generated. - Unix dates start from ```1970-1-1 00:00:00(epoch date)```. When we try to generate timestamp to the pre-epoch dates we get a negative number. In hashing process we convert timestamp into bytes using ```into_bytes```. - In the test case we have use ```fakegun``` to freeze time to 1900. While converting this negative number we get an ```Overflow Error``` because we can't convert negative integer(essentially decimal) into unsigned(it can be only signed int).We can actually convert negative number into signed using an argument "signed=True" (but this serves no real use-case in real scenarios). Fix: - Choosing not to send the mail using context "mail_auto_subscribe_no_notify". task-4075283 Forward-Port-Of: odoo/enterprise#67358
How to reproduce: ================= - Enable "Storage Locations"; - Create a product with a barcode and add some qty in a sublocation (e.g.: 10 products in Shelf 1); - Create an internal transfer from WH/Stock to WH/Stock for this product for at least 2 qty; - Confirm the internal transfer and open it in the Barcode app; - You can see you have one line, from WH/Stock/Shelf 1 to WH/Stock (if we follow previous example); - Scan one time the product, then scan another location (eg.: shelf2),
Original PR description
How to reproduce: ================= - Enable "Storage Locations"; - Create a product with a barcode and add some qty in a sublocation (e.g.: 10 products in Shelf 1); - Create an internal transfer…
How to reproduce: ================= - Enable "Storage Locations"; - Create a product with a barcode and add some qty in a sublocation (e.g.: 10 products in Shelf 1); - Create an internal transfer from WH/Stock to WH/Stock for this product for at least 2 qty; - Confirm the internal transfer and open it in the Barcode app; - You can see you have one line, from WH/Stock/Shelf 1 to WH/Stock (if we follow previous example); - Scan one time the product, then scan another location (eg.: shelf2), the line will be split. => Issue here: the line for the remaining quantity has WH/Stock as source location instead of Shelf 1. Expected behavior: ================== The source location of the split line doesn't change. Explanation: ============ When a line is split, a new line is created for the remaining quantity. But the issue is, when a new line is created, it uses the picking's source location (or the previous scanned source) as the default location. OPW-4016136 Forward-Port-Of: odoo/enterprise#67410 Forward-Port-Of: odoo/enterprise#66360
This commit aims to: - make more coherent information displayed in the list view and the kanban view of the bank reconciliation widget. To do so we now display `ref`, `bank_account` `foreign_currency` and `amount_currency` within the "Manual Operations" tab. - display information even after the statement line is reconciled. To do so we made the "Manual Operations" tab visible even after validation, with its information in readonly. - make the cog menu available even if the transaction if vali
Original PR description
This commit aims to: - make more coherent information displayed in the list view and the kanban view of the bank reconciliation widget. To do so we now display `ref`, `bank_account` `foreign_currency` and `amount_currency` within the "Manual Operations" tab. - display information even after the statement line is reconciled. To do so we made the "Manual Operations" tab visible even after validation, with its information in readonly. - make the cog menu available even if the transaction if validated. task-3996739 Forward-Port-Of: odoo/enterprise#67571 Forward-Port-Of: odoo/enterprise#65313
With an ES Company Open Tax Report Select Report > Generic Tax Report Export "VAT Record Books" Issue: Numbers are exported as string, while the system should export as number, to let users execute operations on the resulting workbook opw-4029478 Forward-Port-Of: odoo/enterprise#66335
Original PR description
With an ES Company Open Tax Report Select Report > Generic Tax Report Export "VAT Record Books" Issue: Numbers are exported as string, while the system should export as number, to let users execute operations on the resulting workbook opw-4029478 Forward-Port-Of: odoo/enterprise#66335
Manual Fowardport latam task 1097 Forward-Port-Of: https://github.com/odoo/enterprise/pull/48754 Forward-Port-Of: https://github.com/odoo/enterprise/pull/47967 Forward-Port-Of: odoo/enterprise#52999
Original PR description
Manual Fowardport latam task 1097 Forward-Port-Of: https://github.com/odoo/enterprise/pull/48754 Forward-Port-Of: https://github.com/odoo/enterprise/pull/47967 Forward-Port-Of: odoo/enterprise#52999
Self-withholding taxes should not be included in tax amounts. This was done when sending through Carvajal, so we should do it with a direct DIAN implementation too. See the Carvajal commit: https://github.com/odoo/enterprise/commit/af8f364cc1f09cc1f9159b326a7f59c6524380be Related to: opw-3958518 Forward-Port-Of: odoo/enterprise#66988
Original PR description
Self-withholding taxes should not be included in tax amounts. This was done when sending through Carvajal, so we should do it with a direct DIAN implementation too. See the Carvajal commit: https://github.com/odoo/enterprise/commit/af8f364cc1f09cc1f9159b326a7f59c6524380be Related to: opw-3958518 Forward-Port-Of: odoo/enterprise#66988
When shifts are group by in the planning, the open shift and total rows are not disabled. In this commit, we have disabled the total row and all rows except those at group level 0. task-3981814 Forward-Port-Of: odoo/enterprise#67443 Forward-Port-Of: odoo/enterprise#66634
Original PR description
When shifts are group by in the planning, the open shift and total rows are not disabled. In this commit, we have disabled the total row and all rows except those at group level 0. task-3981814 Forward-Port-Of: odoo/enterprise#67443 Forward-Port-Of: odoo/enterprise#66634
version - 16.0 Steps: -Install rental app. -Activate the date picker from the web-editor. -Add the start date and end date from that. -Select some attribute of the product. Issue: -When any user adds the start date and end date from the date picker and after that, the user adds the other attribute(filter) of the product, that selected rental period gets cleared automatically. Cause: -The selected rental period (start and end dates) is not persisted when the page refreshes or upda
Original PR description
version - 16.0 Steps: -Install rental app. -Activate the date picker from the web-editor. -Add the start date and end date from that. -Select some attribute of the product. Issue: -When any user adds the start date and end date from the date picker and after that, the user adds the other attribute(filter) of the product, that selected rental period gets cleared automatically. Cause: -The selected rental period (start and end dates) is not persisted when the page refreshes or updates due to attribute selection. -The input fields for the rental period are not updated properly, causing the dates to be reset. Fix: Extend the '_onChangeAttribute' method to read the start_date and end_date parameters from the URL. Update the hidden input fields for 'start_date' and 'end_date' with the values before applying the attribute changes. opw-3774060 Forward-Port-Of: odoo/enterprise#67495 Forward-Port-Of: odoo/enterprise#64962
Before this **PR**: The default filter for the GST Return Period shows the previous month or quarter. After this **PR**: The default filter for the GST Return Period shows the current as well as the previous month or quarter. **task**-4014267 Forward-Port-Of: odoo/enterprise#65629
Original PR description
Before this **PR**: The default filter for the GST Return Period shows the previous month or quarter. After this **PR**: The default filter for the GST Return Period shows the current as well as the previous month or quarter. **task**-4014267 Forward-Port-Of: odoo/enterprise#65629
14 changes
New functionality added to Odoo
This update enables Danish companies to export intrastat reports directly in the official format required by Statistics Denmark. Users can now generate compliant Excel files for arrivals, dispatches, or both with a single click, eliminating manual formatting and reducing errors in intrastat reporting submissions.
Original PR description
Overrides the generic xlsx export button on the intrastat report for Denmark. When pressing the button, it now generates the official documents that can then be uploaded on the official website "Statistics Denmark" for intrastat reporting. Depending on the filter 'intrastat type', the following use cases are possible: Intratat type filter | Document generated ----------------------------------------------- arrivals | official xlsx for arrivals dispatches | official xlsx for dispatches none or both | zip file containing both xlsx The xlsx files that are generated follow the official format, which can be found at this address in the file examples 'Intrastat eksport/import Excel Line' https://www.dst.dk/en/Indberet/hjaelp-til-indberetning/om-idep-web/intrastat task-3976189
Enhancements to existing features
The Shop Floor view has been optimized to load work order information much faster by deferring the loading of operation notes until users actually need them. Previously, all operation notes were loaded upfront, which caused significant slowdowns especially when they contained images. Now the system only fetches these notes when a user clicks on the Worksheet or Quality Check buttons, resulting in approximately 95% faster load times.
Original PR description
## Issue Shop Floor can show performance issues even with the default limit of 40. This is mostly due to the `operation_note` fetched for the work orders. Moreover, as it's a HTML field, it has to be…
## Issue Shop Floor can show performance issues even with the default limit of 40. This is mostly due to the `operation_note` fetched for the work orders. Moreover, as it's a HTML field, it has to be sanitized by the ORM - which is slow considering users tend to put base64 encoded images in it. ## Analysis It is not necessary to fetch the `operation_note` for all displayed work orders as it's only shown when an user will click on the *Worksheet* button or a *Quality Check* button. ## Solution In case there is no PDF or Slide, the *Worksheet* button is only displayed when there's an `operation_note`. Therefore, we introduce a `has_operation_note` field to keep that behavior (refer to the Community commit). When a user clicks on a *Worksheet*/*Quality Check* button, we fetch the `operation_note` from the backend and cache it so we don't need to send another request later on. ## Benchmarks Benchmarks are done calling `web_search_read` on a database containing base64 images. | Displayed MO | Before | After | Speed up | |-------------|---------|--------| --------| | 40 | 8.19 s | 400 ms | ~95% | 100 | 23.9 s / MemoryError | 900 ms | ~96% ## References opw-3983324 -- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
Resolved issues and error corrections
This update fixes multiple tax-related issues across Odoo's accounting and point-of-sale systems. The changes address tax calculation, rounding, and processing in bank reconciliation, EDI (Electronic Data Interchange) modules for various countries, and POS systems. These fixes ensure accurate tax handling in financial transactions and compliance with regional tax requirements.
Original PR description
opw-3844018
This update resolves a bug in the maintenance module where schedule dates with milliseconds were not being read correctly from the database. The fix changes how dates are processed to ensure they're handled properly regardless of their format, improving the reliability of maintenance scheduling.
Original PR description
## Before this commit: The schedule date is converted into a string in SQL and then parsed in Python using `Datetime.to_string`. However, it does not support parsing datetime with trailing milliseconds, such as '2024-05-22 10:09:45.5'. ## After this commit: Do not convert the schedule date to a string but put it in a PostgreSQL Array instead. Psycopg2 will convert it into a datetime object automatically, similar to the ORM's behaviour. opw-3932891 Forward-Port-Of: odoo/enterprise#67469 Forward-Port-Of: odoo/enterprise#63065
This fix improves how the system handles error messages when creating a Brazilian tax account with Avatax. Previously, the system would crash when receiving certain types of error responses. Now it gracefully handles all response formats, providing clearer error messages to users instead of technical errors.
Original PR description
Errors returned by Avatax when creating an account are not consistent. Sometimes the 'message' key contains a string with JSON. Other times it's a human-readable string with an error message. And…
Errors returned by Avatax when creating an account are not consistent. Sometimes the 'message' key contains a string with JSON. Other times it's a human-readable string with an error message. And other times it's a non-descript error that we replace with a more user-friendly error to guide users towards the most common fix.
Before this fix a traceback appeared when a human-readable error string was returned without 'unhandled error occured':
```
File ".../l10n_br_avatax/models/res_config_settings.py", line 85, in create_account
result = json.loads(result['message'])
File "/usr/lib/python3.10/json/__init__.py", line 346, in loads
return _default_decoder.decode(s)
File "/usr/lib/python3.10/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python3.10/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
```
This makes the error handling more robust by first attempting to decode the string as JSON. If that fails we fall back on the other two scenarios.
A new test class is included that provides examples of each type of response.
opw-4067842This fix corrects a bug where component quantities were incorrectly displayed and consumed in manufacturing orders when producing tracked products. Previously, when registering production, some components would show incorrect quantities (e.g., "5/1" instead of "1"), causing the system to consume more materials than needed. This fix ensures component quantities are properly updated to match the actual production quantity.
Original PR description
### Steps to reproduce: - Create a storable product P tracked by SN - Create a consumable (or a storable with 5 units on hand) product COMP 1 and a storable product COMP 2 (without units on hand) -…
### Steps to reproduce:
- Create a storable product P tracked by SN
- Create a consumable (or a storable with 5 units on hand) product
COMP 1 and a storable product COMP 2 (without units on hand)
- Create a BOM for P with an operation op 1 and two component lines:
- 1 x COMP 1 consumed in op 1
- 1 x COMP 2 consumed in op 1
- Create and confirm an MO for 5 units of P
- Go to the shopfloor and click on register production.
**> the qty is updated to 1 on COMP 2 but to 5/1 on COMP 1**
As such, if you click on the 5/1, 5 units of COMP 1 will be consumed to produce only one unit of P
### Cause of the issue:
When you confirm the MO, since Comp 1 is a consumable its quantity is automatically set to 5.0 because reservation are bypassed. On the other hand, since Comp 2 is a storable without on hand qty, its quantity stays at 0.0. When you click on register production, or on the plus sign will trigger a call of the "_set_qty_producing" method. This call will update the qty_producing of the final product:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1214-L1218
However, the update of the qty consumed by the raw move will be bypassed because of these lines:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1225-L1226
https://github.com/odoo/enterprise/blob/0646022d7726a0cc183b191ca5be4e4bb4368f93/mrp_workorder/models/stock_move.py#L10-L13
And the quantity will therefore not be updated by these lines:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1228-L1231
However, as the quantity is not set to 0, it will be displayed as "quantity/should_consume_qty" and clicking on the raw move line will not update the quantity so 5 units will be marked as consumed ("picked").
Community: https://github.com/odoo/odoo/pull/168205
opw-3887580
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix improves the error handling when Amazon sales orders encounter missing location information. Instead of showing a confusing technical error, users now see a clear message indicating which record has the problem and what information is missing. This makes it easier for support teams to identify and resolve location configuration issues.
Original PR description
Before this commit: An exception was raised if the location was failing to retrieve necessary information. Example: ``` ElementTree.SubElement(ship_from_, 'AddressFieldOne').text = location_.street[:180] TypeError: 'bool' object is not subscriptable ``` After this commit: A more user-friendly error message is shown indicating more clearly the problematic record and missing information opw-3936775
This fix resolves a crash that occurred when validating SEPA payments after updating a bank journal's SEPA format settings. Previously, payments created before the format change would fail with a technical error because they lacked required data fields. Now the system provides a clear user-friendly error message explaining what data is missing, allowing users to take appropriate action.
Original PR description
When switching a bank journal to the new SEPA Pain version, existing payments in the batch may lack required data, such as the UETR field. ### Steps to Reproduce 1. Install `l10n_be`,…
When switching a bank journal to the new SEPA Pain version, existing payments in the batch may lack required data, such as the UETR field. ### Steps to Reproduce 1. Install `l10n_be`, `account_accountant`, and `account_sepa_pain_001_001_09`. 2. In the settings, enable 'SEPA Credit Transfer (SCT)'. 3. Switch to a Belgian company. 4. Set up an IBAN bank account on the bank journal. 5. Ensure a partner has an IBAN bank account defined. 6. Create and confirm an outgoing payment for that partner, setting the payment method to 'SEPA Credit Transfer'. 7. In the Outgoing Payments tab of the bank journal, set the SEPA Pain Version to 'New generic version'. 8. Create a batch payment with the payment you just created. 9. Attempt to validate it. ### Expected Result The payment should be validated successfully. ### Actual Result A traceback occurs: `TypeError: Argument must be bytes or unicode, got 'bool'` ### Cause The payment in the batch was created before the SEPA PAIN version was updated on the bank journal. Consequently, the payment is missing some necessary data (specifically, the UETR field is not set) required for the new SEPA version. opw-3973374 Forward-Port-Of: odoo/enterprise#67426 Forward-Port-Of: odoo/enterprise#65614
This fix corrects an issue where invoices with due dates older than 60 days were not appearing in the "Amount to Settle" section of the Aged Receivable report. The report was incorrectly filtering out older invoices due to a domain restriction. Now all overdue invoices, regardless of age, will display correctly in the report.
Original PR description
The amount to settle was not shown in the tree view for the older column due to the [domain…
The amount to settle was not shown in the tree view for the older column due to the [domain prepared](https://github.com/odoo/enterprise/blob/17.0/account_reports/models/account_aged_partner_balance.py#L380-L392) for the older column being capped between 30 days, similar to the other columns(1-30, 31-60, etc.) in the Aged Receivable report. **Step to reproduce:** - create an invoice with due date 150 days back - open the Aged receivable report and find that invoice - The record of `account.move.line` will not be shown in the tree view (Amount to settle) This patch handle the domain for `period5`. **Before fix:**   **After fix:**  OPW - 4048535
This fix resolves an error that occurred when displaying sales orders with external tax calculation (like AvaTax) combined with custom tax group settings. The system now correctly handles the tax totals display by ensuring the subtotal labels match the actual tax groups being shown, preventing frontend errors when users view their orders.
Original PR description
When a sales order has it's tax calculated externally (e.g avatax), but a preceding_subtotal is present on a selected product tax group (case of internal tax computation). The frontend will raise an…
When a sales order has it's tax calculated externally (e.g avatax), but a preceding_subtotal is present on a selected product tax group (case of internal tax computation). The frontend will raise an error when trying to display the tax_totals.
Steps to reproduce:
1. Go to general setting > enable avatax > save.
2. Go to accounting > configuration > tax groups > set preceding subtotal column (hidden) of a chosen tax groups.
3. Go to sales > New
4. In the quotation form > select a product and set its tax to the previously chosen tax groups.
5. In the Other Info tab of the form > set fiscal position as avatax.
6. Finish the quotation creation > save.
7. You can open it in the order lines tab and see the error being raised.
cause:
As the taxes are calculated externally (i.e avatax). sale_external_tax module "will create a single tax group" (cf _compute_tax_totals doc). But the subtotals_order is not overwritten. In the fronted side, the TaxTotalsComponent will try to display each subtotal values, with preceding_subtotal label as keys stored in subtotals_order, but only one tax groups is present with a default subtotal label ('Untaxed Amount'). Resulting to reads in groups_by_subtotal dict with None result thus raising "Uncaught Promise > Invalid loop expression: "undefined" is not iterable".
solution:
Overwrite subtotals_order with a single default value 'Untaxed Amount'
opw-4009957This fix resolves critical issues where IoT devices couldn't print documents from all companies in multi-company setups. Previously, IoT devices were limited to specific company channels, causing print failures when switching companies or using devices without a company assignment. The system now uses a single unified channel, making IoT printing more reliable and accessible across your entire organization.
Original PR description
Using distinct websockets (ws) per company cause a lot of diffent issues, for example: ## Issue this PR solve: ### Multi-company: Assume we have an IoT with no company set. In this case, it should be…
Using distinct websockets (ws) per company cause a lot of diffent issues, for example: ## Issue this PR solve: ### Multi-company: Assume we have an IoT with no company set. In this case, it should be able to print from any company. In practice, it is not the case as the IoT will listen to the channel of the first company, so it will always fail if the user company is not the first one. Same goes if we have child companies, if C2 is a child company of C1, then C2 should be able to print too. With current code it is not the case as C1 and C2 will have distincts channels ### Change of IoT company: When the IoT start, it makes a call to know its channel (see iot/setup route). However, if we change the company set on the IoT, it should change its channel to match the one of newly set company. In practice it is not the case and will only happen on the next iot/setup call (which happen each 3 seconds call in theory IF new devices are detected) ### Simplicity Help simplifying the code as it was sometime complicated to be get the right websocket. For example, when the IoT reply back that the operation completed, see `/iot/printer/status` route. Relying on the IoT device company might be wrong as if no company is set, we don't know the company that the user who did the request is, so we might send on the bus on the wrong channel. In this case, the document did print but the pop-up will still pop ### Visibility The iot.channel had no practical way to be browsed as there is no view defined for this model. The only feasible way to get its data for a functional would be to run a server action or create a view. Using a system parameter is more practical and only accessible for admin users ## Downside of this PR: - system parameter could be modified manually - websocket send/receive more messages - stability: to ease the transition, I tried to get the existing ws channel using basic heuristics, but it might be wrong (if a company other than the first is set on the IoT). In the worst case, they will have to restart their IoT to get the new channel opw-4038176
The "Hide Lines at 0" feature in financial reports now works correctly when reports contain informational columns like partner VAT or country of origin. Previously, these text columns prevented the feature from hiding empty amount lines. The fix ensures the feature only considers numeric and monetary columns when deciding which lines to hide, ignoring informational text columns.
Original PR description
Some reports display some informational columns (like the VAT for a partner, or the country of origin). These columns sometimes prevent the `Hide Lines at 0` option to correctly do its work: the desired behavior of this option is to hide the lines where the amounts are null. It shouldn't care about the "informational" columns, that are usually always present This commit force the `Hide Lines at 0` feature to ignore columns displaying information other than float, integer of monetary ones. task-4006235
Fixed an issue where salary amounts displayed in job offers were not correctly labeled according to the pay frequency set in the salary structure. Previously, salaries calculated for bi-weekly or other non-monthly frequencies were incorrectly labeled as monthly amounts, causing confusion about actual compensation. The fix updates the salary label to accurately reflect the selected pay frequency.
Original PR description
To reproduce: ============= - on Salary structure type "Worker" change its "Default Scheduled Pay" to another value than monthly (bi-weekly). - on the contract templates, create a new one for that structure and set hourly Wage = 10$ - onrecruitment applications, generate an offer with that template Check the link > It should show 800$ (which is 10$ an hour * 40 hours a week * 2 for the bi-wkeely frequency) but still mention it is the monthly Salary (which should be 1600$) Problem: ======== - the salary displayed on the salary configurator doesn't take into account the frequency of the salary structure Solution: ========= - change the label to mention the frequency of the salary structure opw-3963698
Fixed a bug in the barcode app where users had to press backspace multiple times to erase quantity values. When incrementing quantities using the +1/-1 buttons, the system was storing extra decimal places that required multiple deletions. This fix removes those trailing zeros so users only need one backspace to clear the value.
Original PR description
Steps: ------- 1. go to any operations of th barcorde app 2. go to a specific line 3. change the quantity thanks to the +1 / -1 4. try to erase using backspace or the erase button Current behavior…
Steps: ------- 1. go to any operations of th barcorde app 2. go to a specific line 3. change the quantity thanks to the +1 / -1 4. try to erase using backspace or the erase button Current behavior before PR: ------ We need several backspaces to erase the value Desired behavior after PR is merged: ------- If the value is '3' for example, only 1 backspace should be needed. Explanation: ----- Incrementing will set the precision to the value specified, which mean 3 is actually stored as 3.00 on the Digipad, but parsing it as a Number in `_notifyChanges` will remove these trailing zeros. One solution would be to pass the string to the ORM instead of passing it a number, but this has the disadvantages to set the value as 3.00 visually (so the user still need to delete multiple zeros). The solution adopted removes the trailing zeros. Side note: This does not fix the inconsitency where the value displayed is "3" when the Digipad value id "3.". opw-4061351 Forward-Port-Of: odoo/enterprise#67330 Forward-Port-Of: odoo/enterprise#67279