Tuesday, October 22, 2024
41 changes · 18.0
Enhancements to existing features
Financial reports now show a clearer warning when a custom handler is configured. This makes the message easier for users to understand and reduces confusion caused by overly technical wording.
Original PR description
For usability; the previous message caused a bit of confusion, and was too technical to actually be understandable.
Resolved issues and error corrections
This fixes an issue where some customer or vendor contact information used by the accounting print-and-send flow was not always calculated correctly. It helps ensure documents are prepared with the right partner details, reducing errors in outgoing accounting communications.
Original PR description
With the last refactor of the Print & Send we added some non-stored fields, which are not correctly computed. task-no
Miscellaneous changes
Issue: if 'sequence' in vals and self and self[-1].id == self._prefetch_ids[-1]: TypeError: 'PrefetchX2many' object is not subscriptable Cause of the issue: PrefetchX2many object does not have __getitem__ method, only __iter__ --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183224
Original PR description
Issue: if 'sequence' in vals and self and self[-1].id == self._prefetch_ids[-1]: TypeError: 'PrefetchX2many' object is not subscriptable Cause of the issue: PrefetchX2many object does not have __getitem__ method, only __iter__ --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183224
This update simplifies the documentation shown in Studio for character field options by removing confusing placeholder-related options. Business users benefit from clearer configuration choices and less risk of selecting options that are only useful in specialized template or report scenarios.
Original PR description
Since dynamic_placeholder option was confusing in studio, compared to the recently added placeholder_field option. And due to the poor usage and confusion it makes besides mail templates or reports, we decided to remove documentation for those options, and keep only the option that makes sense. task-3901821
This fix updates automated point-of-sale test journeys so pop-up windows are handled consistently before the next step runs. It helps reduce false test failures and improves confidence in point-of-sale, loyalty, and restaurant workflows without changing the customer-facing product.
Original PR description
In this commit, we make sure to either close the modal before continuing the tour (so that the following steps are not done with an open modal) or to make it explicit that the modal is open in the current step.
This fix prevents crashes when creating or opening Indian withholding tax records that do not yet have all fields filled in. It also avoids errors when the withholding wizard is opened without selected records, making the workflow more reliable for users.
Original PR description
Added a check for `tax_source_type` and in the `_compute_display_name` method to handle cases where these fields may be `False` for new records. This prevents errors caused by calling `upper()` on a `False` value. Added a check on active_ids to prevent calling `len()` on empty value
This fix updates purchase order tests so delivery term information is set in the right place, avoiding dependency on fields only shown by another module. It helps keep automated checks reliable without changing day-to-day purchasing workflows.
Original PR description
The incorterm_id fields is defined in `purchase` but visible in the form view in `purchase_stock` module. In order to use it in test. We fill them outside the `Form` wrapper. `incorterm_location` is defined in `purchase_stock` thus is removed. runbot: 75128 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
The subcontracting portal page now provides enough viewing space for purchase order details. This makes it easier for users to review subcontracting information without struggling with a cramped display.
Original PR description
Prior to this commit, the portal view height was very small that users could not see purchase orders details easily. This commit fixes that issue. closes odoo/odoo#181390 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
The accounting reports menu now correctly disables the XML and Copy to Documents buttons when users have not selected the full company and branch hierarchy. This prevents actions from being taken on incomplete report scopes, reducing confusion and avoiding incorrect document exports.
Original PR description
After [this refactoring] a regression occurred. Where previously the "XML" and "Copy to Documents" buttons were disabled when we didn't have the whole hierarchy of a company with its branches selected, it is not anymore. This commit fixes that. [task-4260501](https://www.odoo.com/odoo/all-tasks/4260501) [this refactoring]: https://github.com/odoo/enterprise/commit/1ea5dc3227913826a205b164c19e4771babc3326
Odoo Studio now shows the newer dynamic placeholder setting for text fields in a clearer way, reducing confusion when configuring forms. This helps users choose the right placeholder behavior without seeing an option that only worked in limited cases.
Original PR description
This commit changes the way we display placeholder options for the CharField when being selected by studio. Previously, it was confusing to edit the dynamic_placeholder option, which needs another option to work properly, and which don't make much sense in most cases. Instead, we choose to support only the recently added placeholder_field option, and to name it Dynamic Placeholder in the sidebar. task-3901821
This update fixes incorrect codes used for Group S work entry types in Belgian payroll. Correct codes help ensure payroll entries are classified properly for reporting and processing.
Original PR description
The groups s codes for work entry types were wrong. this commit adds the right codes for the work entry types. task-4221186
### Steps to reproduce: - In Settings, enable "Multi-Step Routes" - In the Routes, unarchive MTO - Create 2 storable products P1, P2 with routes MTO + Buy - Set a different vendor on P1/P2 and ensure you have 0 units in stock - Create and confirm a sale order with 2 lines: - 1 x P1 - 1 x P2 > A delivery and 2 purchase order were created (one for each product) - Cancel the purchase orderfor P2 (it will not work with P1 hehe) - Go back to the SO and decrease the qty of P2 to 0 ###
Original PR description
### Steps to reproduce: - In Settings, enable "Multi-Step Routes" - In the Routes, unarchive MTO - Create 2 storable products P1, P2 with routes MTO + Buy - Set a different vendor on P1/P2 and ensure…
### Steps to reproduce: - In Settings, enable "Multi-Step Routes" - In the Routes, unarchive MTO - Create 2 storable products P1, P2 with routes MTO + Buy - Set a different vendor on P1/P2 and ensure you have 0 units in stock - Create and confirm a sale order with 2 lines: - 1 x P1 - 1 x P2 > A delivery and 2 purchase order were created (one for each product) - Cancel the purchase orderfor P2 (it will not work with P1 hehe) - Go back to the SO and decrease the qty of P2 to 0 #### > A return is created from patner to stock instead of updating the P2 move of the delivery ### Cause of the issue: When the sale order was confirmed the moves created for the delivery were both used the same procurment group and their `procure_method` was set to `make_to_order`. When the purchase order for P2 is cancelled, the delivery move associated with the related sol is cancelled and its `procure_method` is set to `make_to_stock` here: https://github.com/odoo/odoo/blob/c424fded8660de628bfcf3937806cc72c8410434/addons/purchase_stock/models/purchase.py#L148 Then, when you decrease the qty of the SOL from 0 to 1, a procurement for -1 unit of P2 will be created and run by the `_action_launch_stock_rule`. A negative move will then be created and confirm with a `procure_method`: `make_to_stock` here: https://github.com/odoo/odoo/blob/c424fded8660de628bfcf3937806cc72c8410434/addons/stock/models/stock_rule.py#L275-L277 Because the `procure_method` used at the creation of the negative move is determined from the `procure_method` of the first move related to the procurement group with a positive qty (here the P1 move): https://github.com/odoo/odoo/blob/1fd336e5f321e5256accff6b5a4032b237dce528/addons/stock/models/stock_rule.py#L257-L260 As such, the negative P2 move will have a different `procure_method` than the positive P2 move and they will not be merged here: https://github.com/odoo/odoo/blob/1fd336e5f321e5256accff6b5a4032b237dce528/addons/stock/models/stock_move.py#L1384 ### Fix: The fix proposed in commit 65d5e7900f41aa7f65159f8f4cdb0c6638eaf8ca and introducing the lines: https://github.com/odoo/odoo/blob/1fd336e5f321e5256accff6b5a4032b237dce528/addons/stock/models/stock_rule.py#L257-L260 works perfectly fine in most situtations but should considers only the moves related to the procurment group that concerns the same product to also work in the above case. opw-4214369 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183854 Forward-Port-Of: odoo/odoo#182802
**Steps to reproduce:** - Install Accounting and l10n_it_edi - Switch to an Italian company (e.g. IT Company) - Create an invoice: * Customer: [an Italian customer] * Product: [any] * Taxes: [a split payment tax] (e.g. 22% SP) - Confirm the invoice - Process to E-invoicing service - Check the XML of the electronic invoice => <ImportoTotaleDocumento> node is including the tax amount - Create a credit note (Full refund) - Confirm the credit note - Process to E-invoicing service
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_it_edi - Switch to an Italian company (e.g. IT Company) - Create an invoice: * Customer: [an Italian customer] * Product: [any] * Taxes: [a split payment tax] (e.g. 22% SP) - Confirm the invoice - Process to E-invoicing service - Check the XML of the electronic invoice => <ImportoTotaleDocumento> node is including the tax amount - Create a credit note (Full refund) - Confirm the credit note - Process to E-invoicing service - Check the XML of the credit note **Issue:** <ImportoTotaleDocumento> node is not including the tax amount. Task [link](https://www.odoo.com/odoo/project/967/tasks/4161435) opw-4161435 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184334 Forward-Port-Of: odoo/odoo#183774
- Create a Sales Order, add a product and confirm - Open POS session - Click Quotations/Order button - Select the created SO - Apply a downpayment - Validate the downpayment order - Go back to the Sales Order - Deliver the product if necessary - Click 'Create Invoice' Issue: The downpayment amount paid via POS is not taken into account in computation of 'Already invoiced' and 'Amount to invoice' A solution is to add a component to keep track of the downpayments made via POS op
Original PR description
- Create a Sales Order, add a product and confirm - Open POS session - Click Quotations/Order button - Select the created SO - Apply a downpayment - Validate the downpayment order - Go back to the Sales Order - Deliver the product if necessary - Click 'Create Invoice' Issue: The downpayment amount paid via POS is not taken into account in computation of 'Already invoiced' and 'Amount to invoice' A solution is to add a component to keep track of the downpayments made via POS opw-4131695 Forward-Port-Of: odoo/odoo#184303 Forward-Port-Of: odoo/odoo#178844
This Error occurs when a user tries to archive multiple journals. Steps to reproduce: - Install the ```account``` module - Go to Invoicing / Configuration / Accounting / Journals. - Select two or more journals and try to archive them. ```ValueError: Expected singleton: account.journal(15, 18)``` An error occurs at [1] because the system attempts to retrieve the id from 'self', which contains multiple records. link [1]:https://github.com/odoo/odoo/blob/1f7debc24bab4e0a7f2ef0d85e5
Original PR description
This Error occurs when a user tries to archive multiple journals. Steps to reproduce: - Install the ```account``` module - Go to Invoicing / Configuration / Accounting / Journals. - Select two or more journals and try to archive them. ```ValueError: Expected singleton: account.journal(15, 18)``` An error occurs at [1] because the system attempts to retrieve the id from 'self', which contains multiple records. link [1]:https://github.com/odoo/odoo/blob/1f7debc24bab4e0a7f2ef0d85e50d9381e1826cd/addons/account/models/account_journal.py#L801 To resolve this issue, Use an ```ids``` instead of an ```id``` to get a multiple records. Sentry-5917175119 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182664 Forward-Port-Of: odoo/odoo#182043
When starting a PoS session a useless sequence was created every time Steps to reproduce: ------------------- * Open a PoS session on different days > Observation: Go to the sequence list in the settings, there is one sequence for each days you opened a session Why the fix: ------------ The sequence was actually not used so we just remove it. opw-4166554 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184503
Original PR description
When starting a PoS session a useless sequence was created every time Steps to reproduce: ------------------- * Open a PoS session on different days > Observation: Go to the sequence list in the settings, there is one sequence for each days you opened a session Why the fix: ------------ The sequence was actually not used so we just remove it. opw-4166554 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184503
Description of the issue/feature this PR addresses: It is necessary to be able to select document type "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund. Current behavior before PR: User is not able to select document types "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund. Desired behavior after PR is merged: User is able to select document types "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund. Task Adhoc side: 40557 Tas
Original PR description
Description of the issue/feature this PR addresses:
It is necessary to be able to select document type "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund.
Current behavior before PR:
User is not able to select document types "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund.
Desired behavior after PR is merged:
User is able to select document types "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund.
Task Adhoc side: 40557
Task latam: 1254
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#176858Before this commit: == - When there is no order line(s) in the order, a message saying 'Start adding products' along with a cart icon will be displayed on the receipt. After this commit: == - Added a check for the product image, which will be displayed when order line(s) exist. task - 4267700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184276
Original PR description
Before this commit: == - When there is no order line(s) in the order, a message saying 'Start adding products' along with a cart icon will be displayed on the receipt. After this commit: == - Added a check for the product image, which will be displayed when order line(s) exist. task - 4267700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184276
Backend translations are not loaded in the frontend, and since the product/combo configurators are defined in the backend and overridden in the frontend, any translations used both in the backend and the frontend need to be defined in both. opw-4182798 Forward-Port-Of: odoo/odoo#184486
Original PR description
Backend translations are not loaded in the frontend, and since the product/combo configurators are defined in the backend and overridden in the frontend, any translations used both in the backend and the frontend need to be defined in both. opw-4182798 Forward-Port-Of: odoo/odoo#184486
This commit fixes an issue with the display of list monetary aggregates where the error message saying that different currencies cannot be aggregated would show even when no aggregate method is set. Steps to reproduce: - Create a list view with monetary field and different currencies - Don't set an aggregation method - An aggregation row is wrongly added and contains the error message Original PR: https://github.com/odoo/odoo/pull/132272 Forward-Port-Of: odoo/odoo#184302 Forward-Port-O
Original PR description
This commit fixes an issue with the display of list monetary aggregates where the error message saying that different currencies cannot be aggregated would show even when no aggregate method is set. Steps to reproduce: - Create a list view with monetary field and different currencies - Don't set an aggregation method - An aggregation row is wrongly added and contains the error message Original PR: https://github.com/odoo/odoo/pull/132272 Forward-Port-Of: odoo/odoo#184302 Forward-Port-Of: odoo/odoo#183730
Versions -------- - 17.0+ Steps ----- 1. Create a coupon with free shipping reward; 2. create an eWallet with enough points for a free purchase; 3. create at least 2 shipping methods with different prices; 4. in eCommerce, add a product to cart, and go to checkout; 5. apply coupon; 6. go to payment & apply eWallet; 7. switch between shipping methods. Issue ----- The eWallet amount on the right doesn't get updated after changing shipping costs. Cause ----- Commit e08449e42a
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a coupon with free shipping reward; 2. create an eWallet with enough points for a free purchase; 3. create at least 2 shipping methods with different…
Versions -------- - 17.0+ Steps ----- 1. Create a coupon with free shipping reward; 2. create an eWallet with enough points for a free purchase; 3. create at least 2 shipping methods with different prices; 4. in eCommerce, add a product to cart, and go to checkout; 5. apply coupon; 6. go to payment & apply eWallet; 7. switch between shipping methods. Issue ----- The eWallet amount on the right doesn't get updated after changing shipping costs. Cause ----- Commit e08449e42a01 allowed for eWallet to update after changes, using a `_handleCarrierUpdateResultBadge` override. Commit 453c6169e080 merged the `_handleCarrierUpdateResult` & `_handleCarrierUpdateResultBadge` methods. Because of an `else` that was left in by accident, it either displays a shipping discount *or* it updates the eWallet. Solution -------- Remove the stray `else` so that the conditional branches are no longer mutually exclusive. opw-4150258 Forward-Port-Of: odoo/odoo#181325 Forward-Port-Of: odoo/odoo#180347
Problem: When editing images, the company context is not respected during operations such as `get_image_info` and `modify_image`. This occurs because we use `self._clean_context()` during creating of attachment which was introduced [here](https://github.com/odoo/odoo/commit/a137f22363ff538ab86f50d15851730af1b8ed76) , it strips the company from the context. This fix ensures that company information is skipped for these methods as well, similar to attachment creation. Steps to Reproduce: - Se
Original PR description
Problem: When editing images, the company context is not respected during operations such as `get_image_info` and `modify_image`. This occurs because we use `self._clean_context()` during creating of attachment which was introduced [here](https://github.com/odoo/odoo/commit/a137f22363ff538ab86f50d15851730af1b8ed76) , it strips the company from the context. This fix ensures that company information is skipped for these methods as well, similar to attachment creation. Steps to Reproduce: - Select a company other than the default one. - Create a quotation. - In the description, add an image and save. - Try to crop the image and save again. The operation fails due to the company context issue. opw-4173391 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183112
Steps to reproduce the bug: - In website dit mode. - Click on the footer. - Enable the "Scroll Top Button" option for the footer. - Disable the "Copyright" option for the footer. - Bug: There is a white space below the footer. task-4208475 Forward-Port-Of: odoo/odoo#183514
Original PR description
Steps to reproduce the bug: - In website dit mode. - Click on the footer. - Enable the "Scroll Top Button" option for the footer. - Disable the "Copyright" option for the footer. - Bug: There is a white space below the footer. task-4208475 Forward-Port-Of: odoo/odoo#183514
New image development was started in August but now being released in October, so bump version from 24.08 -> 24.10. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184318
Original PR description
New image development was started in August but now being released in October, so bump version from 24.08 -> 24.10. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184318
Versions -------- - 16.0+ Steps ----- 1. Create a zero-priced product template; 2. add some attribute values; 3. configure price extras for the attributes; 4. configure eCommerce to prevent sale of zero-priced products; 5. go to eCommerce products page. Issue ----- Product is displayed as "Not Available For Sale," even though you can click on it, select a price-extra attribute, add it to cart, and purchase it. Cause ----- The template doesn't consider potential `price_extra`
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Create a zero-priced product template; 2. add some attribute values; 3. configure price extras for the attributes; 4. configure eCommerce to prevent sale of zero-priced products; 5. go to eCommerce products page. Issue ----- Product is displayed as "Not Available For Sale," even though you can click on it, select a price-extra attribute, add it to cart, and purchase it. Cause ----- The template doesn't consider potential `price_extra` attributes when displaying the not available message. Solution -------- Add a `t-elif` element to the template, checking if the product has any non-zero price-extra attribute values, if so, don't display the not available message, but also don't display the zero price. opw-4225183 Forward-Port-Of: odoo/odoo#184576 Forward-Port-Of: odoo/odoo#184052
Follow up of https://github.com/odoo/odoo/pull/171393 The method should forward all kwargs to the super call. Issue manifesting in particular in 18.0 when attempting to fix cloud storage at https://github.com/odoo/odoo/pull/184331 Forward-Port-Of: odoo/odoo#184506
Original PR description
Follow up of https://github.com/odoo/odoo/pull/171393 The method should forward all kwargs to the super call. Issue manifesting in particular in 18.0 when attempting to fix cloud storage at https://github.com/odoo/odoo/pull/184331 Forward-Port-Of: odoo/odoo#184506
Currently since TestFrontend has test methods and is imported/inherited, the same test is executed three times. Fixing it by extracting setup to an utility class --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184267 Forward-Port-Of: odoo/odoo#179344
Original PR description
Currently since TestFrontend has test methods and is imported/inherited, the same test is executed three times. Fixing it by extracting setup to an utility class --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184267 Forward-Port-Of: odoo/odoo#179344
The issue: We run the test under the assumption that an analytic plan with ID=2 exists. However, if the demo data hasn’t been loaded, this analytic plan won’t be available. The fix: Create the analytic plan runbot-60608 Forward-Port-Of: odoo/odoo#181399
Original PR description
The issue: We run the test under the assumption that an analytic plan with ID=2 exists. However, if the demo data hasn’t been loaded, this analytic plan won’t be available. The fix: Create the analytic plan runbot-60608 Forward-Port-Of: odoo/odoo#181399
When the user selects multiple companies and clicks on Refresh tax mapping, a traceback will appear. Steps to reproduce the error: - Install ``l10n_eu_oss`` module - Select multiple companies - Go to Invoicing > Configuration > Settings > Taxes > EU Intra-community Distance Selling > Click on Refresh tax mapping Traceback: ``` ValueError: Expected singleton: res.company(1, 2) File "odoo/http.py", line 2364, in __call__ response = request._serve_db() File "odoo/http.py",
Original PR description
When the user selects multiple companies and clicks on Refresh tax mapping, a traceback will appear. Steps to reproduce the error: - Install ``l10n_eu_oss`` module - Select multiple companies - Go to…
When the user selects multiple companies and clicks on Refresh tax mapping,
a traceback will appear.
Steps to reproduce the error:
- Install ``l10n_eu_oss`` module
- Select multiple companies
- Go to Invoicing > Configuration > Settings > Taxes >
EU Intra-community Distance Selling > Click on Refresh tax mapping
Traceback:
```
ValueError: Expected singleton: res.company(1, 2)
File "odoo/http.py", line 2364, in __call__
response = request._serve_db()
File "odoo/http.py", line 1891, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1954, 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 1921, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2168, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 330, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 728, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 40, in call_button
action = call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 517, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/l10n_eu_oss/models/res_config_settings.py", line 13, in refresh_eu_tax_mapping
self.env.companies._map_eu_taxes()
File "addons/l10n_eu_oss/models/res_company.py", line 34, in _map_eu_taxes
invoice_repartition_lines, refund_repartition_lines = company._get_repartition_lines_oss()
File "addons/l10n_eu_oss/models/res_company.py", line 105, in _get_repartition_lines_oss
self.ensure_one()
File "odoo/models.py", line 6213, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
https://github.com/odoo/odoo/blob/bbcef64e3296efa2b985e8d08dfe0573dc62dbb4/addons/l10n_eu_oss/models/res_company.py#L32
Here, ``self`` is used instead of ``company``, When self has multiple companies,
It will lead to the above traceback.
sentry-6002997139
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#184491Before this commit, when editing a message, we had to click twice on "Cancel" or "Save" to register the edit message action. This happens because while clicking on these action for the 1st time, composer intercepts a "focusout" event, which re-renders the template and thus the "Cancel" & "Save" buttons too, thus cancelling their action. The 2nd click doesn't trigger this focusout thus it works. This commit fixes the issue by moving code that generates the "Cancel or Save" text in a sub-com
Original PR description
Before this commit, when editing a message, we had to click twice on "Cancel" or "Save" to register the edit message action. This happens because while clicking on these action for the 1st time, composer intercepts a "focusout" event, which re-renders the template and thus the "Cancel" & "Save" buttons too, thus cancelling their action. The 2nd click doesn't trigger this focusout thus it works. This commit fixes the issue by moving code that generates the "Cancel or Save" text in a sub-component. Doing so ensures that the component is only rendered when needed, in this case when Composer.mode or ui.isSmall change. opw-4119283 Before  After  Forward-Port-Of: odoo/odoo#178066
Since https://github.com/odoo/enterprise/pull/70230, this test https://github.com/odoo/enterprise/blame/saas-17.4/account_batch_payment/tests/test_account_batch_payment.py#L86 was failing on nightly runbot builds (but weirdly not on regular builds, probably due to the timing of stored fields recomputation and constraint validation). Essentially, the constraint here https://github.com/odoo/enterprise/blob/saas-17.4/account_batch_payment/models/account_batch_payment.py#L170 broke. This happe
Original PR description
Since https://github.com/odoo/enterprise/pull/70230, this test https://github.com/odoo/enterprise/blame/saas-17.4/account_batch_payment/tests/test_account_batch_payment.py#L86 was failing on nightly…
Since https://github.com/odoo/enterprise/pull/70230, this test https://github.com/odoo/enterprise/blame/saas-17.4/account_batch_payment/tests/test_account_batch_payment.py#L86 was failing on nightly runbot builds (but weirdly not on regular builds, probably due to the timing of stored fields recomputation and constraint validation). Essentially, the constraint here https://github.com/odoo/enterprise/blob/saas-17.4/account_batch_payment/models/account_batch_payment.py#L170 broke. This happened because, when resetting the payment to draft in the test, we triggered this compute function on the account.payment https://github.com/odoo/enterprise/blob/saas-17.4/account_batch_payment/models/account_payment.py#L18. This compute function did not reassign the batch_payment_id field, but the ORM still considered it modified, and hence recomputed the payment method of the batch via this compute function https://github.com/odoo/enterprise/blob/saas-17.4/account_batch_payment/models/account_batch_payment.py#L69 . Then, this field triggered the constraint here https://github.com/odoo/enterprise/blob/saas-17.4/account_batch_payment/models/account_batch_payment.py#L149. The test raised then just when initializing the assertRaises, when the stored payment_method_id field of the batch got recomputed. It is possible to force it by flushing at that point, otherwise, it's not exactly deterministic. The part of the constraint ensuring a draft payment cannot be added to a batch is the problem. The test tries to set one of the payments in the batch back to draft, and if this happens, the batch will end up in a state that is inconsistent with its own constraint. We fix the issue by simply removing it. This check is done again anyway when validating the batch payment. Doing things this way, we ensure the scenario of the test works in every case, whatever crazy recomputations happen in the ORM. Forward-Port-Of: odoo/enterprise#71924
Forward-Port-Of: odoo/enterprise#72400 Forward-Port-Of: odoo/enterprise#72307
Original PR description
Forward-Port-Of: odoo/enterprise#72400 Forward-Port-Of: odoo/enterprise#72307
Current behaviour: --- When you click on the "request a document" link, then upload a document, you get a CSRF error Steps to reproduce: --- 1. Install documents 2. In documents, click the arrow next to "new", then "request" 3. Add a name, and a "request to", then click "request" 4. Go to messages, copy the link in the generated email 5. Paste the link in an incognito window 6. Upload a document, CSRF error Cause of the issue: --- The js file that adds the CSRF token (documents_
Original PR description
Current behaviour: --- When you click on the "request a document" link, then upload a document, you get a CSRF error Steps to reproduce: --- 1. Install documents 2. In documents, click the arrow next…
Current behaviour: --- When you click on the "request a document" link, then upload a document, you get a CSRF error Steps to reproduce: --- 1. Install documents 2. In documents, click the arrow next to "new", then "request" 3. Add a name, and a "request to", then click "request" 4. Go to messages, copy the link in the generated email 5. Paste the link in an incognito window 6. Upload a document, CSRF error Cause of the issue: --- The js file that adds the CSRF token (documents_public_pages.js) could not be loaded due to an error caused by website_sale_renting: `TypeError: odoo.define is not a function` The mixin file was loaded before the odoo module loader. Caused by: https://github.com/odoo/enterprise/commit/93d09071a08bd5de948886729d827b1c46e907d9 Fix: --- Put js code from website_sale_renting before owl.js which is right after assets_frontend_minimal, containing module_loader.js opw-4138333 Forward-Port-Of: odoo/enterprise#71921 Forward-Port-Of: odoo/enterprise#70577
Steps to reproduce the bug: - Create two Storable product: - “P1” -> product category A - “P2” -> product category B - Create a quality point: - picking type: receipt - product category: Cat A & Cat B - Measure: by quantity - Create a second quality point: - picking type: receipt - product category: Cat A - Measure: by quantity - Create a receipt of one unit of P1 and P2 - Confirm Problem: Four quality checks are created instead of three bec
Original PR description
Steps to reproduce the bug:
- Create two Storable product:
- “P1” -> product category A
- “P2” -> product category B
- Create a quality point:
- picking type: receipt
- product category: Cat A & Cat B
- Measure: by quantity
- Create a second quality point:
- picking type: receipt
- product category: Cat A
- Measure: by quantity
- Create a receipt of one unit of P1 and P2
- Confirm
Problem:
Four quality checks are created instead of three because we check if the quality point corresponds to the picking type and if the quality point has no product selected. However, we don't verify if a product category is also not set.
opw-4240859
Forward-Port-Of: odoo/enterprise#71709
Forward-Port-Of: odoo/enterprise#71453…ifferent trees Add a field at the end of the "left" subgroup and remove the "right" subgroup. ```xml <form> <group> <group> <field name="display_name" /> [ADD A FIELD] </group> [ REMOVE THIS GROUP <group> </group> ] </group> </form> ``` Before this commit, when "normalizing" the xpaths, the add field operation was aggregated with the remove operation because no unchanged node was found in between. We were left with the inheriting vi
Original PR description
…ifferent trees
Add a field at the end of the "left" subgroup and remove the "right" subgroup.
```xml
<form>
<group>
<group>
<field name="display_name" />
[ADD A FIELD]
</group>
[ REMOVE THIS GROUP
<group>
</group>
]
</group>
</form>
```
Before this commit, when "normalizing" the xpaths, the add field operation was aggregated with the remove operation because no unchanged node was found in between.
We were left with the inheriting view:
```xml
<xpath expr="[..]/group[2]" position="replace">
<field name="added_field" />
</xpath>
```
After this commit, this flow works and the two operations are independent.
part of task-4207793
Forward-Port-Of: odoo/enterprise#72273
Forward-Port-Of: odoo/enterprise#71289The model 349 wasn't working as expected, here are the points that have been changed: - Some keys were missing, in particular the keys R, D, and C. - Changed some wording of the report, such as replacing 'refunds' with 'rectifications'. - The biggest change was changing the way the lines are computed in the report. Before this commit, we used only the domain engine, but now we need to use a custom engine to handle the rectifications part. - Fixed some other bugs, like negative amount
Original PR description
The model 349 wasn't working as expected, here are the points that have been changed: - Some keys were missing, in particular the keys R, D, and C. - Changed some wording of the report, such as replacing 'refunds' with 'rectifications'. - The biggest change was changing the way the lines are computed in the report. Before this commit, we used only the domain engine, but now we need to use a custom engine to handle the rectifications part. - Fixed some other bugs, like negative amounts which are not supposed to appear as the report only deals with positive values, and also ensured the discounts on the move lines are computed correctly. task-3992046 Forward-Port-Of: odoo/enterprise#72389 Forward-Port-Of: odoo/enterprise#65074
Before this change, if a regular user was granted access to the IoT app, they would get a traceback on trying to pair an IoT box as they cannot access `ir.config_parameter`. This PR adds the missing `sudo` calls to fix this traceback and allow the user to pair an IoT box. task-4216519 Forward-Port-Of: odoo/enterprise#72199
Original PR description
Before this change, if a regular user was granted access to the IoT app, they would get a traceback on trying to pair an IoT box as they cannot access `ir.config_parameter`. This PR adds the missing `sudo` calls to fix this traceback and allow the user to pair an IoT box. task-4216519 Forward-Port-Of: odoo/enterprise#72199
Before this commit, when a user doesn't have any hr right, he can't see employee's picture. With this commit, this issue is fixed and the user can access to the public employee form when he clicks on this picture. And "mark as done" option in three dot menu is invisible if the goal is already done. task-4240631 Forward-Port-Of: odoo/enterprise#72189 Forward-Port-Of: odoo/enterprise#71459
Original PR description
Before this commit, when a user doesn't have any hr right, he can't see employee's picture. With this commit, this issue is fixed and the user can access to the public employee form when he clicks on this picture. And "mark as done" option in three dot menu is invisible if the goal is already done. task-4240631 Forward-Port-Of: odoo/enterprise#72189 Forward-Port-Of: odoo/enterprise#71459
Steps to reproduce: ------------------- - Create or rename any journal entry to have an empty name (Number). - Open GL and make sure that this entry is included in the report. - Click XLSX export, will give error: "TypeError: float() argument must be a string or a real number, not 'NoneType'". Cause ----- Since #50004, dynamic column width calculation for xlsx was added without handling the case where a filed can be empty. A typecast to float was done with exception for ValueError only
Original PR description
Steps to reproduce: ------------------- - Create or rename any journal entry to have an empty name (Number). - Open GL and make sure that this entry is included in the report. - Click XLSX export, will give error: "TypeError: float() argument must be a string or a real number, not 'NoneType'". Cause ----- Since #50004, dynamic column width calculation for xlsx was added without handling the case where a filed can be empty. A typecast to float was done with exception for ValueError only. Fix --- Add condition to check if the field is non empty before casting. Forward-Port-Of: odoo/enterprise#71295
Currently since TestFrontend has test methods and is imported/inherited, the same test is executed three times. Fixing it by extracting setup to an utility class Forward-Port-Of: odoo/enterprise#72269 Forward-Port-Of: odoo/enterprise#69552
Original PR description
Currently since TestFrontend has test methods and is imported/inherited, the same test is executed three times. Fixing it by extracting setup to an utility class Forward-Port-Of: odoo/enterprise#72269 Forward-Port-Of: odoo/enterprise#69552
Steps to reproduce =================== - Create a booking using any appointment type. - Delete that booking from Gantt view. - The confirmation dialog is missing when deleting the record. This PR addresses the issue of the missing confirmation dialog while deleting calendar event records. Task-4228681 Forward-Port-Of: odoo/enterprise#71627
Original PR description
Steps to reproduce =================== - Create a booking using any appointment type. - Delete that booking from Gantt view. - The confirmation dialog is missing when deleting the record. This PR addresses the issue of the missing confirmation dialog while deleting calendar event records. Task-4228681 Forward-Port-Of: odoo/enterprise#71627