Daily updates from Odoo
Thursday, April 17, 2025
56 changes · 18.0
Enhancements to existing features
Invoice batch sending now shows more accurate counts based on the delivery methods that can actually be used for each invoice. Peppol invoice handling is also more reliable, including better behavior when invoice formats are missing and clearer treatment of blocking send errors.
Original PR description
### [IMP] account: fix the summary of account.move.send.batch.wizard *: account_peppol, snailmail_account The summary was displaying wrong numbers of invoices. Indeed, it was computed on default…
### [IMP] account: fix the summary of account.move.send.batch.wizard *: account_peppol, snailmail_account The summary was displaying wrong numbers of invoices. Indeed, it was computed on default methods, instead of methods that are applicable to the move. For example, if a move was not possible to send through Peppol because the partner is not registered on the network, it was still displayed in the summary of the batch sending (then not used when the async processing happened). We also always put email as a fallback, even if no email is set, since it can be added through the wizard. task-no (review with TSB/PMAX) ---------------------------- ### [FIX] account_peppol: Remove 'skipped' state of Peppol moves This state doesn't really make sense. It only happens when there is an error while generating the XML file to send, which can be considered as a blocking error. task-no ---------------------------- ### [FIX] account_peppol: fix batch send of Peppol invoices when no format set In previous commit[1], we set the BIS3 format on invoices that were meant to be sent trough Peppol, even if no invoice_edi_format was set on the Partner. This commit fixes some cases when sending multiple invoices with no invoice_edi_format but Peppol as default sending method ended up not being sent. [1]: https://github.com/odoo/odoo/commit/84a0b81a258262e3bb9dbaa9c9f37796303a9dad task-no
This pull request bundles several usability and reliability updates across Odoo, including clearer product availability for delivery and click-and-collect, better payment deletion guidance, corrected POS receipt links, and improved messaging membership behavior. These changes reduce customer-facing errors, improve staff workflows, and make reports and website interactions behave more consistently.
Original PR description
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 change adds a reusable way for Odoo to find the default sale orders linked to a process. It makes future customizations easier and safer for businesses that extend sales workflows.
Original PR description
in this commit: - added a helper function to get sale order ids which can be override in inherited models. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Product forms now avoid loading a very large Intrastat code list into the browser. This reduces memory use and helps users navigate product records more smoothly, especially in databases with many Intrastat codes.
Original PR description
Previously, the intrastat_code_id was filtered by checking against a large list that is sent to the frontend. This caused huge memory usage due to the list being used in many objects and the list itself being large, around 10k items. This memory leak caused slowness in the frontend while going through the product form views. Currently, the list is not being sent. The domain itself is evaluated from the frontend without sending a list. This reduces memory footprint and slowness.
The Knowledge portal search experience has been adjusted so results better match whether users are searching from the portal or the main back office. This should make it easier for portal users to find the right articles without seeing less relevant internal results.
Helpdesk tickets that include billable timesheets can now be invoiced more easily once they are solved. Timesheets are automatically validated when a ticket reaches the solved stage, and a new Create Invoices action in the helpdesk overview helps teams bill completed work faster and with fewer manual steps.
Original PR description
Before this commit : - Timesheets are not validated automatically when a ticket is solved . - No available button to create invoices for solved tickets in the helpdesk overview. After this commit: - Timesheets linked to a helpdesk ticket get validated when ticket is moved to Solved stage. - A 'Create Invoices' button is added to invoice solved tickets in helpdesk overview. Task id: 4243781
Resolved issues and error corrections
Point of Sale receipts now show the tax label that applies after a fiscal position changes the tax. This prevents mismatches between receipt line labels and tax details, reducing confusion for cashiers and customers.
Original PR description
When using a fiscal position the tax group labels on the receipt order lines where not adapted correctly Steps to reproduce: ------------------- * Create 2 taxes A and B * For each tax go to their corresponding tax group and set the label to "A" and "B" * Create a fiscal position that will match A on B * Add the fiscal position to the PoS * Create a new order and add a product that uses the A tax * Activate the fiscal position * Validate the order and go to the receipt > Observation: The orderline will show the label A but the order tax detail will correctly show the label B Why the fix: ------------ When generating the display data for the orderline we need to first map the taxes according to the fiscal position. opw-4579223
Portal users can now search mail messages by related recipients more reliably. This prevents searches from bypassing the intended mail-specific logic, improving consistency when users look up conversations or followed records.
Original PR description
When searching `message_partner_ids`, we have a search method that will replace the domain, so `_condition_to_sql` will not be called for that field. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes Point of Sale database upgrades process records in smaller batches, avoiding very slow updates on large sales databases. For affected customers, upgrade time can drop from several hours to around ten minutes, reducing downtime and migration risk.
Original PR description
Before this commit odoo/odoo@5bb76504425082cfd654a2860350aa94d9782dbd, the update query for UUID deduplication used…
Before this commit odoo/odoo@5bb76504425082cfd654a2860350aa94d9782dbd, the update query for UUID deduplication used [cr.split_for_in_conditions()](https://github.com/odoo/odoo/blob/13133b40eb545c4d4f7427c2145b3d57074fa74b/odoo/sql_db.py#L402-L405) to chunk IDs properly for the `WHERE id IN (...)` clause. However, after the mentioned commit, all IDs are passed at once, especially when `fetchmany()` returns up to 1 lac records. This significantly slows down the update query due to large `IN` clauses and memory overhead. To address this, reduce the processing chunk from 1lac to 10k IDs. This reduces update time from over 2 hours to under 10 minutes in practice for recordset shown below: ```sql apan_2760231=> select count(*) from pos_order; count -------- 146885 (1 row) apan_2760231=> select count(*) from pos_order_line; count -------- 378860 (1 row) apan_2760231=> select count(*) from pos_payment; count -------- 184679 (1 row) ``` Logs: Before fix (Almost 3 hrs): ```py 2025-04-17 07:06:31,094 31 INFO db_2760231 odoo.modules.migration: module point_of_sale: Running migration [1.0.2>] post-deduplicate-uuids 2025-04-17 10:08:39,397 31 INFO db_2760231 odoo.addons.base.models.ir_module: module point_of_sale: loading translation file /home/odoo/src/odoo/18.0/addons/point_of_sale/i18n/nl.po for language nl_NL ``` After fix (reduces to 10 mins): ```py 2025-04-17 11:29:44,294 23 INFO apan_2760231_18.0 odoo.modules.migration: module point_of_sale: Running migration [1.0.2>] post-deduplicate-uuids 2025-04-17 11:39:58,582 23 INFO apan_2760231_18.0 odoo.addons.base.models.ir_module: module point_of_sale: loading translation file /home/odoo/src/odoo/18.0/addons/point_of_sale/i18n/nl.po for language nl_NL ``` opw-4734894 upg-2760231 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a small issue in event email processing when multiple records are handled at once. It helps ensure event-related email updates are applied to the correct record, reducing the risk of inconsistent behavior in less common batch scenarios.
Original PR description
Looping on self, but updating self. As this method is generally called on a singleton recordset no error has been reported but better safe than sorry.
Clearing the Point of Sale cache could leave some reward lines without their related coupon data, causing the POS to get stuck while loading. The fix cleans up those inconsistent order lines during this debug cache-clear scenario, helping the POS recover without affecting normal sales workflows.
Original PR description
After clearing the cache you can have inconsistent reward lines that have no coupon associated with them. Steps to reproduce: ------------------- * Create an order and add any reward (Buy X Get Y for example) * Go to the backend to make sure the order is saved in the database * Go back to the POS and clear the cache > Observation: You are stuck on the loading screen Why the fix: ------------ To avoid having inconsistent reward lines that have no coupon associated with them, we delete all the lines of an order that contains wrong data. As this is not supposed to happen (clearing the cache is a debug functionality), we can safely delete the lines because it's wont impact the real workflow of the users. opw-4655422
Duplicating a restaurant point of sale no longer automatically copies its floor plan. This prevents orders placed at matching tables in duplicated restaurants from mixing or overwriting each other, reducing confusion for restaurant staff.
Original PR description
The original issue was that when you duplicated a pos restaurant, it would also duplicate it's floors. And when you would make an order on the same table in the 2 restaurant the second one would take the first one and override it. Steps to reproduce: ------------------- * Duplicate a restaurant * Make an order on the same table in the 2 restaurant * The second one will take the first one and override it > Observation: The new order contains the first order lines in it if you check the db Why the fix: ------------ To avoid confusion when duplicating restaurant we prevent duplicating the floor plans automatically. opw-4536327
Accounting entries now include the country of the related commercial partner. This prepares the accounting module for improved filtering and reporting by partner location.
Original PR description
The commercial partner country field is required for later improvements namely filtering or reports related ones. --- task-4725240 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Creating a new contact from autocomplete could fail when a lowercase GST or VAT number was entered and selected from the suggestions. The fix normalizes those tax identifiers during lookup, preventing the error and making contact creation more reliable.
Original PR description
The system throws an error due to missing `name` in values during RPC `onchange` call Steps to Reproduce: 1. Open the `Contacts app` and click `New`. 2. Enter `32aadcs3224n1zf` as the name. 3. From the autocomplete dropdown, select a company. Error: `KeyError: 'name'` Solution: Added upper() transformation for GST and VAT numbers during autocomplete search to normalize input and avoid missing key errors. Sentry - 6327760196 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The sale details report now calculates totals based on the specific POS configuration, preventing blackbox-related rules from affecting regular POS setups. This helps businesses see accurate sales totals when the blackbox module is installed but not used for every POS configuration.
Original PR description
Before this commit, if the POS blackbox module was installed, the sale details report would display total price in price included because of an override. In this commit, we add the config id to the method computing this price so that the blackbox module can override this computation only if the config is a blackbox one. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Mobile users can now expand record dialogs, such as subtasks, just like they can on desktop. This makes related areas like the chatter accessible on phones and improves consistency across devices.
Original PR description
Steps: - Install `project` - Open a task - Create a subtask - Try to access chatter - It works on desktop, because you have the expand button - It doesn't work on mobile This commit adds this button on mobile too opw-4631478
Fixed an issue where sales orders could fail when customers used coupon programs that had multiple rewards. The system now selects the best available global discount reward, helping sales teams apply coupons reliably without interruptions.
Original PR description
This error occurs when a user creates multiple rewards of the same program using below steps : Steps to Reproduce : - Install module `sale_management` and `sale_loyalty. - In Products, go to Discount & Loyalty. - Create two new `Discount & Loyalty` with the program type `Coupons` and `Generate coupons. ` - Add multiple rewards to one coupon program. - Create a sale order and apply a coupon code from the first Discount & Loyalty program. Repeat the process with the coupon code from the second program. ValueError : Expected singleton: loyalty.reward(3, 4, 5) This error occurs when the system tries to fetch global_rewards but receives multiple values instead of a single record. This commit resolves the error by ensuring that only the global reward with the highest discount is selected. Sentry - 6417784661 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Physical gift cards sold and invoiced through Point of Sale now keep the entered card code and associated customer. This prevents missing or incorrect gift card records in the backend, making follow-up and redemption more reliable.
Original PR description
When selling a physical gift card, and invoicing it. The code and partner id where not taken into account. Steps to reproduce: ------------------- * Open PoS * Add a gift card to the order * Click on selling a physical gift card * Enter any code * Validate the order and invoice it > Observation: If you check the gift card in the backend, you will see that the code and partner id are not set correctly. Why the fix: ------------ When updating the rewards, the code and partner id were never set. opw-4597330
Fixed an issue where applying a global discount after a fixed product-specific loyalty reward could incorrectly increase the reward amount and make the final Point of Sale total too low or even negative. The checkout total now stays accurate by keeping fixed rewards at their intended value while applying the global discount only to the remaining amount.
Original PR description
Steps to reproduce ------------------ - Create a product with price $80 - Create a fixed discount reward for this product with $40 - In PoS config, enable global discount - In a new PoS order, add…
Steps to reproduce ------------------ - Create a product with price $80 - Create a fixed discount reward for this product with $40 - In PoS config, enable global discount - In a new PoS order, add the product created in the first step and observe that we now have 2 orderlines, the product at $80 and the discount at $40. Total amount remaining to pay is $40 - Add a global discount of 50% -> At this point, we are expecting to apply the 50% discount on the remaining $40, and hence, a discount of $20, which changes the order's total price to $20. We also expect the fixed discount line of $40 to remain at $40, as it's a fixed price discount. Indeed, we now see a $20 global discount as an orderline, but the $40 fixed discount has changed its value from $40 to $53.33, and thus, the total amount has decreased to $6.67 instead of $20 -> A corrupted final amount!! In some other pricing configs, this final total amount will even become negative. Reason ------ After applying the global discount, we recalculate the value of the discounts to keep everything in sync, so we recompute the discount value of the fixed $40 discount in `_getRewardLineValuesDiscount`, and since now the total amount to pay, i.e. `order.get_total_with_tax()` is less then the value of the product (due to the global discount), `discountFactor` [1] of the fixed discount increases since `discountable` decreases. However, at the end when we calculate the new `unit_price` of this fixed discount, we multiply the `discountFactor` by the intial product price, i.e. by the price before the global discount, and hence, the amount of the fixed tax will be higher than expected, causing this buggy behavior. Below is a math representation of the bad (current) vs good (new) behavior: Bad: discountable = $60 = $80 - $20, where $20 is (total - fixed) * discount, i.e. (80-40)*0.5 discountFactor = $40 / $60 = 0.666666 price_unit = 0.666666 * $80 = $53.3333 (instead of $40) Good should be: discountable = $60 = $80 - $20, where $20 is (total - fixed) * discount, i.e. (80-40)*0.5 discountFactor = $40 / $60 = 0.666666 price_unit = 0.666666 * $60 = $40 I.e the good behavior should be multiplying the `discountFactor` by the the min of the remaining total price (after applying the global discount, so $60), and the initial value of the product (here $80). The formula has been updated accordingly. [1]: https://github.com/odoo/odoo/blob/76e2aa6b70d1fb03b8ce2f8e4a7e9c3d9425270f/addons/pos_loyalty/static/src/overrides/models/pos_order.js#L1163 opw-4622428
This fix makes the PDF quote builder target the correct sales order line views when customizing quote layouts. It prevents custom or Studio-added sections from being mistaken for the main order line area, reducing the risk of incorrect behavior in sales quote forms.
Original PR description
Description of the issue/feature this PR addresses: sale_pdf_quote_builder uses `//` for selection of the kanban and list views of the order lines rather than `/`. Current behavior before PR: However, in the upstream view the form view is declared first. If any extension, or studio change embeds a list or kanban view inside the form, the current selectors will pick that up instead of the list and kanban views associated with the order line. Desired behavior after PR is merged: More accurately select the correct insertion point of the inherited view OPW-4716782 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Adds example placeholder text for the Peppol EAS field so users know what information to enter when setting up electronic invoicing. This reduces confusion during partner setup and Peppol registration without changing the underlying process.
Original PR description
Add a placeholder for Peppol EAS field. task-4544834 (Part-of)
This fix makes Point of Sale database upgrades process records in smaller batches, avoiding very large updates that could run for hours. For large retail databases, the upgrade step can complete much faster and with less strain on the system.
Original PR description
Before this commit odoo/odoo@5bb76504425082cfd654a2860350aa94d9782dbd, the update query for UUID deduplication used…
Before this commit odoo/odoo@5bb76504425082cfd654a2860350aa94d9782dbd, the update query for UUID deduplication used [cr.split_for_in_conditions()](https://github.com/odoo/odoo/blob/13133b40eb545c4d4f7427c2145b3d57074fa74b/odoo/sql_db.py#L402-L405) to chunk IDs properly for the `WHERE id IN (...)` clause. However, after the mentioned commit, all IDs are passed at once, especially when `fetchmany()` returns up to 1 lac records. This significantly slows down the update query due to large `IN` clauses and memory overhead. To address this, reduce the processing chunk from 1lac to 10k IDs. This reduces update time from over 2 hours to under 10 minutes in practice for recordset shown below: ```sql apan_2760231=> select count(*) from pos_order; count -------- 146885 (1 row) apan_2760231=> select count(*) from pos_order_line; count -------- 378860 (1 row) apan_2760231=> select count(*) from pos_payment; count -------- 184679 (1 row) ``` Logs: Before fix (Almost 3 hrs): ```py 2025-04-17 07:06:31,094 31 INFO db_2760231 odoo.modules.migration: module point_of_sale: Running migration [1.0.2>] post-deduplicate-uuids 2025-04-17 10:08:39,397 31 INFO db_2760231 odoo.addons.base.models.ir_module: module point_of_sale: loading translation file /home/odoo/src/odoo/18.0/addons/point_of_sale/i18n/nl.po for language nl_NL ``` After fix (reduces to 10 mins): ```py 2025-04-17 11:29:44,294 23 INFO apan_2760231_18.0 odoo.modules.migration: module point_of_sale: Running migration [1.0.2>] post-deduplicate-uuids 2025-04-17 11:39:58,582 23 INFO apan_2760231_18.0 odoo.addons.base.models.ir_module: module point_of_sale: loading translation file /home/odoo/src/odoo/18.0/addons/point_of_sale/i18n/nl.po for language nl_NL ``` opw-4734894 upg-2760231 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Belgian POS blackbox module now skips IP logging when no web request is available, preventing point-of-sale tests and automated session starts from failing. Sale details processing also checks that a configuration uses blackbox before applying blackbox-specific logic.
Original PR description
Before this commit, when pos_blackbox_be was installed, the pos tests were failing because most pos test called `_run_test` which is calling `_satrt_pos_session` which is calling `open_new_session` which is calling `set_opening_control`. This makes that when calling `set_opening_control`, the request is not bound and we cannot do `request.geoip.ip`. We now check that the request is bound in `_log_ip`: if it is not, we return, if it is, we resolve the ip on the fly.
This update fixes a connection issue in Argentina electronic invoicing that could occur when running newer Python versions. It helps keep tax web service communication reliable across supported deployment environments.
This update fixes the Argentina electronic invoicing connection so it works reliably on both older Python versions and Python 3.12. It helps avoid connection failures when companies or hosting environments upgrade Python.
Original PR description
We adapted it to make it work depending on the version of Python used. It works for version 3.10.6 and below, but for Python 3.12, it fails. We adapted it so it can work in both Python versions Adhoc task 47274
This update improves batch invoice sending for Brazil, Colombia, Mexico, and Uruguay localizations by showing more accurate invoice counts before sending. It also fixes cases where Peppol invoices could be missed when no electronic invoice format was set, and treats Peppol XML generation problems as blocking errors instead of silently skipped items.
Original PR description
*: l10n_br_edi, l10n_co_dian, l10n_mx_edi, l10n_uy_edi 1. fix the summary of account.move.send.batch.wizard The summary was displaying wrong numbers of invoices. Indeed, it was computed on default…
*: l10n_br_edi, l10n_co_dian, l10n_mx_edi, l10n_uy_edi 1. fix the summary of account.move.send.batch.wizard The summary was displaying wrong numbers of invoices. Indeed, it was computed on default methods, instead of methods that are applicable to the move. For example, if a move was not possible to send through Peppol because the partner is not registered on the network, it was still displayed in the summary of the batch sending (then not used when the async processing happened). We also always put email as a fallback, even if no email is set, since it can be added through the wizard. 2. fix batch send of Peppol invoices when no format set In previous commit[1], we set the BIS3 format on invoices that were meant to be sent trough Peppol, even if no invoice_edi_format was set on the Partner. This commit fixes some cases when sending multiple invoices with no invoice_edi_format but Peppol as default sending method ended up not being sent. [1]: https://github.com/odoo/odoo/commit/84a0b81a258262e3bb9dbaa9c9f37796303a9dad 3. Remove 'skipped' state of Peppol moves This state doesn't really make sense. It only happens when there is an error while generating the XML file to send, which can be considered as a blocking error. task-no (review with TSB and PMAX)
This fix changes Brazilian Avalara account creation so missing fields are sent as empty text instead of false values. This prevents Avalara from storing "false" in account details, reducing EDI processing problems for affected Brazilian tax integrations.
Original PR description
Avalara populates those fields as "false" in the account, which causes issues during EDI. We keep sending the fields, but send empty string instead. opw-4716571
Payslips now exclude overtime that is still waiting for manager approval. This helps prevent employees from being paid for overtime before it has been reviewed and approved, improving payroll accuracy.
Original PR description
to reproduce: ============= - with employee having attendace houre based contract - set in attendace settigns that overtime should be approved by manager - create attendace for this employee with overtime pending for approval - create payslip for this employee -> the overtime is included in the payslip even if it is not approved Problem: ======== unapproved overtimes are not filtred while computing payslip lines Solution: ========= - add a filter to exclude unapproved overtimes in payslip line computation opw-4610454
The salesperson subscription dashboard now uses the correct source values and ranking lists in churn, contraction, and expansion tables. This improves the accuracy of reported subscription performance so sales teams can rely on the dashboard for decision-making.
Original PR description
fix wrong formulas in different tables: - in "worst churn" under Value, starting the 7th line, the value used was "recurring_monthly" instead of "amount_signed" - in "worst contraction", the 10th line didn't use the list 4 like the rest of the table - in "top expansion", the 10th line didn't use the list 2 like the rest of the table Task: 4711532
Fixes an issue that could cause Helpdesk ticket screens or automated checks to run out of memory when processing large numbers of tickets. The change makes ticket counting more efficient, improving reliability for teams with high ticket volumes.
Original PR description
**Traceback:** ```python ('helpdesk.helpdesk_ticket_menu_all', 117, 'Helpdesk > Tickets > All Tickets', 157): Traceback (most recent call last): File…
**Traceback:**
```python
('helpdesk.helpdesk_ticket_menu_all', 117, 'Helpdesk > Tickets > All Tickets', 157):
Traceback (most recent call last):
File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 259, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 272, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 432, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 463, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3814, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4045, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7031, in __getitem__
return self._fields[key].__get__(self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1303, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1485, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/18.0/addons/base_automation/models/base_automation.py", line 816, in _compute_field_value
return _compute_field_value.origin(self, field)
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 429, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5253, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
return needle(*args)
File "/home/odoo/src/enterprise/18.0/helpdesk/models/helpdesk_ticket.py", line 298, in _compute_partner_ticket_count
partner_tickets.fetch(['stage_id']) # prevent over-fetching fields, leading to potential out-of-memory error
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4095, in fetch
self.check_access('read')
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4394, in check_access
if not self.env.su and (result := self._check_access(operation)):
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4435, in _check_access
if domain and (forbidden := self - self.sudo().filtered_domain(domain)):
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6627, in filtered_domain
data = record.mapped(key)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6470, in mapped
recs = recs._fields[name].mapped(recs)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1377, in mapped
self.__get__(first(remaining))
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 3059, in __get__
return super().__get__(records, owner)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1266, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4071, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4108, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4197, in _fetch_query
rows = self.env.execute_query(query.select(*sql_terms))
File "/home/odoo/src/odoo/18.0/odoo/api.py", line 979, in execute_query
return [] if self.cr.description is None else self.cr.fetchall()
MemoryError
```
Issue:
------
The `_compute_partner_ticket_count` method caused a MemoryError while running the test cases due to the large number of records and over fetching of `stage_id` in the line: `partner_tickets.fetch(['stage_id'])`
followed by: `partner_tickets.filtered(lambda ticket: not ticket.stage_id.fold)`
Solution:
---------
Replaced the fetch and filtered logic with a search method to resolve the MemoryError and improve performance
upg-2707381
opw-4653413Miscellaneous changes
Before this commit, when the user enables the task dependencies feature globally, all basic projects (that is, non fsm ones) will get the feature. By doing that, the open tasks state will be recomputed to set `Waiting` state on tasks with blocking tasks linked to them. The problem is the compute method of the task state will also reset the state instead of keeping the one set on those open tasks when there is no blocking task linked. This commit makes sure the compute method of task state fie
Original PR description
Before this commit, when the user enables the task dependencies feature globally, all basic projects (that is, non fsm ones) will get the feature. By doing that, the open tasks state will be…
Before this commit, when the user enables the task dependencies feature globally, all basic projects (that is, non fsm ones) will get the feature. By doing that, the open tasks state will be recomputed to set `Waiting` state on tasks with blocking tasks linked to them. The problem is the compute method of the task state will also reset the state instead of keeping the one set on those open tasks when there is no blocking task linked. This commit makes sure the compute method of task state field is no longer called when the task dependencies feature changes. Instead, a inverse method is added on allow_task_dependencies field on `project.project` model to correctly update the state of the tasks linked to the project in which the task dependencies feature changed. Steps to reproduce the issue: ---------------------------- 0. install project 1. Create a project 2. Create some tasks inside that project and changes the state to some tasks 3. Enable the task dependencies feature in `Project > Configuration > Settings` menu. 4. Go back to the tasks kanban view of that project. Current Behavior: ---------------- The state of those tasks is reset to `In progress` (if those tasks did not have a state equals to `Done` or `Canceled`). Expected Behavior: ----------------- The state of those tasks should not be altered since no dependencies are added in those tasks yet. task-4487922 Forward-Port-Of: odoo/odoo#206156 Forward-Port-Of: odoo/odoo#198952
Before this commit, several invisible fields were present in the views in `l10n_ch`, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed. The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031. This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views. We will removes the unnecessary invisible fields in master.
Original PR description
Before this commit, several invisible fields were present in the views in `l10n_ch`, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed. The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031. This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views. We will removes the unnecessary invisible fields in master. opw-4629332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205501
**Current behavior:** When receiving product after having billed it already, if: A) the product is valuated, B) the purchase is in a foreign currency, C) there is an underlying exchange diff between time of bill and receiption then the exchange difference account move will occur in the regular exchange account. **Expected behavior:** It should be for the stock valuation account. **Steps to reproduce:** *with anglo saxon accounting enabled* 1. Create a real-time valuated product in
Original PR description
**Current behavior:** When receiving product after having billed it already, if: A) the product is valuated, B) the purchase is in a foreign currency, C) there is an underlying exchange diff between…
**Current behavior:** When receiving product after having billed it already, if: A) the product is valuated, B) the purchase is in a foreign currency, C) there is an underlying exchange diff between time of bill and receiption then the exchange difference account move will occur in the regular exchange account. **Expected behavior:** It should be for the stock valuation account. **Steps to reproduce:** *with anglo saxon accounting enabled* 1. Create a real-time valuated product invoiced on ordered qty 2. Activate a foreign currency, set some exchange rate for today and tomorrow (unique) 3. Make a purchase for the product, invoice -> post 4. The next day, receive the product 5. Check the exchange journal to see the offending AMLs **Cause of the issue:** In this flow, when the receipt is validated, at this point: *from `_validate_accounting_entries()`* https://github.com/odoo/odoo/blob/7e7c1abeead0d4ef19ec15d50808ab33a642d25e/addons/stock_account/models/account_move.py#L185 the SVL linkage is somewhat broken because the bill's SVL was generated before the receiption's. It means the exchange diff reconciliation proceeds as "usual" (without the `stock_account` module impacting the process) so the regular journal and accounts are used to record the amounts. **Fix:** Add overrides for getting the relevant journal and account(s) inside `_prepare_exchange_difference_move_vals()` in order to prevent `real_time` valuated product moves from generating AMLs in the ordinary exchange account (instead, use the stock journal and stock valuation account resp.) opw-4655669 Forward-Port-Of: odoo/odoo#204505
* When checking model coherency for sms, if choose transient model -> raise ValidationError message but the message seem not follow with the code so much 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#205196 Forward-Port-Of: odoo/odoo#188760
Original PR description
* When checking model coherency for sms, if choose transient model -> raise ValidationError message but the message seem not follow with the code so much 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#205196 Forward-Port-Of: odoo/odoo#188760
Replace the non-standard '🠖' (->) character with an arrow icon in the `_search_render_results()` method for consistent and proper rendering across browsers and platforms. Forward-Port-Of: odoo/odoo#205862
Original PR description
Replace the non-standard '🠖' (->) character with an arrow icon in the `_search_render_results()` method for consistent and proper rendering across browsers and platforms. Forward-Port-Of: odoo/odoo#205862
A check on the object received by the IoT Box containing certificate keys was always returning `False`, resulting in the certificate never being applied to the box in addition to an excessive amount of requests to odoo.com. Forward-Port-Of: odoo/odoo#206070 Forward-Port-Of: odoo/odoo#206040
Original PR description
A check on the object received by the IoT Box containing certificate keys was always returning `False`, resulting in the certificate never being applied to the box in addition to an excessive amount of requests to odoo.com. Forward-Port-Of: odoo/odoo#206070 Forward-Port-Of: odoo/odoo#206040
# Context: A recent improvement (https://github.com/odoo/odoo/pull/203739) slightly changed how the search domain for `ancestors` operates. Before it ignored note subtypes, i.e. `'subtype_id', '!=', note_type.id`. After the PR, it now matches all messages as long as they have a subtype. In doing so, it didn't account for the fact that in some production database, you might have `mail.message` records that have **no** message_id set, i.e. `message_id == False`. In such cases a traceba
Original PR description
# Context: A recent improvement (https://github.com/odoo/odoo/pull/203739) slightly changed how the search domain for `ancestors` operates. Before it ignored note subtypes, i.e. `'subtype_id', '!=',…
# Context:
A recent improvement (https://github.com/odoo/odoo/pull/203739) slightly changed how the search domain for `ancestors` operates. Before it ignored note subtypes, i.e. `'subtype_id', '!=', note_type.id`.
After the PR, it now matches all messages as long as they have a subtype.
In doing so, it didn't account for the fact that in some production database, you might have `mail.message` records that have **no** message_id set, i.e. `message_id == False`.
In such cases a traceback would be generated when sending a message from a mail.thread having an ancestor without `message_id` set.
Example:
```
references = ' '.join(m.message_id for m in (ancestors + message_sudo))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: sequence item 1: expected str instance, bool found
```
While such records *should* not exist when using the ORM, they might be the result of:
* certain upgrade scripts that use direct SQL (cf https://github.com/odoo/upgrade/blob/06b9e7f3cd98c383698695d6028bb7adefb6f805/migrations/base_vat/saas~16.3.1.0/pre-migrate.py#L104-L120)
* direct SQL inserts by users or/and customisations
# Proposed solution:
Since there are no ad-hoc mecanismes to fix such records on productions, the next best thing would be to simply adapt the search domain for `ancestors` and ignore any records where `message_id == False`. Indeed, if there is no `message_id` it makes no sense to try to add it in the references header.
# Reproduction steps:
1) Setup database and install contacts
2) Pick a contact and post a log note
3) For this new `mail.message` write `message_id == False` in the backend 4) Try to send a new message to the contact
-> Traceback
OPW-4728399
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#206279This commit removes four banner-related commands: Banner Info, Banner Success, Banner Warning, and Banner Danger. These commands have been removed in favor of using the Alert command, which offers the same functionality through a fully customizable Alert snippet. Now, when users search for terms like 'Banner', 'Info', 'Success', 'Warning' or 'Danger', the Alert command will appear in the Powerbox instead of the previous banner commands. task-3572344 --- I confirm I have signed the CLA
Original PR description
This commit removes four banner-related commands: Banner Info, Banner Success, Banner Warning, and Banner Danger. These commands have been removed in favor of using the Alert command, which offers the same functionality through a fully customizable Alert snippet. Now, when users search for terms like 'Banner', 'Info', 'Success', 'Warning' or 'Danger', the Alert command will appear in the Powerbox instead of the previous banner commands. task-3572344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206090 Forward-Port-Of: odoo/odoo#180313
Revealed by the nightly single app tests now testing every module, possibly some other module (and formerly demo data) hides the issue by setting a country which happens to work on the current company. Since #127204 `action_stripe_connect_account` will raise an error if the current company's country is not in `SUPPORTED_COUNTRIES`. When installing the module and running the test, the country is `False`, which is not a country supported by stripe. Ensure a supported country is set before ru
Original PR description
Revealed by the nightly single app tests now testing every module, possibly some other module (and formerly demo data) hides the issue by setting a country which happens to work on the current company. Since #127204 `action_stripe_connect_account` will raise an error if the current company's country is not in `SUPPORTED_COUNTRIES`. When installing the module and running the test, the country is `False`, which is not a country supported by stripe. Ensure a supported country is set before running the test. https://runbot.odoo.com/odoo/error/163118 Forward-Port-Of: odoo/odoo#206141 Forward-Port-Of: odoo/odoo#206066
Forward-Port-Of: odoo/odoo#206289
Original PR description
Forward-Port-Of: odoo/odoo#206289
Steps to reproduce: 1. Install `l10n_in_ewaybill_stock` and `sale_management` 2. Activate Units of measure 3. Create SO and add SO line with a product uom having units 4. Set this parameter `Quantity -> 1`, `UoM -> Dozen`, `Price Unit -> 12` 5. Confirm SO and related picking delivery 6. Create and generate E-waybill 7. Print Receipt The actual Taxable amount should be Rs. 12 but instead it shows 144 In this commit we fix the following issue opw-4728253 --- I confirm I hav
Original PR description
Steps to reproduce: 1. Install `l10n_in_ewaybill_stock` and `sale_management` 2. Activate Units of measure 3. Create SO and add SO line with a product uom having units 4. Set this parameter `Quantity -> 1`, `UoM -> Dozen`, `Price Unit -> 12` 5. Confirm SO and related picking delivery 6. Create and generate E-waybill 7. Print Receipt The actual Taxable amount should be Rs. 12 but instead it shows 144 In this commit we fix the following issue opw-4728253 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206094
Printing the E-Way Bill failed if the company logo was not configured, as the QWeb template attempted to render an image using a non-existent logo. Steps to reproduce: - Remove the company logo from the company settings - Try to print an E-Way Bill for any invoice Expected: - The E-Way Bill should be printed successfully without a logo Actual: - PDF generation fails due to a template rendering error Now: - The template checks for the presence of a logo before rendering it, allow
Original PR description
Printing the E-Way Bill failed if the company logo was not configured, as the QWeb template attempted to render an image using a non-existent logo. Steps to reproduce: - Remove the company logo from the company settings - Try to print an E-Way Bill for any invoice Expected: - The E-Way Bill should be printed successfully without a logo Actual: - PDF generation fails due to a template rendering error Now: - The template checks for the presence of a logo before rendering it, allowing the E-Way Bill to print even if the logo is not set. opw-4709233 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206190
This PR introduces a regression test to ensure that the sitemap remains in the default language of the website, regardless of the language version being accessed. Tests 2 scenarios: - First, configure a website with English and French language. - Set the default language to French. - Access the sitemap at /sitemap.xml -> The sitemap should be displayed in French. - Second, let the default language to be English. - Navigate to the French version of the website at /fr. - Access t
Original PR description
This PR introduces a regression test to ensure that the sitemap remains in the default language of the website, regardless of the language version being accessed. Tests 2 scenarios: - First,…
This PR introduces a regression test to ensure that the sitemap
remains in the default language of the website, regardless of the
language version being accessed.
Tests 2 scenarios:
- First, configure a website with English and French language.
- Set the default language to French.
- Access the sitemap at /sitemap.xml -> The sitemap should be displayed
in French.
- Second, let the default language to be English.
- Navigate to the French version of the website at /fr.
- Access the sitemap at /sitemap.xml -> The sitemap should now be
displayed in English.
This test addresses an issue that was previously fixed in commit
https://github.com/odoo/odoo/commit/809854c5d10735fb280141f5291bdb84d8d36569, but lacked a corresponding test to prevent future
regressions. This test ensures the bug reported in task-3935135 does ``
not reoccur.
**Added test in website_blog as it has routes that were translated.
Reference:
[1]: https://github.com/odoo/odoo/pull/154993#pullrequestreview-1900639267
Forward-Port-Of: odoo/odoo#190779Contains two commits. One adds the node in `account_edi_ubl_cii` module and one to adapt the Nilvera e-invoice to use it. Forward-Port-Of: odoo/odoo#204508
Original PR description
Contains two commits. One adds the node in `account_edi_ubl_cii` module and one to adapt the Nilvera e-invoice to use it. Forward-Port-Of: odoo/odoo#204508
Steps to reproduce: - Install `project` - Create a new `project` and `tasks` within it. - Share the project with the portal user with edit access mode. Issue: - The color picker is not accessible through the portal. Fix: - Hide the color picker for portal users when editing color in shared tasks. task-4495861 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206139 Forward-Port-Of: odoo/odoo#2020
Original PR description
Steps to reproduce: - Install `project` - Create a new `project` and `tasks` within it. - Share the project with the portal user with edit access mode. Issue: - The color picker is not accessible through the portal. Fix: - Hide the color picker for portal users when editing color in shared tasks. task-4495861 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206139 Forward-Port-Of: odoo/odoo#202058
Before this commit, the text wrapping in the product categories sometimes resulted in ugly breaks in the middle of words where not needed. Steps to reproduce ----- 1. Configure a category with spaces in Point of Sale > Configuration > PoS Product Categories For example, a category named "Special Menu" 2. Open a self-ordering kiosk, the "Special Menu" will be displayed as "Special M" + "enu" Cause ----- The styling `word-break: break-all;` was added to this element in #140095 to avoid
Original PR description
Before this commit, the text wrapping in the product categories sometimes resulted in ugly breaks in the middle of words where not needed. Steps to reproduce ----- 1. Configure a category with spaces in Point of Sale > Configuration > PoS Product Categories For example, a category named "Special Menu" 2. Open a self-ordering kiosk, the "Special Menu" will be displayed as "Special M" + "enu" Cause ----- The styling `word-break: break-all;` was added to this element in #140095 to avoid overlapping category names. However `break-all` always breaks in the exact place needed, often resulting in breaks in the middle of words. Solution ----- Use `overflow-wrap: break-word;` instead which will break between words if possible and only break in the middle of a word if needed. opw-4642999 Forward-Port-Of: odoo/odoo#205080
Versions -------- - 16.0+ Steps ----- 1. Run the `test_gift_card_email_sender` without `website_sale_loyalty`. Issue ----- `AttributeError` Cause ----- The `sale_loyalty` test calls `_auto_apply_rewards`, which is defined in `website_sale_loyalty`. Solution -------- The test works just as well without the method call, so we can simply remove it. runbot-163194 Forward-Port-Of: odoo/odoo#206295
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Run the `test_gift_card_email_sender` without `website_sale_loyalty`. Issue ----- `AttributeError` Cause ----- The `sale_loyalty` test calls `_auto_apply_rewards`, which is defined in `website_sale_loyalty`. Solution -------- The test works just as well without the method call, so we can simply remove it. runbot-163194 Forward-Port-Of: odoo/odoo#206295
Revert odoo/enterprise#81587 because errors are triggered on dry-run. Also see discussion here: ref: https://github.com/odoo/enterprise/pull/82900#issuecomment-2800848343 Forward-Port-Of: odoo/enterprise#83422 Forward-Port-Of: odoo/enterprise#83391
Original PR description
Revert odoo/enterprise#81587 because errors are triggered on dry-run. Also see discussion here: ref: https://github.com/odoo/enterprise/pull/82900#issuecomment-2800848343 Forward-Port-Of: odoo/enterprise#83422 Forward-Port-Of: odoo/enterprise#83391
### Step to reproduce: - In the settings enable Multi-step routes - Inventory > Configuration > Warehouse Management > Warehouses - Put you warehouse in manufacturing in 2 steps - Create a bill of material for a final product FP with one raw: - 3 x COMP (storable product with 10 units in stock) - Create and confirm an MO for 1 unit of FP. > This create a picking from stock to preprod for 3 unit of COMP - In the shopfloor on your MO click on the 3 dots and add components - Register
Original PR description
### Step to reproduce: - In the settings enable Multi-step routes - Inventory > Configuration > Warehouse Management > Warehouses - Put you warehouse in manufacturing in 2 steps - Create a bill of…
### Step to reproduce:
- In the settings enable Multi-step routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Put you warehouse in manufacturing in 2 steps
- Create a bill of material for a final product FP with one raw:
- 3 x COMP (storable product with 10 units in stock)
- Create and confirm an MO for 1 unit of FP.
> This create a picking from stock to preprod for 3 unit of COMP
- In the shopfloor on your MO click on the 3 dots and add components
- Register a new unit of COMP
> The picking from stock to pre-prod was updated twice, hence for 5 units
### Cause of the issue:
When you add a product from the shopfloor, we create a new move from pre-prod to virtual/production with the corresponding `product_uom_qty` of 1 and confirm it:
https://github.com/odoo/enterprise/blob/fc1fb4c56da916b165c43d8f6b6a4b903733a12f/mrp_workorder/wizard/additional_product.py#L63-L68 Since the procure method of this move has been adjusted, this confirmation will correctly create and run a procurement to generate a move from stock to pre-prod. Note that this part of the flow is strictly necessary if the additional product is not already part of the component raw of the MO. However, since in the present case there is already move raw from pre-prod to virtual/production associated to that product, the action confirm will also merge our additional move with the current existing one and hence modify its `product_uom_qty`. However, an override of mrp ensures that when such modification happen, we should also run the procurement to ensure that modifying the demand of a move will also update the related pickings:
https://github.com/odoo/odoo/blob/7def831bea18a91e4fa0f9c6aa6de34f4d6d18c8/addons/mrp/models/stock_move.py#L413-L419 Since we already run that same procurement we should bypass this call in our case.
opw-4562965
Forward-Port-Of: odoo/enterprise#82958
Forward-Port-Of: odoo/enterprise#81818Steps to reproduce: 1. Create a new BoM w/ a pass/fail operation step 2. Create a manufacturing order using that BoM 3. Go the the Quality app 4. Open the quality check created for the MO 5. Click on Pass (or Fail, does not matter) 6. Go back to the MO and click Produce All 7. The qty_passed/qty_failed is not computed on the quality check opw-4552103 Forward-Port-Of: odoo/enterprise#80291
Original PR description
Steps to reproduce: 1. Create a new BoM w/ a pass/fail operation step 2. Create a manufacturing order using that BoM 3. Go the the Quality app 4. Open the quality check created for the MO 5. Click on Pass (or Fail, does not matter) 6. Go back to the MO and click Produce All 7. The qty_passed/qty_failed is not computed on the quality check opw-4552103 Forward-Port-Of: odoo/enterprise#80291
Tests were moved to l10n_ch_hr_payroll_elm_account in https://github.com/odoo/enterprise/pull/64454 Forward-Port-Of: odoo/enterprise#83456 Forward-Port-Of: odoo/enterprise#81018
Original PR description
Tests were moved to l10n_ch_hr_payroll_elm_account in https://github.com/odoo/enterprise/pull/64454 Forward-Port-Of: odoo/enterprise#83456 Forward-Port-Of: odoo/enterprise#81018
### Issue: It is currently not possible to generate a return label with sendcloud if the delivery has been generated using a service point. ### Step to reproduce: - Set up Sendcloud, for a belgian company - Select bpost and dpd for delivery and returns while loading products - On a private window buy a storable product on the webstore online and select a sendcloud pickup point as the delivery method. - With an employee confirm the delivery order that was created #### > A problem occ
Original PR description
### Issue: It is currently not possible to generate a return label with sendcloud if the delivery has been generated using a service point. ### Step to reproduce: - Set up Sendcloud, for a belgian…
### Issue: It is currently not possible to generate a return label with sendcloud if the delivery has been generated using a service point. ### Step to reproduce: - Set up Sendcloud, for a belgian company - Select bpost and dpd for delivery and returns while loading products - On a private window buy a storable product on the webstore online and select a sendcloud pickup point as the delivery method. - With an employee confirm the delivery order that was created #### > A problem occured in the generation of the return label ### Cause of the issue: The `to_service_point` parameter is used by sendcloud's API in order to generate parcels and is added here: https://github.com/odoo/enterprise/blob/747482f34ca8210d89d81b3363ec5a8fc3a4ff6f/delivery_sendcloud/models/sendcloud_service.py#L109-L112 However, this parameter does not make sense in case of a return since the customer is allowed to return the product to the pickup point of its choice. In particular, sendcloud's API will fail to genrate the return parcel if it is expecting to link the label to a given pickup point. #### Note: Sendcloud also fails to generate the return label when the shipping provider is the same for the delivery and for the return, so that the `to_service_point` can just not be provided for return labels. opw-4562040 Forward-Port-Of: odoo/enterprise#83436 Forward-Port-Of: odoo/enterprise#83357
Currently, an error may occur when we try to export the trial balance with the SAT (XML) format. This is because a None id is used to browse the account, due to a more specific account_group. Steps to reproduce: - Install l10n_mx_reports. - Create an account_group with a more specific account, such as 401.01.01 - The 4, 401, and 401.01 groups are created with demo data. - Go to trial balance and try exporting with "SAT (XML)". An error will occur (`AttributeError: 'bool' object has
Original PR description
Currently, an error may occur when we try to export the trial balance with the SAT (XML) format. This is because a None id is used to browse the account, due to a more specific account_group.
Steps to reproduce:
- Install l10n_mx_reports.
- Create an account_group with a more specific account, such as 401.01.01
- The 4, 401, and 401.01 groups are created with demo data.
- Go to trial balance and try exporting with "SAT (XML)".
An error will occur (`AttributeError: 'bool' object has no attribute 'startswith'`) because the account is None, so account have no type.
opw-4716047
Forward-Port-Of: odoo/enterprise#83392
Forward-Port-Of: odoo/enterprise#83197**Steps to reproduce:** - Install Accounting and l10n_pe_edi - Switch to a Peruvian company (e.g. PE Company) - Configure Peruvian localization (https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/peru.html) - Create an invoice: * Customer: Comercial Constructora los Patitos S.A. * Operation Type: [0101] Internal sale * Invoice Lines: - Product: [any with a UNSPSC Category] - Taxes: 18% - Terms and Conditions: [text containing special cha
Original PR description
**Steps to reproduce:**
- Install Accounting and l10n_pe_edi
- Switch to a Peruvian company (e.g. PE Company)
- Configure Peruvian localization (https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/peru.html)
- Create an invoice:
* Customer: Comercial Constructora los Patitos S.A.
* Operation Type: [0101] Internal sale
* Invoice Lines:
- Product: [any with a UNSPSC Category]
- Taxes: 18%
- Terms and Conditions: [text containing special characters like '/' or '.']
- Confirm the invoice
- Process UBL 2.1
**Issue:**
In the XML, the content of <cbc:Note> has been stripped of all special characters like [/\!?+-=%.,;:()].
Only "whitespace" special characters should be excluded (i.e. '\n', '\u00A0',...).
opw-4659655
Forward-Port-Of: odoo/enterprise#82787Steps to reproduce: ------------------- * Install l10n_cl_edi_stock * Create a new Transfer * Add as customer a Contact that is part of a Company * Print Delivery Guide SII DTE 52 (CL) > Observation: Why the fix: ------------ The name of the company has to be shown not the actual name of ths customer Legal requirement in Chile ref: https://www.sii.cl/factura_electronica/formato_dte.pdf https://github.com/odoo/odoo/pull/172793 opw-4676871 Forward-Port-Of: odoo/enterprise#83311
Original PR description
Steps to reproduce: ------------------- * Install l10n_cl_edi_stock * Create a new Transfer * Add as customer a Contact that is part of a Company * Print Delivery Guide SII DTE 52 (CL) > Observation: Why the fix: ------------ The name of the company has to be shown not the actual name of ths customer Legal requirement in Chile ref: https://www.sii.cl/factura_electronica/formato_dte.pdf https://github.com/odoo/odoo/pull/172793 opw-4676871 Forward-Port-Of: odoo/enterprise#83311
The SP-API doesn't support SKU containing commas, not even when escaping and listing them in a correct CSV like string, as they'll be considered as either separate SKU or a different one, thus leading to an error saying there are too many identifiers, or not recognizing them anyway. In order to let the synchronization continue for the other items, ensure their SKU are valid beforehand. As from Amazon side, using a comma is a valid value, we can't constrain the SKU either. opw-4710435
Original PR description
The SP-API doesn't support SKU containing commas, not even when escaping and listing them in a correct CSV like string, as they'll be considered as either separate SKU or a different one, thus leading to an error saying there are too many identifiers, or not recognizing them anyway. In order to let the synchronization continue for the other items, ensure their SKU are valid beforehand. As from Amazon side, using a comma is a valid value, we can't constrain the SKU either. opw-4710435 Forward-Port-Of: odoo/enterprise#83367