Wednesday, October 16, 2024
30 changes · saas-17.2
Resolved issues and error corrections
UAE reporting modules now install automatically when the related accounting and UAE localization setup is used. This prevents missing tax reporting fields and avoids installation or test errors that could block UAE accounting workflows.
Original PR description
Before this commit, when installing the account_reports and l10n_ae modules, the l10n_ae_reports and corporate_tax_report modules were not installed, even though they depended on these modules. This caused an issue during an account report test, as the necessary field was not created, leading to an "Invalid field" error: ('l10n_ae_tax_report_liabilities_account' on model 'res.company')
By removing the countries field from the manifest, the modules now auto-install as expected, and the test no longer fails. But why? If a module depends on another module that has the countries attribute, there’s no need to include it back; the auto-installation will only be triggered if there is a company that belongs to that country.This update corrects how subscription-related automated tests are skipped and how amount comparisons are checked. It helps ensure test results are accurate and prevents avoidable failures in validation pipelines, without changing customer-facing behavior.
Original PR description
Before this commit, tests were skipped without using self.skipTest which is not a good practice. Moreover, assertAlmostEqual was not properly used in an older version. ssertAlmostEqual should be used to compare amounts but it can be called with place, delta and message. The named argument should be used correctly. See https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertAlmostEqual The msg parameter should be explicitely named. Runbots: https://runbot.odoo.com/web/#id=102838&view_type=form&model=runbot.build.error&menu_id=405&cids=1 https://runbot.odoo.com/web/#id=102837&view_type=form&model=runbot.build.error&menu_id=405&cids=1 https://runbot.odoo.com/web/#id=102836&view_type=form&model=runbot.build.error&menu_id=405&cids=1 https://runbot.odoo.com/web/#id=102835&view_type=form&model=runbot.build.error&menu_id=405&cids=1 https://runbot.odoo.com/web/#id=102834&view_type=form&model=runbot.build.error&menu_id=405&cids=1
This fixes internal subscription payment tests so they handle expected payment statuses and optional demo payment setup correctly. It helps keep subscription payment checks stable without changing customer-facing behavior.
Original PR description
1. Use `skipTest` if `payment_demo` isn't installed 2. Allow `paid` as well as `in_payment` as valid states 3. Name message parameter with `msg` in `assertAlmostEqual` opw-4152257
When adding new content to an online course with multiple sections, the system now automatically selects the most recently created section if no section was chosen. This reduces extra clicks and helps course editors continue adding content in chronological order.
Original PR description
Purpose ======= When users are editing course content and created multiple sections they are most likely working "chronologically" adding content to sections one after the other. It seems the fix to preselect last section by default when many exist to populate new content is in regression. How to fix ========== Whenever a channel has sections and users has not selected one: make the last section as the default one. task-4109586 see odoo#132934 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Before this fix, when a P&L account was wrongly configured with a Balance Sheet type, the 'normal' date_scope set on the P&L expressions made it so that the balance of this account was computed on the whole accounting history. Of course, the most proper fix in that case is to fix the account type, but using strict_range as the date_scope will just make the report a little more robust. This is a partial backport of what was done in https://github.com/odoo/enterprise/commit/6e607e662dd2ae3ee5e3
Original PR description
Before this fix, when a P&L account was wrongly configured with a Balance Sheet type, the 'normal' date_scope set on the P&L expressions made it so that the balance of this account was computed on the whole accounting history. Of course, the most proper fix in that case is to fix the account type, but using strict_range as the date_scope will just make the report a little more robust. This is a partial backport of what was done in https://github.com/odoo/enterprise/commit/6e607e662dd2ae3ee5e3616bded11b62332ac2f9 for 18.0 Forward-Port-Of: odoo/enterprise#71578
In the deferred computations, we always assume that both the start and end date are inclusive E.g: 1st January -> 31st December is *exactly* 1 year = 12 months However, the user may instead put 1st January -> 1st January of next year which is then 12 months + 1/30 month = 12.03 months which may result in odd amounts when deferrals are created For this reason, we now alert the user if we detect such a case with a warning banner and yellow highlight in the abnormal dates. Other cases were the num
Original PR description
In the deferred computations, we always assume that both the start and end date are inclusive E.g: 1st January -> 31st December is *exactly* 1 year = 12 months However, the user may instead put 1st January -> 1st January of next year which is then 12 months + 1/30 month = 12.03 months which may result in odd amounts when deferrals are created For this reason, we now alert the user if we detect such a case with a warning banner and yellow highlight in the abnormal dates. Other cases were the number of months is not round should not be handled. task-id: none Forward-Port-Of: odoo/enterprise#71423
Issue: The Uso (l10n_mx_edi_usage) field in the Mexican invoice PDF report was displayed in English instead of Spanish (MX), even when the customer's language was set to Spanish(Mx). Step to reproduce the issue: - Go to the Accounting app --› Customer invoices journal --› Create a new invoice. - Select a customer with the Spanish (MX) / Español (MX) language set. - Select any product from the inventory catalog. - Set the Uso (l10n_mx_edi_usage) as "Gastos en general". - Confirm the invo
Original PR description
Issue: The Uso (l10n_mx_edi_usage) field in the Mexican invoice PDF report was displayed in English instead of Spanish (MX), even when the customer's language was set to Spanish(Mx). Step to…
Issue: The Uso (l10n_mx_edi_usage) field in the Mexican invoice PDF report was displayed in English instead of Spanish (MX), even when the customer's language was set to Spanish(Mx). Step to reproduce the issue: - Go to the Accounting app --› Customer invoices journal --› Create a new invoice. - Select a customer with the Spanish (MX) / Español (MX) language set. - Select any product from the inventory catalog. - Set the Uso (l10n_mx_edi_usage) as "Gastos en general". - Confirm the invoice. - Click on "Send and print" button and mark the CFDI checkbox in the next window, click on send and print button again. - The Uso (l10n_mx_edi_usage) field is being translated into English, despite the language set for the customer is Spanish (MX) / Español (MX). Cause of the issue: The XML template (report_invoice.xml) uses a dynamic value for the Uso field, preventing the standard PO file translations from being applied. A python translation using the _description_selection from Fields with the env language detection method is necessary in the _l10n_mx_edi_get_extra_invoice_report_values method in account_move.py. opw-4212069 Forward-Port-Of: odoo/enterprise#71344
After [this commit], there was an issue for reports where we don't have accounts as the first column. It would offset the cell too far to the left, assuming there is an account code column. This commit fixes that, so reports like the partner ledger are exporting correctly again showing the partner names. [this commit]: https://github.com/odoo/enterprise/commit/a3d76fc2b39428b7ea7c41bf98b2ecbe741a67fb Forward-Port-Of: odoo/enterprise#72010
Original PR description
After [this commit], there was an issue for reports where we don't have accounts as the first column. It would offset the cell too far to the left, assuming there is an account code column. This commit fixes that, so reports like the partner ledger are exporting correctly again showing the partner names. [this commit]: https://github.com/odoo/enterprise/commit/a3d76fc2b39428b7ea7c41bf98b2ecbe741a67fb Forward-Port-Of: odoo/enterprise#72010
Before this commit, when the invoice consolidation option was activated and several user_id were set on subscription invoicing at the same time, a traceback was observed: ``py File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 276, in create thread._message_auto_subscribe(create_values, followers_existing_policy='update') File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 4138, in _message_auto_subscr
Original PR description
Before this commit, when the invoice consolidation option was activated and several user_id were set on subscription invoicing at the same time, a traceback was observed: ``py File…
Before this commit, when the invoice consolidation option was activated and several user_id were set on subscription invoicing at the same time, a traceback was observed:
``py
File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 276, in create
thread._message_auto_subscribe(create_values, followers_existing_policy='update')
File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 4138, in _message_auto_subscribe
res = self._message_auto_subscribe_followers(updated_values, def_ids)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/arj/PycharmProjects/worktree/17.0/enterprise/sale_subscription/models/account_move.py", line 76, in _message_auto_subscribe_followers
if salesperson and user_id == salesperson.id and user_id != self.env.user.id:
^^^^^^^^^^^^^^
File "/home/arj/PycharmProjects/worktree/17.0/odoo/odoo/fields.py", line 5154, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: res.users(56, 60)
```
Forward-Port-Of: odoo/enterprise#71188### Description When trying to invoice to a partner that does not have an Uruguayan identification type or do not have a generic identification type we get a traceback, this PR solve it and show the proper error message to the user so he can properly set the partner info. ### Steps to reproduce 1. Open runbot install AR and UY modules 2. In the UY company and invoice a e-ticket to ADHOC SA partner (id CUIT - AR type), total amount should be greater that 30.000 ### Before the PR W
Original PR description
### Description When trying to invoice to a partner that does not have an Uruguayan identification type or do not have a generic identification type we get a traceback, this PR solve it and show the…
### Description
When trying to invoice to a partner that does not have an Uruguayan identification type or do not have a generic identification type we get a traceback, this PR solve it and show the proper error message to the user so he can properly set the partner info.
### Steps to reproduce
1. Open runbot install AR and UY modules
2. In the UY company and invoice a e-ticket to ADHOC SA partner (id CUIT - AR type), total amount should be greater that 30.000
### Before the PR
We receive a traceback error
```
RPC_ERROR
Odoo Server Error
Traceback (most recent call last):
File "/data/build/adhoc-cicd-odoo-odoo/odoo/http.py", line 1783, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/service/model.py", line 133, in retrying
result = func()
File "/data/build/adhoc-cicd-odoo-odoo/odoo/http.py", line 1810, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/http.py", line 2014, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/data/build/adhoc-cicd-odoo-odoo/addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/addons/base/models/ir_http.py", line 226, in _dispatch
result = endpoint(**request.params)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/http.py", line 759, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/data/build/adhoc-cicd-odoo-odoo/addons/web/controllers/dataset.py", line 28, in call_button
action = self._call_kw(model, method, args, kwargs)
File "/data/build/adhoc-cicd-odoo-odoo/addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/api.py", line 468, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "/data/build/adhoc-cicd-odoo-odoo/addons/account/wizard/account_move_send.py", line 732, in action_send_and_print
return self._process_send_and_print(
File "/data/build/adhoc-cicd-odoo-odoo/addons/account/wizard/account_move_send.py", line 666, in _process_send_and_print
self._generate_invoice_documents(moves_data, allow_fallback_pdf=allow_fallback_pdf)
File "/data/build/adhoc-cicd-odoo-odoo/addons/account/wizard/account_move_send.py", line 572, in _generate_invoice_documents
self._hook_invoice_document_before_pdf_report_render(invoice, invoice_data)
File "/data/build/adhoc-cicd-odoo-enterprise/l10n_uy_edi/wizards/account_move_send.py", line 59, in _hook_invoice_document_before_pdf_report_render
if errors := invoice._l10n_uy_edi_check_move():
File "/data/build/adhoc-cicd-odoo-enterprise/l10n_uy_edi/models/account_move.py", line 502, in _l10n_uy_edi_check_move
dtype=self.partner_id.l10n_latam_document_type_id.name))
AttributeError: 'res.partner' object has no attribute 'l10n_latam_document_type_id'
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (https://80893-17-0-all.runbot.adhoc.com.ar/web/assets/d093fae/web.assets_web.min.js:2891:163)
at XMLHttpRequest.<anonymous> (https://80893-17-0-all.runbot.adhoc.com.ar/web/assets/d093fae/web.assets_web.min.js:2895:13)
```
This happens because the document type is related to the invoice, the partner actually has identification type field.
### After the PR
Now it shows the proper message telling the message the problem related to the partner configuration so they can fix it before sending EDI invoice
Reference: LATAM 1275 / ADHOC TICKET 81219
Forward-Port-Of: odoo/enterprise#71416Fixes an issue where the overriden split_uncompleted_moves method did not return its call to super(). Forward-Port-Of: odoo/enterprise#71980
Original PR description
Fixes an issue where the overriden split_uncompleted_moves method did not return its call to super(). Forward-Port-Of: odoo/enterprise#71980
Adding some new accounts in the reports task: 4210069 Forward-Port-Of: odoo/enterprise#70710
Original PR description
Adding some new accounts in the reports task: 4210069 Forward-Port-Of: odoo/enterprise#70710
### Steps to reproduce the issue: 1. In Mexican Company, create an Invoice elligible for CFDI 2. Send & Print 3. In the PDF, "Digital stamp of the emitter" and "Digital stamp SAT" are the same ### Explanation: In the xml template, under "Digital stamp of the emitter", the value retrieved is `sello_sat` instead of `sello` ### Fix reasoning: Replacing `sello_sat` with `sello` under "Digital stamp of the emitter" in every template using the values opw-4227743 Forward-Port-Of: o
Original PR description
### Steps to reproduce the issue: 1. In Mexican Company, create an Invoice elligible for CFDI 2. Send & Print 3. In the PDF, "Digital stamp of the emitter" and "Digital stamp SAT" are the same ### Explanation: In the xml template, under "Digital stamp of the emitter", the value retrieved is `sello_sat` instead of `sello` ### Fix reasoning: Replacing `sello_sat` with `sello` under "Digital stamp of the emitter" in every template using the values opw-4227743 Forward-Port-Of: odoo/enterprise#71463
In this PR: - Updated the matching criteria for GSTR2B late bills to use the specific month of the bill date. - Replaced previous date filter on `invoice_date` to limit searches to the start and end of the bill's month. - Ensured accurate retrieval of bills by filtering based on the bill number and company. This change enhances the precision of bill matching in the GSTR2B late bill streamline process. Forward-Port-Of: odoo/enterprise#72012
Original PR description
In this PR: - Updated the matching criteria for GSTR2B late bills to use the specific month of the bill date. - Replaced previous date filter on `invoice_date` to limit searches to the start and end of the bill's month. - Ensured accurate retrieval of bills by filtering based on the bill number and company. This change enhances the precision of bill matching in the GSTR2B late bill streamline process. Forward-Port-Of: odoo/enterprise#72012
Backport of https://github.com/odoo/odoo/commit/9302313a01368cde83b98c7dce9d706d8bd1d2a2 opw-4147106 Forward-Port-Of: odoo/odoo#183068
Original PR description
Backport of https://github.com/odoo/odoo/commit/9302313a01368cde83b98c7dce9d706d8bd1d2a2 opw-4147106 Forward-Port-Of: odoo/odoo#183068
The country is a mandatory field on the delivery address. Xpath: cac:Delivery/cac:DeliveryLocation/cac:Address/cac:Country/cbc:IdentificationCode "[BR-57]-Each Deliver to address (BG-15) shall contain a Deliver to country code (BT-80)." opw-4139689 Forward-Port-Of: odoo/odoo#180172
Original PR description
The country is a mandatory field on the delivery address. Xpath: cac:Delivery/cac:DeliveryLocation/cac:Address/cac:Country/cbc:IdentificationCode "[BR-57]-Each Deliver to address (BG-15) shall contain a Deliver to country code (BT-80)." opw-4139689 Forward-Port-Of: odoo/odoo#180172
- sale_project: fix domain as it is not possible to select a SOL on a task in the case where the SOL's contact belongs to the same company than the contact set as the task's customer. The `.id` was removed by https://github.com/odoo/odoo/commit/e095ef5153fb1a8364a4f53896a522fefa35ecd9 and is actually necessary if we want to have SOLs where the `order_partner_id` is the parent of the `partner_id` or shares the same parent than `parent_id`. - sale: remove SOLs of discount products from th
Original PR description
- sale_project: fix domain as it is not possible to select a SOL on a task in the case where the SOL's contact belongs to the same company than the contact set as the task's customer. The `.id` was removed by https://github.com/odoo/odoo/commit/e095ef5153fb1a8364a4f53896a522fefa35ecd9 and is actually necessary if we want to have SOLs where the `order_partner_id` is the parent of the `partner_id` or shares the same parent than `parent_id`. - sale: remove SOLs of discount products from the SOLs considered as sellable. The discount products are "fake" products used to manage discounts. opw-4212956 Forward-Port-Of: odoo/odoo#183121
During this commit: https://github.com/odoo/odoo/pull/126718/commits/00af576ec77e90b6e2e4b398e61b6b5a17f01067 We changed the CoA but when doing it, we added some subtitle as accounts which was wrong and can be misleading for the users. Also adding some missing accounts. We don't remove the accounts from the reports in case a user used those account, and we don't want them to be impacted by this change. task: 4210069 --- I confirm I have signed the CLA and read the PR guidelines
Original PR description
During this commit: https://github.com/odoo/odoo/pull/126718/commits/00af576ec77e90b6e2e4b398e61b6b5a17f01067 We changed the CoA but when doing it, we added some subtitle as accounts which was wrong and can be misleading for the users. Also adding some missing accounts. We don't remove the accounts from the reports in case a user used those account, and we don't want them to be impacted by this change. task: 4210069 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181513
Since [1] the meta tag 'default_title' was double-escaped due to improper handling of dynamic content within the template, leading to HTML entities being escaping twice. For example, `"` was incorrectly transformed into `&34;` Steps to reproduce: - Open a product and modify its name by adding a special character, such as a single quote. - Open the "Optimize SEO" dialog. Issue: The default title displays `'` instead of the single quote. This commit resolves this issue and
Original PR description
Since [1] the meta tag 'default_title' was double-escaped due to improper handling of dynamic content within the template, leading to HTML entities being escaping twice. For example, `"` was incorrectly transformed into `&34;` Steps to reproduce: - Open a product and modify its name by adding a special character, such as a single quote. - Open the "Optimize SEO" dialog. Issue: The default title displays `'` instead of the single quote. This commit resolves this issue and at the same time gets rid of the trailing spaces. [1] https://github.com/odoo/odoo/commit/7c54acaebe38e47cad25d8a1bbdb430e5bad265d task-3974334 Forward-Port-Of: odoo/odoo#179739
This issue arises when multiple clicks are made on the calendar view button. Steps to reproduce: - Install either the `google_calendar` or `microsoft_calendar` module. - Go to calendar > Click multiple times on the calendar view button. - Error will be generated This issue specifically occurs if either the `google_calendar` or `microsoft_calendar` module has been installed. this issue occurs because here https://github.com/odoo/odoo/blob/79666cbab0ab0947b3d853ab58a929635c309bab/addons
Original PR description
This issue arises when multiple clicks are made on the calendar view button. Steps to reproduce: - Install either the `google_calendar` or `microsoft_calendar` module. - Go to calendar > Click multiple times on the calendar view button. - Error will be generated This issue specifically occurs if either the `google_calendar` or `microsoft_calendar` module has been installed. this issue occurs because here https://github.com/odoo/odoo/blob/79666cbab0ab0947b3d853ab58a929635c309bab/addons/google_calendar/static/src/views/google_calendar/google_calendar_model.js#L28 google or microsoft sync will taking longer then 1s, this promise will resolve after 1s and the component is destroyed. so to address this issue, we need to eliminate the race condition and await the completion of the google/microsoft sync. Task-3768492 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173783 Forward-Port-Of: odoo/odoo#161831
Open web shop Add item to cart To to checkout Enter Customer details Add as country Hungary and vat 12345678-1-11 Confirm Error The VAT number [HU12345678111] does not seem to be valid. Note: the expected format is HU12345676 or 12345678-1-11 or 8071592153 This occurs because, when converting the domestic vat to the EU format, (with the leading country code) all digits are kept opw-3815478 Forward-Port-Of: odoo/odoo#165740
Original PR description
Open web shop Add item to cart To to checkout Enter Customer details Add as country Hungary and vat 12345678-1-11 Confirm Error The VAT number [HU12345678111] does not seem to be valid. Note: the expected format is HU12345676 or 12345678-1-11 or 8071592153 This occurs because, when converting the domestic vat to the EU format, (with the leading country code) all digits are kept opw-3815478 Forward-Port-Of: odoo/odoo#165740
Taxes with the l10n_es_edi_facturae_tax_type field were not updated correctly from the `account.tax-es_common.csv` file causing `TaxTypeCode` in XML to be incorrect in case of withheld taxes(IRPF) and XML file refused. With this commit, the bug is fixed automatically for new users installing the l10n_es_edi_factuare module task-4095945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179638
Original PR description
Taxes with the l10n_es_edi_facturae_tax_type field were not updated correctly from the `account.tax-es_common.csv` file causing `TaxTypeCode` in XML to be incorrect in case of withheld taxes(IRPF) and XML file refused. With this commit, the bug is fixed automatically for new users installing the l10n_es_edi_factuare module task-4095945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179638
When unlinking too many records, the memory can be reached when browsing too many records, which prevents the gc to work properly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183576 Forward-Port-Of: odoo/odoo#183321
Original PR description
When unlinking too many records, the memory can be reached when browsing too many records, which prevents the gc to work properly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183576 Forward-Port-Of: odoo/odoo#183321
Follow up of https://github.com/odoo/odoo/pull/178219 The vies check service may limit ip addresses when: - checking too many vat numbers per day - checking the same vat number multiple times - checking too many invalid number This is to avoid the second case Forward-Port-Of: odoo/odoo#182764
Original PR description
Follow up of https://github.com/odoo/odoo/pull/178219 The vies check service may limit ip addresses when: - checking too many vat numbers per day - checking the same vat number multiple times - checking too many invalid number This is to avoid the second case Forward-Port-Of: odoo/odoo#182764
This fix aims to prevent the button_process_edi_web_services function from being executed with multiple records simultaneously. The reason is that calling action_process_edi_web_services with with_commit=False can cause issues if Odoo crashes in the middle of execution (e.g., the document is sent but not updated in Odoo, so when the server restarts, the document is sent again). Although I don't believe anything in Odoo calls this function with multiple records. But we encountered a case where
Original PR description
This fix aims to prevent the button_process_edi_web_services function from being executed with multiple records simultaneously. The reason is that calling action_process_edi_web_services with with_commit=False can cause issues if Odoo crashes in the middle of execution (e.g., the document is sent but not updated in Odoo, so when the server restarts, the document is sent again). Although I don't believe anything in Odoo calls this function with multiple records. But we encountered a case where a client had a server action that invoked this function with multiple records at the same tim, and it caused a duplicate document sent. opw-4195392 Forward-Port-Of: odoo/odoo#183060
When user tries to apply a discount code in order, a traceback will appear. Steps to reproduce the error: - Install ```website_sale_loyalty``` - Activate ```Demo``` payment provider - Go to Website > Shop > Add a product to cart > View cart - Pay with Demo > Pay - Click the back button - Apply Coupon code Traceback: ``` ValueError: not enough values to unpack (expected 1, got 0) File "odoo/models.py", line 5975, in ensure_one _id, = self._ids ValueError: Expected singleto
Original PR description
When user tries to apply a discount code in order, a traceback will appear. Steps to reproduce the error: - Install ```website_sale_loyalty``` - Activate ```Demo``` payment provider - Go to Website >…
When user tries to apply a discount code in order,
a traceback will appear.
Steps to reproduce the error:
- Install ```website_sale_loyalty```
- Activate ```Demo``` payment provider
- Go to Website > Shop > Add a product to cart > View cart
- Pay with Demo > Pay
- Click the back button
- Apply Coupon code
Traceback:
```
ValueError: not enough values to unpack (expected 1, got 0)
File "odoo/models.py", line 5975, in ensure_one
_id, = self._ids
ValueError: Expected singleton: sale.order()
File "odoo/http.py", line 2383, in __call__
response = request._serve_db()
File "odoo/http.py", line 1913, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1976, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1943, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2100, in dispatch
return self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 227, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 757, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/website_sale_loyalty/controllers/main.py", line 17, in pricelist
coupon_status = order._try_apply_code(promo)
File "addons/sale_loyalty/models/sale_order.py", line 1197, in _try_apply_code
self.ensure_one()
File "odoo/models.py", line 5978, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
https://github.com/odoo/odoo/blob/9a9063a2d1f385b02f8453b766ec225def531d7e/addons/website_sale_loyalty/controllers/main.py#L16
When user clicks the back button and applies the coupon,
```order``` will be empty, So, it will lead to the above traceback.
sentry-5856780654
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#180450# Issue: When creating a vendor bill for a non EU partner, setting the tax to "22% G RC (Goods)" and generating the XML file, checking the generated XML file gives the error: "Tipo Documento must not be empty." # Steps to reproduce: - create a vendor bill with a non EU partner - add a product with tax "22% G RC (Goods)" - post the bill - click Send Tax Integration - check the generated XML file using an online checker like www.fatturacheck.it - it will show the error "Tipo Documento mu
Original PR description
# Issue: When creating a vendor bill for a non EU partner, setting the tax to "22% G RC (Goods)" and generating the XML file, checking the generated XML file gives the error: "Tipo Documento must not…
# Issue: When creating a vendor bill for a non EU partner, setting the tax to "22% G RC (Goods)" and generating the XML file, checking the generated XML file gives the error: "Tipo Documento must not be empty." # Steps to reproduce: - create a vendor bill with a non EU partner - add a product with tax "22% G RC (Goods)" - post the bill - click Send Tax Integration - check the generated XML file using an online checker like www.fatturacheck.it - it will show the error "Tipo Documento must not be empty." # Solution: - The document type is usually computed. However, in this specific case, it cannot be computed because it does not meet any of the conditions in the computation logic. Additionally, there is no safeguard to prevent the generation of the XML file if the document type is not set. - A check has been added to prevent XML generation when the document type is not set, ensuring the document type is always correctly provided before XML generation. opw-4182531 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180364
Steps --- * install `stock` * from *Settings* > *Stock* activate packages * create a product P and put 2 packages (pk1, pk2) of 10 units each in stock (inventory adjustment) * create a delivery order for 10 P > *Mark as Todo* * go to the detailed ops for the move * => it auto suggest the sml: pk1, qty = 10 * set the qty on the generated sml to 3 * *add a line* > pick from *WHStock - pk2*: * => this creates the sml: pk2, qty = 7 * set the new sml's package to pk1
Original PR description
Steps --- * install `stock` * from *Settings* > *Stock* activate packages * create a product P and put 2 packages (pk1, pk2) of 10 units each in stock (inventory adjustment) * create a delivery order…
Steps
---
* install `stock`
* from *Settings* > *Stock* activate packages
* create a product P and put 2 packages (pk1, pk2) of 10 units each
in stock (inventory adjustment)
* create a delivery order for 10 P > *Mark as Todo*
* go to the detailed ops for the move
* => it auto suggest the sml: pk1, qty = 10
* set the qty on the generated sml to 3
* *add a line* > pick from *WHStock - pk2*:
* => this creates the sml: pk2, qty = 7
* set the new sml's package to pk1
* => the *Pick From* field doesn't change
* *save*, the second sml's package has been reset to pk2
Cause
---
In the detailed ops we use a dummy `quant_id` field on sml to allow
selecting a quant and carrying some fields values from it to the sml.
But, when the quant was selected, setting the values of the carried
field, will not affect back the quant. And later, because the quant is
set, we use its values instead of the ones the user specified.
Fix
---
Hide the affected fields in the view, so the user cannot attempt to set
them, which would not work. i.e if they want to set the package id they should
do it via the quant dropdown.
opw-4089523
Forward-Port-Of: odoo/odoo#177260Before this PR, if you changed the time format in the language, the Gantt and the form view of the attendance did not follow those formats. With this PR, the dates displayed in the Gantt and form view are based on the time format set in the language. Task-4098672 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176599
Original PR description
Before this PR, if you changed the time format in the language, the Gantt and the form view of the attendance did not follow those formats. With this PR, the dates displayed in the Gantt and form view are based on the time format set in the language. Task-4098672 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176599
Steps --- * In the setting enable *Multi Step Routes* * Create an internal transfer with 1 operation for some product > *Mark as Todo* * On the stock.move operation line click the list icon for detailed operations. * *Add a line* => this opens a Wizard where we can choose the quant from which to pick the product for the sml * After adding the line *Add a line* again, we cannot pick the same quant Use case --- For internal transfers, we would like to be able to pick products from the s
Original PR description
Steps --- * In the setting enable *Multi Step Routes* * Create an internal transfer with 1 operation for some product > *Mark as Todo* * On the stock.move operation line click the list icon for detailed operations. * *Add a line* => this opens a Wizard where we can choose the quant from which to pick the product for the sml * After adding the line *Add a line* again, we cannot pick the same quant Use case --- For internal transfers, we would like to be able to pick products from the same quant and dispatch them to several sub-locations of the picking's destination location. Side Fix --- Delete `onRecordDiscarted` method, which wasn't being used because of the typo and doesn't appear to be necessary. opw-4072541 Co-authored-by: @ajf-odoo Forward-Port-Of: odoo/odoo#174984