Wednesday, January 8, 2025
14 changes · saas-17.2
Resolved issues and error corrections
Fixes an issue where grouping journal items by Internal Group could cause an error instead of showing results. This makes financial reporting views more reliable for users organizing accounting entries.
Original PR description
In journal items, when grouping by 'Internal Group', a traceback appears due to referencing a non-existent table `account_account` as it has been joined with `account_move_line`. This commit ensures the referenced table is correctly updated in the case of joins. opw-4405281 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
**Steps to reproduce:** - Install point_of_sale and l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create a product with an UNSPSC Category - In POS settings, enable "Use QR code on ticket" option - Open a POS session - Make an orders with the created product (without invoice) - Print the receipt - Close the POS session - Scan the QR code on the receipt with a mobile (Or just open the link retrieved from the QR code in a browser from the computer without being
Original PR description
**Steps to reproduce:** - Install point_of_sale and l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create a product with an UNSPSC Category - In POS settings, enable "Use QR…
**Steps to reproduce:** - Install point_of_sale and l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create a product with an UNSPSC Category - In POS settings, enable "Use QR code on ticket" option - Open a POS session - Make an orders with the created product (without invoice) - Print the receipt - Close the POS session - Scan the QR code on the receipt with a mobile (Or just open the link retrieved from the QR code in a browser from the computer without being logged) - Enter all the required data - Click several times on "Get my invoice" button quickly to generate the invoice **Issue:** Several concurrent processes are executed to create the invoice. In the Mexican localization, an electronic invoice is also generated and signed. However, an error is raised when trying to commit the electronic invoice document from the concurrent processes. These errors prevents the normal flow to continue after the creation of the invoice and the reversal of the POS closing entry is not generated as expected. **Solution:** Disable the "Get my invoice" button when the form is submitted to prevent concurrent calls to the action. opw-4399540 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192016
When the user tries to reset the password, a traceback will appear. Steps to reproduce the error: - Install ``auth_signup`` - Configure "Outgoing mail server" - Now Log out - Click on Sign in > Reset Password > Enter your email > Click on ``Reset Password`` twice Traceback: ``` InFailedSqlTransaction: current transaction is aborted, commands ignored until end of transaction block File "odoo/http.py", line 2365, in __call__ response = request._serve_db() File "odoo/htt
Original PR description
When the user tries to reset the password, a traceback will appear. Steps to reproduce the error: - Install ``auth_signup`` - Configure "Outgoing mail server" - Now Log out - Click on Sign in > Reset…
When the user tries to reset the password, a traceback will appear.
Steps to reproduce the error:
- Install ``auth_signup``
- Configure "Outgoing mail server"
- Now Log out
- Click on Sign in > Reset Password > Enter your email >
Click on ``Reset Password`` twice
Traceback:
```
InFailedSqlTransaction: current transaction is aborted, commands ignored until end of transaction block
File "odoo/http.py", line 2365, in __call__
response = request._serve_db()
File "odoo/http.py", line 1892, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1955, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1922, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2082, in dispatch
return self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 331, in _dispatch
result.flatten()
File "odoo/http.py", line 1389, in flatten
self.response.append(self.render())
File "odoo/http.py", line 1381, in render
return request.env["ir.ui.view"]._render_template(self.template, self.qcontext)
File "home/odoo/src/enterprise/18.0/web_studio/models/ir_ui_view.py", line 1315, in _render_template
return super(View, self)._render_template(template, values)
File "odoo/addons/base/models/ir_ui_view.py", line 2185, in _render_template
return self.env['ir.qweb']._render(template, values)
File "odoo/tools/profiler.py", line 306, in _tracked_method_render
return method_render(self, template, values, **options)
File "odoo/addons/base/models/ir_qweb.py", line 597, in _render
template_functions, def_name = irQweb._compile(template)
File "odoo/tools/profiler.py", line 314, in _tracked_compile
return method_compile(self, template)
File "odoo/addons/base/models/ir_qweb.py", line 666, in _compile
return self._load_values(base_key_cache, generate_functions)
File "odoo/addons/base/models/ir_qweb.py", line 2524, in _load_values
return get_value()
File "odoo/addons/base/models/ir_qweb.py", line 635, in generate_functions
code, options, def_name = self._generate_code(template)
File "odoo/addons/base/models/ir_qweb.py", line 691, in _generate_code
element, document, ref = self._get_template(template)
File "odoo/addons/base/models/ir_qweb.py", line 822, in _get_template
doc_or_elem, ref = self._load(ref_alias) or (None, None)
File "odoo/addons/base/models/ir_qweb.py", line 859, in _load
view = IrUIView._get(ref)
File "odoo/addons/base/models/ir_ui_view.py", line 2085, in _get
return self.browse(self._get_view_id(view_ref))
File "odoo/addons/base/models/ir_ui_view.py", line 2073, in _get_view_id
view = self.sudo().search([('key', '=', template)], limit=1)
File "odoo/models.py", line 1717, in search
return self.search_fetch(domain, [], offset=offset, limit=limit, order=order)
File "odoo/models.py", line 1749, in search_fetch
return self._fetch_query(query, fields_to_fetch)
File "odoo/models.py", line 4180, in _fetch_query
fetched = self.browse(query)
File "odoo/models.py", line 6154, in browse
if not ids:
File "odoo/tools/query.py", line 261, in __bool__
return bool(self.get_result_ids())
File "odoo/tools/query.py", line 225, in get_result_ids
self._ids = tuple(id_ for id_, in self._env.execute_query(self.select()))
File "odoo/api.py", line 962, in execute_query
self.cr.execute(query)
File "odoo/sql_db.py", line 354, in execute
res = self._obj.execute(query, params)
```
After this commit, user can not click on ``Reset Password`` button multiple times.
sentry-5661309399
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#190833
Forward-Port-Of: odoo/odoo#184862- add check on `employee_id` to the contract domain to exclude templates from the contract count on the stat buttons as it gives misleading info about the real contracts count Task: 4402795 Forward-Port-Of: odoo/odoo#192145
Original PR description
- add check on `employee_id` to the contract domain to exclude templates from the contract count on the stat buttons as it gives misleading info about the real contracts count Task: 4402795 Forward-Port-Of: odoo/odoo#192145
**Steps to reproduce:** - Install l10n_es_edi_tbai - Switch to a Spanish company (e.g. ES Company) - Create an invoice with "Simplified Invoice Partner (ES)" as customer - Confirm the invoice - Process the invoice with "TicketBAI (ES)" service **Issue:** The generated XML has 2 regime keys (02 and 52) for <ClaveRegimenIvaOpTrascendencia> that are not compatible with each other. From the documentation, regime key "52" (for simplified invoices) can only be associated with regime key "51"
Original PR description
**Steps to reproduce:** - Install l10n_es_edi_tbai - Switch to a Spanish company (e.g. ES Company) - Create an invoice with "Simplified Invoice Partner (ES)" as customer - Confirm the invoice - Process the invoice with "TicketBAI (ES)" service **Issue:** The generated XML has 2 regime keys (02 and 52) for <ClaveRegimenIvaOpTrascendencia> that are not compatible with each other. From the documentation, regime key "52" (for simplified invoices) can only be associated with regime key "51", which is not supported for the moment. **Solution:** If the "Simplified Invoice Partner" is used, only the regime key "52" is used. opw-4332052 opw-4355424 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192687 Forward-Port-Of: odoo/odoo#192448
Issue: In the POS settings, even after disabling the preparation display option, it remains enabled after saving. Steps to reproduce: -In POS configuration -Ensure the Pay after option is set to each order. -Disable self ordering and uncheck the preparation display option, save. Explanation: In res_config_settings.py of pos_self_order, https://github.com/odoo/odoo/commit/8ee8010cf67f20c4eb28a334cc943bfedf2dd0d1 added a check to ensure that the preparation display is enabled if self-orde
Original PR description
Issue: In the POS settings, even after disabling the preparation display option, it remains enabled after saving. Steps to reproduce: -In POS configuration -Ensure the Pay after option is set to each order. -Disable self ordering and uncheck the preparation display option, save. Explanation: In res_config_settings.py of pos_self_order, https://github.com/odoo/odoo/commit/8ee8010cf67f20c4eb28a334cc943bfedf2dd0d1 added a check to ensure that the preparation display is enabled if self-ordering is active. However, it was still automatically enabling the preparation display even when self-ordering was disabled. opw-4225668 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183601
If you create a pricelist rule with a discount that has a valid date range, that discount is only applied if the SO was created in that range. Even if it is confirmed within the valid date range. Fix: For website_sale orders we consider the date to be the current time when computing the price. opw-4375643 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191538
Original PR description
If you create a pricelist rule with a discount that has a valid date range, that discount is only applied if the SO was created in that range. Even if it is confirmed within the valid date range. Fix: For website_sale orders we consider the date to be the current time when computing the price. opw-4375643 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191538
Current behavior before PR: When multiple types of lists were selected and the deleteBackward operation was performed, the list type remained unchanged. Desired behavior after PR is merged: When deleteBackward is pressed with multiple types of lists selected, and all selected content is removed, if the anchor node's list item is empty, that list item type will change to match the type of the list where the deleteBackward operation started. task:4187739 Forward-Port-Of: odoo/odoo#191
Original PR description
Current behavior before PR: When multiple types of lists were selected and the deleteBackward operation was performed, the list type remained unchanged. Desired behavior after PR is merged: When deleteBackward is pressed with multiple types of lists selected, and all selected content is removed, if the anchor node's list item is empty, that list item type will change to match the type of the list where the deleteBackward operation started. task:4187739 Forward-Port-Of: odoo/odoo#191915 Forward-Port-Of: odoo/odoo#180687
In Odoo, an issue araised where the "Expected Arrival" date field was overlapped when zooming in. This was due to the button "action_purchase_vendor_delay_report". To adress this, the related button was encapsulated within a <div> element. This change ensure that the layout remains consistent and the elements does not overlap regardless of the zoom level. opw-4316093 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187
Original PR description
In Odoo, an issue araised where the "Expected Arrival" date field was overlapped when zooming in. This was due to the button "action_purchase_vendor_delay_report". To adress this, the related button was encapsulated within a <div> element. This change ensure that the layout remains consistent and the elements does not overlap regardless of the zoom level. opw-4316093 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187179
Before this commit: pos_stripe doesn't specify a Stripe version when doing its requests. Because of this, Stripe defaults to the API version defined on the Stripe account. This varies from customer to customer, as it is automatically configured to use the latest API version available when the first API request is received. Stripe regularly makes breaking changes to their API: https://docs.stripe.com/changelog?breaking=true for example removing the `charges` attribute: https://docs.stripe.com
Original PR description
Before this commit: pos_stripe doesn't specify a Stripe version when doing its requests. Because of this, Stripe defaults to the API version defined on the Stripe account. This varies from customer to customer, as it is automatically configured to use the latest API version available when the first API request is received. Stripe regularly makes breaking changes to their API: https://docs.stripe.com/changelog?breaking=true for example removing the `charges` attribute: https://docs.stripe.com/changelog/2022-11-15/removes-charges-attribute-paymentintent which we use in pos_stripe. After this commit: We rely on payment_stripe._stripe_make_request which hardcode the API version number. Such change was already started in `pos_stripe.stripe_capture_payment` opw-4375876 Forward-Port-Of: odoo/odoo#192008
Those constraints are blocking the flow for no good reason as we - don't find them in the official documentation - they don't really make sense in the context of a credit note Therefore we decide to remove them for credit notes. They don't seem to be required for the facturx validity. task-4454115 Forward-Port-Of: odoo/odoo#192495
Original PR description
Those constraints are blocking the flow for no good reason as we - don't find them in the official documentation - they don't really make sense in the context of a credit note Therefore we decide to remove them for credit notes. They don't seem to be required for the facturx validity. task-4454115 Forward-Port-Of: odoo/odoo#192495
When exporting a SA E-invoice file, the system needs to collect invoice line without downpayment lines. However, when collecting tax values, because of an error correction mechanism, the tax amount will still include the amount of the downpayment tax line Steps to reproduce (with SA localization installed and SA company): - Create a SO of 1000$ with 15% tax - Make a downpayment of 100$ with 15% tax and confirm - Make the final invoice with downpayment deducted - Confirm and send e-invo
Original PR description
When exporting a SA E-invoice file, the system needs to collect invoice line without downpayment lines. However, when collecting tax values, because of an error correction mechanism, the tax amount…
When exporting a SA E-invoice file, the system needs to collect invoice line without downpayment lines. However, when collecting tax values, because of an error correction mechanism, the tax amount will still include the amount of the downpayment tax line Steps to reproduce (with SA localization installed and SA company): - Create a SO of 1000$ with 15% tax - Make a downpayment of 100$ with 15% tax and confirm - Make the final invoice with downpayment deducted - Confirm and send e-invoice for validation Issue: The invoice is validated, but a warning is logged ``` Invoice was Accepted by ZATCA (with Warnings) The invoice was accepted by ZATCA, but returned warnings. Please, check the response below: BR-CO-17: VAT category tax amount (BT-117) = VAT category taxable amount (BT-116) x (VAT category rate (BT-119) / 100), rounded to two decimals. BR-S-09: The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where VAT category code (BT-118) is Standard rated shall equal the VAT category taxable amount (BT-116) multiplied by the VAT category rate (BT-119). ``` As the warning states the is an issue with the tax computation. When collecting amounts from the final invoice, we should filter out downpayment amounts, but due to the error correction mechanism introduced to account for manual modification of the journal items, the filter is ignored, so we will have the filtered base amount (1000) and the unfiltered tax amount (135 instead of 150) A possible solution is to avoid the error correction when we know we need to filter invoice lines opw-4380798 Forward-Port-Of: odoo/odoo#191867
…wnload Current behavior before PR: When using the "Download logs" button, from the IoT box form view, an Internal Server Error is raised every time. ```py Internal Server Error : Log file configuration is not set ``` Description of the issue/feature this PR addresses: New IoT Box images are missing the default `logfile` parameter in their config. This parameter is required for log downloading, and cannot be left empty. The `logfile` parameter has been removed from the `odoo.conf`
Original PR description
…wnload Current behavior before PR: When using the "Download logs" button, from the IoT box form view, an Internal Server Error is raised every time. ```py Internal Server Error : Log file…
…wnload Current behavior before PR: When using the "Download logs" button, from the IoT box form view, an Internal Server Error is raised every time. ```py Internal Server Error : Log file configuration is not set ``` Description of the issue/feature this PR addresses: New IoT Box images are missing the default `logfile` parameter in their config. This parameter is required for log downloading, and cannot be left empty. The `logfile` parameter has been removed from the `odoo.conf` config file in PR #169633. However, it is still explicitly mentioned as `/var/log/odoo/odoo-server.log` in two other files: https://github.com/odoo/odoo/blob/451a956a22015034b8c35bd0d9a860b78442af7f/addons/hw_posbox_homepage/controllers/homepage.py#L74 and https://github.com/odoo/odoo/blob/451a956a22015034b8c35bd0d9a860b78442af7f/addons/point_of_sale/tools/posbox/overwrite_before_init/etc/init_posbox_image.sh#L28 As such, a fallback to the default `/var/log/odoo/odoo-server.log` is added. Desired behavior after PR is merged: The Logs can be downloaded from the IoT box form view without receiving an Internal Server Error. opw-4443593 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192867
Issue: - run the `test_account_manager_user_can_create_product` with `account`and its dependencies as the only modules installed - error is given as `product` is not a valid product type (it is added in the `stock` module) Solution: - replace `product` with a product type that is defined in one of the dependencies --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192462
Original PR description
Issue: - run the `test_account_manager_user_can_create_product` with `account`and its dependencies as the only modules installed - error is given as `product` is not a valid product type (it is added in the `stock` module) Solution: - replace `product` with a product type that is defined in one of the dependencies --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192462