Friday, October 25, 2024
43 changes · saas-17.2
Resolved issues and error corrections
Updated demo setup data for several country localizations so it is marked correctly when demo data is installed. This prevents unnecessary warning messages during automated checks and keeps localization modules cleaner for deployments.
Original PR description
Correctly set the flag `install_demo` in demo data for some localisation, they were triggering some warnings otherwise. RunbotError: 103691
Miscellaneous changes
Some cities that process service invoices [1] have stricter hsCode validations than others and error on the hsCode we send. Avalara requires periods to be removed from the hsCode field for goods transactions. This was already the case. For services they inform us that the periods should be kept but leading zeroes should be stripped [2]. [1] e.g. Belo Horizonte [2] There's no documentation on this. This was specified by Avalara support in an internal support ticket. opw-4009684 Forward
Original PR description
Some cities that process service invoices [1] have stricter hsCode validations than others and error on the hsCode we send. Avalara requires periods to be removed from the hsCode field for goods transactions. This was already the case. For services they inform us that the periods should be kept but leading zeroes should be stripped [2]. [1] e.g. Belo Horizonte [2] There's no documentation on this. This was specified by Avalara support in an internal support ticket. opw-4009684 Forward-Port-Of: odoo/enterprise#72641
Add a compound index on (`res_model`, `res_id`) to support domains searching documents based on those criteria, similarly to `ir_attachment_res_idx` on `ir.attachment`. Forward-Port-Of: odoo/enterprise#72426
Original PR description
Add a compound index on (`res_model`, `res_id`) to support domains searching documents based on those criteria, similarly to `ir_attachment_res_idx` on `ir.attachment`. Forward-Port-Of: odoo/enterprise#72426
Let's say you have: - One statement line of 3000 USD / 1000 MXN (rate 1:3) - Three invoices of 1000 USD / 500MXN (rate 1:2) => If you reconcile in the bank widget, the statement entry amounts will be divided by 3 ending with 3 lines of 1000 USD and 333.33 MXN leaving a 0.01 unmatched. This can be an issue for the validation of payment EDI for localizations like Mexican one. This PR gives more flexibility to user when dealing when bank reconciliation in multiple currencies by allowing to
Original PR description
Let's say you have: - One statement line of 3000 USD / 1000 MXN (rate 1:3) - Three invoices of 1000 USD / 500MXN (rate 1:2) => If you reconcile in the bank widget, the statement entry amounts will be divided by 3 ending with 3 lines of 1000 USD and 333.33 MXN leaving a 0.01 unmatched. This can be an issue for the validation of payment EDI for localizations like Mexican one. This PR gives more flexibility to user when dealing when bank reconciliation in multiple currencies by allowing to edit amounts on generated exchange moves to allocate this small difference. opw-4128899 Forward-Port-Of: odoo/enterprise#72212
steps: -> populate the portal user's appointments with enough appointments to have multiple pages in the portal -> go on the portal, filter by "past" -> go to page 2 --> the filter by "past" is removed from the url opw-4236596 Forward-Port-Of: odoo/enterprise#71965
Original PR description
steps: -> populate the portal user's appointments with enough appointments to have multiple pages in the portal -> go on the portal, filter by "past" -> go to page 2 --> the filter by "past" is removed from the url opw-4236596 Forward-Port-Of: odoo/enterprise#71965
This commit introduces an easy way to recognize "orders" which are intended to settle customer accounts. opw-4185144 Community PR: https://github.com/odoo/odoo/pull/183682 Forward-Port-Of: odoo/enterprise#71958
Original PR description
This commit introduces an easy way to recognize "orders" which are intended to settle customer accounts. opw-4185144 Community PR: https://github.com/odoo/odoo/pull/183682 Forward-Port-Of: odoo/enterprise#71958
The query count in single module build is higher than the one with all modules installed. - test_mail_enterprise   - test_mail_enterprise + documents_project    - test_mail_enterprise + documents_project   In summary, a one2many fields document_ids on document_projects triggers an [orm optimisation](https://github.com/odoo/odoo/pull/111651/files) leading to 10 less queries. In 16.0 the query count adapted in an all-enterprise build fails in single module In 17.0 a regression of performance was missed because a margin is added on a bunch of query count that didn't break in the all-enterprise build This pr proposes to add a field with the corresponding optimization in the test module in stable, to have reliable query counter. This field will be moved to the document module in master. RunbotError-65777 Forward-Port-Of: odoo/enterprise#72700 Forward-Port-Of: odoo/enterprise#72598
### Steps to reproduce: - Create and configure a Sendcloud shipping method - Create a Contact Bob - Create a subconcat of type delivery for Bob without setting any name > by default its display name will be "Bob, delivery address" - Create a sale order for Bob - Add a Sendcloud shipment method to that SO and confirm the SO - Go on the associated delivery and try to validate it ### Expected behavior: You should raise a user error telling you that you a pickup point was required fo
Original PR description
### Steps to reproduce: - Create and configure a Sendcloud shipping method - Create a Contact Bob - Create a subconcat of type delivery for Bob without setting any name > by default its display name…
### Steps to reproduce: - Create and configure a Sendcloud shipping method - Create a Contact Bob - Create a subconcat of type delivery for Bob without setting any name > by default its display name will be "Bob, delivery address" - Create a sale order for Bob - Add a Sendcloud shipment method to that SO and confirm the SO - Go on the associated delivery and try to validate it ### Expected behavior: You should raise a user error telling you that you a pickup point was required for the selected shipping method. ### Current behavior: You raise a traceback prior to that point. ### Cause of the issue: Since you did not set a name on your delivery partner the code will break as soon as you try to generate the parcels data because "False" is not iterable, see: https://github.com/odoo/enterprise/blob/37577535a4482eaa1250b41136b47b3613eb7693/delivery_sendcloud/models/sendcloud_service.py#L576-L577 ### Fix: If for some reason the name of the delivery partner has been removed or was unset (e.g. display name is of the form: Bob, Delivery address), the name of its parent should be used to generate the parcel data. Note: This fix should normally not be that relevant, because, if you were to select a pickup point, the partner used to generate the parcel would already be the parent partner and is guarranteed to have a name: https://github.com/odoo/enterprise/blob/37577535a4482eaa1250b41136b47b3613eb7693/delivery_sendcloud/models/sendcloud_service.py#L556-L561already However, now, if you proceed with this flow without any pickup point (which you can only select form the website) you will now raise a relevant user error: #### Invalid Operation: "A service point is required for the selected shipping method" opw-4118362 Forward-Port-Of: odoo/enterprise#72076
As Debian wants to remove pypdf2 and keep only pypdf (4.3) in trixie, so we need to be compatible otherwise Odoo could not be released in the next Debian. Forward-Port-Of: odoo/enterprise#71676
Original PR description
As Debian wants to remove pypdf2 and keep only pypdf (4.3) in trixie, so we need to be compatible otherwise Odoo could not be released in the next Debian. Forward-Port-Of: odoo/enterprise#71676
Steps to reproduce: - multi-currency - upload an expense with a differenct currency than the company - OCRize it Issue: The exchange rate is always 1:1 Cause: We don't fetch the echange rate with OCR and the compute's cannot fetch it since we cill never satisfy the condition https://github.com/odoo/odoo/blob/86b748dc91f7260b30c6944fd906a4d68ec1849b/addons/hr_expense/models/hr_expense.py#L251-L261 Solution: Fetch the exchange rate directly during the process of the extracted data.
Original PR description
Steps to reproduce: - multi-currency - upload an expense with a differenct currency than the company - OCRize it Issue: The exchange rate is always 1:1 Cause: We don't fetch the echange rate with OCR and the compute's cannot fetch it since we cill never satisfy the condition https://github.com/odoo/odoo/blob/86b748dc91f7260b30c6944fd906a4d68ec1849b/addons/hr_expense/models/hr_expense.py#L251-L261 Solution: Fetch the exchange rate directly during the process of the extracted data. I differed the write operation at the end to avoid unwanted computed that could overwrite what we need. opw-4151571 Forward-Port-Of: odoo/enterprise#72112
When generating either a PO or SO from one company to another, currently the commitment date of a Sale Order or the Expected Arrival of a Purchase Order are not used to generate their counter-part in the other company. This means that if you set the expected arrival of the PO in Company A to 10 days in the future, the SO generated in Company B will still try to deliver it as soon as possible, regardless of the date set. Forward-Port-Of: odoo/enterprise#72627 Forward-Port-Of: odoo/enterprise#
Original PR description
When generating either a PO or SO from one company to another, currently the commitment date of a Sale Order or the Expected Arrival of a Purchase Order are not used to generate their counter-part in the other company. This means that if you set the expected arrival of the PO in Company A to 10 days in the future, the SO generated in Company B will still try to deliver it as soon as possible, regardless of the date set. Forward-Port-Of: odoo/enterprise#72627 Forward-Port-Of: odoo/enterprise#72586
Currently, Odoo supports several currencies (USD, EUR, JPY, GBP) for Banxico data parsing, but CNY (Chinese Yuan) is missing. This commit adds support for CNY in the list of currencies retrieved from Banxico’s API (through iap proxy). related pr: https://github.com/odoo/iap-apps/pull/912 task-4205613 Forward-Port-Of: odoo/enterprise#72202
Original PR description
Currently, Odoo supports several currencies (USD, EUR, JPY, GBP) for Banxico data parsing, but CNY (Chinese Yuan) is missing. This commit adds support for CNY in the list of currencies retrieved from Banxico’s API (through iap proxy). related pr: https://github.com/odoo/iap-apps/pull/912 task-4205613 Forward-Port-Of: odoo/enterprise#72202
This is a complement of previous fix: https://github.com/odoo/enterprise/commit/9b2d9508745fb1b00e42c8d729d01ad7ae1b4b85 Add the company of the move in the context as it is possible that the company of the move and the current company are different. Related community PR: https://github.com/odoo/odoo/pull/185096 Forward-Port-Of: odoo/enterprise#71725
Original PR description
This is a complement of previous fix: https://github.com/odoo/enterprise/commit/9b2d9508745fb1b00e42c8d729d01ad7ae1b4b85 Add the company of the move in the context as it is possible that the company of the move and the current company are different. Related community PR: https://github.com/odoo/odoo/pull/185096 Forward-Port-Of: odoo/enterprise#71725
The field fetching status is used to check if we need to call the synchronization. In case there is an error during the synchronization, the user would be block with his connection. The solution is to reset the fetching status when fetching the transaction or use the new reset button on the list view of the online accounts. task:4262788 Forward-Port-Of: odoo/enterprise#72492
Original PR description
The field fetching status is used to check if we need to call the synchronization. In case there is an error during the synchronization, the user would be block with his connection. The solution is to reset the fetching status when fetching the transaction or use the new reset button on the list view of the online accounts. task:4262788 Forward-Port-Of: odoo/enterprise#72492
While adding the `TDS` taxes on payment for receipt from vendor and payment to customer, the type of tax i.e purchase or sale should be dependent on partner type i.e supplier or customer. For the vendor tds taxes should be of purchase type and for the customer it should be of sale type. task-4262953 Forward-Port-Of: odoo/odoo#184823
Original PR description
While adding the `TDS` taxes on payment for receipt from vendor and payment to customer, the type of tax i.e purchase or sale should be dependent on partner type i.e supplier or customer. For the vendor tds taxes should be of purchase type and for the customer it should be of sale type. task-4262953 Forward-Port-Of: odoo/odoo#184823
This is a complement of previous fix: https://github.com/odoo/odoo/commit/792773296fce27340bf866fef8a6f6e8969b682e Add the company of the move in the context as it is possible that the company of the move and the current company are different. opw-4227241 Related enterprise PR: https://github.com/odoo/enterprise/pull/71725 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185096
Original PR description
This is a complement of previous fix: https://github.com/odoo/odoo/commit/792773296fce27340bf866fef8a6f6e8969b682e Add the company of the move in the context as it is possible that the company of the move and the current company are different. opw-4227241 Related enterprise PR: https://github.com/odoo/enterprise/pull/71725 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185096
Just a few improvements in the French translation of the FEC module. Forward-Port-Of: odoo/odoo#183351
Original PR description
Just a few improvements in the French translation of the FEC module. Forward-Port-Of: odoo/odoo#183351
This reverts commit bcaf8cb859dc2f7e975d180ba0fc49da20204557 as we were forcing values and it did not reflect the settings of fiscal positions. opw-4270399 Forward-Port-Of: odoo/odoo#185164 Forward-Port-Of: odoo/odoo#185101
Original PR description
This reverts commit bcaf8cb859dc2f7e975d180ba0fc49da20204557 as we were forcing values and it did not reflect the settings of fiscal positions. opw-4270399 Forward-Port-Of: odoo/odoo#185164 Forward-Port-Of: odoo/odoo#185101
How to reproduce: - Create a product P, storable, uom=Units - Create Receipt for 12 units of P, Confirm - Change the operation line from 12 Units to 1 Dozen - Validate Receipt => Valuation layer for 12 Units created (OK) - Unlock Receipt - Change the operation line from 1 to 2 Dozens - Save Receipt => Valuation layer for 1 Unit created (Should be 12) OPW-4204420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#1847
Original PR description
How to reproduce: - Create a product P, storable, uom=Units - Create Receipt for 12 units of P, Confirm - Change the operation line from 12 Units to 1 Dozen - Validate Receipt => Valuation layer for 12 Units created (OK) - Unlock Receipt - Change the operation line from 1 to 2 Dozens - Save Receipt => Valuation layer for 1 Unit created (Should be 12) OPW-4204420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184773 Forward-Port-Of: odoo/odoo#182502
Using composer in the mass mail mode is allowed on non `mail.thread` models. This fix covers the case where one of the required methods isn't available on the model that we try to send mail on. Reproduce --- - install website_slides - "Add Context Action" on the "Elearning: Add Attendees to Course" template - open an eLearning course -> Attendees list view, select one, click on Send Mail action - fill required replyto -> send -> BUG: traceback opw-4062613 Forward-Port-Of: odoo/odoo
Original PR description
Using composer in the mass mail mode is allowed on non `mail.thread` models. This fix covers the case where one of the required methods isn't available on the model that we try to send mail on. Reproduce --- - install website_slides - "Add Context Action" on the "Elearning: Add Attendees to Course" template - open an eLearning course -> Attendees list view, select one, click on Send Mail action - fill required replyto -> send -> BUG: traceback opw-4062613 Forward-Port-Of: odoo/odoo#178999
The event is create with a date_begin and date_end calling datetime.now consecutively. This can lead to a situation where the date_end is before the date_begin in verry rare case (not monotonic). This commit fix this by calling datetime.now only once and using the same value for both date_begin and date_end. runbot error [56986](https://runbot.odoo.com/web#id=56986&cids=1&menu_id=424&action=573&model=runbot.build.error&view_type=form) Forward-Port-Of: odoo/odoo#185067 Forward-Port-Of: odoo/
Original PR description
The event is create with a date_begin and date_end calling datetime.now consecutively. This can lead to a situation where the date_end is before the date_begin in verry rare case (not monotonic). This commit fix this by calling datetime.now only once and using the same value for both date_begin and date_end. runbot error [56986](https://runbot.odoo.com/web#id=56986&cids=1&menu_id=424&action=573&model=runbot.build.error&view_type=form) Forward-Port-Of: odoo/odoo#185067 Forward-Port-Of: odoo/odoo#184990
The test_sync_recorder was breaking for strange reason because of extra elements in the stack A first attempt was made trying to remove last elements but in some case a `_remove` or `signal_handler` can appear in the middle. It looks to complex to adapt the test to work in all those cases. Moving it to a non standard test looks like the simplest solution for now. runbot error [73473](https://runbot.odoo.com/web#id=73473&cids=1&menu_id=424&action=573&model=runbot.build.error&view_type=form)
Original PR description
The test_sync_recorder was breaking for strange reason because of extra elements in the stack A first attempt was made trying to remove last elements but in some case a `_remove` or `signal_handler` can appear in the middle. It looks to complex to adapt the test to work in all those cases. Moving it to a non standard test looks like the simplest solution for now. runbot error [73473](https://runbot.odoo.com/web#id=73473&cids=1&menu_id=424&action=573&model=runbot.build.error&view_type=form) Forward-Port-Of: odoo/odoo#185065 Forward-Port-Of: odoo/odoo#185023
Steps to reproduce: ==== - Create a quotation and confirm it. - Open Point of Sale. - Load the order in POS. - Choose option Apply a down payment(percentage). - Insert 50. - Do payment and again place new order. - Select the same Quotation and do same 50% down payment. Issue: ==== - Next time value should be calculated from due balance not from initial total amount of the quotation. Fix: ==== - Instead of total_amount , now amount_unpaid is used. task- 4231244 Forward-Port-
Original PR description
Steps to reproduce: ==== - Create a quotation and confirm it. - Open Point of Sale. - Load the order in POS. - Choose option Apply a down payment(percentage). - Insert 50. - Do payment and again place new order. - Select the same Quotation and do same 50% down payment. Issue: ==== - Next time value should be calculated from due balance not from initial total amount of the quotation. Fix: ==== - Instead of total_amount , now amount_unpaid is used. task- 4231244 Forward-Port-Of: odoo/odoo#182542
When being order-based, several registrations are used to create a new lead. In some cases we might end up with several possible langs due to multiple visitors. We should take the first found one, as lang is a m2o on lead model. When running on registrations without linked SO, registrations are grouped by "event" in case of group-based lead generation. We should also group by create_date, as same event - same create_date indicates tickets belong to the same "group". Task-3940853 C
Original PR description
When being order-based, several registrations are used to create a new lead. In some cases we might end up with several possible langs due to multiple visitors. We should take the first found one, as lang is a m2o on lead model. When running on registrations without linked SO, registrations are grouped by "event" in case of group-based lead generation. We should also group by create_date, as same event - same create_date indicates tickets belong to the same "group". Task-3940853 Co-Authored-By: Jeremy Hennecart <jeh@odoo.com> Forward-Port-Of: odoo/odoo#182138
- Add new tax groups, fiscal positions and taxes for retentions of not residents. - Add configuration to send SII in new taxes. https://sede.agenciatributaria.gob.es/Sede/nuevasede.html @rafaelbn @arantxasudon @moduon MT-5974 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183901 Forward-Port-Of: odoo/odoo#166499
Original PR description
- Add new tax groups, fiscal positions and taxes for retentions of not residents. - Add configuration to send SII in new taxes. https://sede.agenciatributaria.gob.es/Sede/nuevasede.html @rafaelbn @arantxasudon @moduon MT-5974 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183901 Forward-Port-Of: odoo/odoo#166499
Remove Dependency on hr_contract model as it does exist in the dependent apps for base_automation which would allow tests to fail if the module was not installed. To solve this, the test was compared against a base field instead. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184335 Forward-Port-Of: odoo/odoo#183573
Original PR description
Remove Dependency on hr_contract model as it does exist in the dependent apps for base_automation which would allow tests to fail if the module was not installed. To solve this, the test was compared against a base field instead. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184335 Forward-Port-Of: odoo/odoo#183573
Steps to reproduce: - install project module. - open form view of any task - create new task and set value of deadline - deadline is getting text-decoration even if deadline is not passed. Sol: - Condition ensures date_deadline is not None and strictly less than current_date - This change improves the robustness of the condition by handling undefined date_deadline values. task: 3970136 Forward-Port-Of: odoo/odoo#173850
Original PR description
Steps to reproduce: - install project module. - open form view of any task - create new task and set value of deadline - deadline is getting text-decoration even if deadline is not passed. Sol: - Condition ensures date_deadline is not None and strictly less than current_date - This change improves the robustness of the condition by handling undefined date_deadline values. task: 3970136 Forward-Port-Of: odoo/odoo#173850
Steps to reproduce: - Create a Sale Order for a storable product and confirm it - Create another user with the following permissions: - Sales > User: Own Documents Only - Inventory > User - With that user, create a new Sale Order for the same product and confirm it. - Click the forecast icon and open the report. Issue: An AccessError will be triggered, as that user doesn't have the rights to access the SO lines of the first SO since it wasn't created by them. While it's correct
Original PR description
Steps to reproduce: - Create a Sale Order for a storable product and confirm it - Create another user with the following permissions: - Sales > User: Own Documents Only - Inventory > User - With that user, create a new Sale Order for the same product and confirm it. - Click the forecast icon and open the report. Issue: An AccessError will be triggered, as that user doesn't have the rights to access the SO lines of the first SO since it wasn't created by them. While it's correct that this user shouldn't be able to access the sale order, we still want them to be able to access the forecast report and see their use, even though they can't click on them and see the SO content. Same thing should apply for draft SO, as they indicate potential future state of the stock as well. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184673 Forward-Port-Of: odoo/odoo#182914
As Debian wants to remove pypdf2 and keep only pypdf (4.3) in trixie, so we need to be compatible otherwise Odoo could not be released in the next Debian. Forward-Port-Of: odoo/odoo#183165
Original PR description
As Debian wants to remove pypdf2 and keep only pypdf (4.3) in trixie, so we need to be compatible otherwise Odoo could not be released in the next Debian. Forward-Port-Of: odoo/odoo#183165
In line with the approach outlined in [1], where element accessibility was improved by providing explicit names for easier selection and inheritance, this commit applies the same logic to the account portal invoices. By adding column header names, we ensure that these elements can be safely referenced without relying on positional selectors, thus avoiding potential issues when the element structure changes. [1] https://github.com/odoo/enterprise/pull/63957 --- I confirm I have signed the
Original PR description
In line with the approach outlined in [1], where element accessibility was improved by providing explicit names for easier selection and inheritance, this commit applies the same logic to the account portal invoices. By adding column header names, we ensure that these elements can be safely referenced without relying on positional selectors, thus avoiding potential issues when the element structure changes. [1] https://github.com/odoo/enterprise/pull/63957 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180259
## Issue: - when making a payment using 2 different payment methods (cash and bank), the change gets deducted from the bank payment not the cash payment in the invoice. ## Steps To Reproduce: On POS, for an order totaling $120. - Add a customer and ensure the "Invoice" box is checked. - pay using two payments methods bank 100$ Cash 50$ - the change is $30, everything looks fine on the ticket on the pos. - Notice on the invoice on the db backend the $30 change is in
Original PR description
## Issue: - when making a payment using 2 different payment methods (cash and bank), the change gets deducted from the bank payment not the cash payment in the invoice. ## Steps To Reproduce: On POS,…
## Issue:
- when making a payment using 2 different payment methods (cash and bank), the change gets deducted from the bank payment not the cash payment in the invoice.
## Steps To Reproduce:
On POS, for an order totaling $120.
- Add a customer and ensure the "Invoice" box is checked.
- pay using two payments methods
bank 100$
Cash 50$
- the change is $30, everything looks fine on the ticket on the pos.
- Notice on the invoice on the db backend the $30 change is incorrectly deducted from the bank payment. As a result, the invoice displays:
bank : $70
cash: $50
## Soltution:
- In the _create_payment_moves method, I ensured that an `account.move` is not created for the change amount. Instead, the change is deducted from the first cash payment before creating the relevant `account.move`.
opw-4076246
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#183616
Forward-Port-Of: odoo/odoo#176342Steps to reproduce: - Drop the "Team" snippet and toggle it to grid mode. - Change the grid items padding with the "Padding (Y, X)" option. => The `o_we_padding_highlight` class used to show the padding preview is also added on the inner row of the grid items. This happens because the `data-apply-to` attribute of this option targets the `.row` elements in general, instead of only the grid mode one (so having the `o_grid_mode` class). This commit fixes this issue by changing this attribut
Original PR description
Steps to reproduce: - Drop the "Team" snippet and toggle it to grid mode. - Change the grid items padding with the "Padding (Y, X)" option. => The `o_we_padding_highlight` class used to show the padding preview is also added on the inner row of the grid items. This happens because the `data-apply-to` attribute of this option targets the `.row` elements in general, instead of only the grid mode one (so having the `o_grid_mode` class). This commit fixes this issue by changing this attribute, by patching the template in JS as a stable fix. Note that in above versions, the padding option changed so this fix will not be needed (but other grid options will need a similar fix). task-4247543 Forward-Port-Of: odoo/odoo#184354 Forward-Port-Of: odoo/odoo#183219
How to reproduce: 1. install l10n_pe_edi_pos 2. run `test_pos_js` The following traceback is obtained: ``` QUnit test failed: point_of_sale > Chrome > mount the Chrome : message: "Promise rejected during "mount the Chrome": Cannot make the given value reactive" ``` It is actually raised because in l10n_pe_edi_pos, we try to access `company.account_fiscal_country_id.code` and the fiscal_country is undefined (`Cannot read properties of undefined (reading 'code')`). Adding demo data
Original PR description
How to reproduce: 1. install l10n_pe_edi_pos 2. run `test_pos_js` The following traceback is obtained: ``` QUnit test failed: point_of_sale > Chrome > mount the Chrome : message: "Promise rejected during "mount the Chrome": Cannot make the given value reactive" ``` It is actually raised because in l10n_pe_edi_pos, we try to access `company.account_fiscal_country_id.code` and the fiscal_country is undefined (`Cannot read properties of undefined (reading 'code')`). Adding demo data fixes the error. runbot-71686 Forward-Port-Of: odoo/odoo#184749
The issue: When trying to update the stage field of multiple maintenance request there was an error. How to reproduce the issue: -Navigate to the Maintenance app -Click the Maintenance menu item and select Maintenance Requests from the drop-down menu -Click the List view -Select more than one request -Click the Stage field on the list view and select a different stage -Confirm the stage move -> Traceback Explanation: In the write method of the maintenance.request model, the fields mai
Original PR description
The issue: When trying to update the stage field of multiple maintenance request there was an error. How to reproduce the issue: -Navigate to the Maintenance app -Click the Maintenance menu item and select Maintenance Requests from the drop-down menu -Click the List view -Select more than one request -Click the Stage field on the list view and select a different stage -Confirm the stage move -> Traceback Explanation: In the write method of the maintenance.request model, the fields maintenance_type and recurring_maintenance were directly accessed on a recordset instead of a single record. This caused an error in the __get__ method of field.py because it expects a single record. opw-4213560 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183154
Currently when settling a customer account, we try to create a simplified invoice which is nt possible since we do not have products in the order. Users using the Spanish localization cannot settle customer accounts. Steps to reproduce: ------------------- * Install **l10n_es_pos** and switch to the ES Company * Open shop session * Add products to the order, select any customer, pay with customer account * Select **New order** * Select the previous customer and select **Settle due accou
Original PR description
Currently when settling a customer account, we try to create a simplified invoice which is nt possible since we do not have products in the order. Users using the Spanish localization cannot settle…
Currently when settling a customer account, we try to create a simplified invoice which is nt possible since we do not have products in the order. Users using the Spanish localization cannot settle customer accounts. Steps to reproduce: ------------------- * Install **l10n_es_pos** and switch to the ES Company * Open shop session * Add products to the order, select any customer, pay with customer account * Select **New order** * Select the previous customer and select **Settle due accounts** * Select any payment method * Validate order -> Yes > Observation: Cannot invoice empty order Why the fix: ------------ Spain requires to invoice all orders. In Pos, everything is considered as an order but settling customer accounts does not fall under the definition of an order outside of Odoo (no transfer of product, amount=0). Therefore when we settle customer account we skip the automatic invoicing and fallback on the pos bahavior without the localization. opw-4185144 Enterprise PR: https://github.com/odoo/enterprise/pull/71958 Forward-Port-Of: odoo/odoo#183682
Steps ----- - install sale_timesheet - create a "30 hours" Unit of Measure in the Working Time category, equal to 3.75 days - create a service product with "30 hours" as the UoM - create a SO with this product for a customer - create a task for this customer and use the previously created SOL - add 15 hours of timesheet Issue ----- The remaining hours on the SO appear as +/- 26:00 (with some minor decimal precision inaccuracies), but the name of the SOL in the "Sales Order Item" f
Original PR description
Steps ----- - install sale_timesheet - create a "30 hours" Unit of Measure in the Working Time category, equal to 3.75 days - create a service product with "30 hours" as the UoM - create a SO with this product for a customer - create a task for this customer and use the previously created SOL - add 15 hours of timesheet Issue ----- The remaining hours on the SO appear as +/- 26:00 (with some minor decimal precision inaccuracies), but the name of the SOL in the "Sales Order Item" field shows 26:30 remaining. Change ----- Backport https://github.com/odoo/odoo/commit/d0cf7c0f2c039d55d024cf9a2e0676e11ba97338 which removes the rounding by 30 minutes and uses `format_duration` opw-3959886 Forward-Port-Of: odoo/odoo#185142 Forward-Port-Of: odoo/odoo#181008
Steps to reproduce: - Install `snailmail_account` and `contacts` - Add a company as a contact, this company should be a german one add address and street 2 - Create an invoice for that contact - Confirm invoice - Send invoice using post only - With debug mode go to snailmail letters - Click on send - Check pdf document Issue: The format is not respected, for german letter we should have a '//' preceeding the supplementary notes, as such pingen flag the document as invalid. http
Original PR description
Steps to reproduce: - Install `snailmail_account` and `contacts` - Add a company as a contact, this company should be a german one add address and street 2 - Create an invoice for that contact - Confirm invoice - Send invoice using post only - With debug mode go to snailmail letters - Click on send - Check pdf document Issue: The format is not respected, for german letter we should have a '//' preceeding the supplementary notes, as such pingen flag the document as invalid. https://help.pingen.com/en/faq-post/adressanforderungen-deutsche-post opw-4160129 Forward-Port-Of: odoo/odoo#182292
* Module maintenance worksheet is from enterprise, we should add widget upgrade_boolean for it to avoid misunderstanding from customer Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185020
Original PR description
* Module maintenance worksheet is from enterprise, we should add widget upgrade_boolean for it to avoid misunderstanding from customer Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185020
Description of the issue/feature this PR addresses: Do not try install auto installable modules that are not installable Current behavior before PR: If you have an auto_installable module (auto_install = True) that is not installable (installable = False) odoo is trying to install it and displaying warnings on the log Desired behavior after PR is merged: Avoid trying to install modules that are auto_install = True and installable = False --- I confirm I have signed the CLA and
Original PR description
Description of the issue/feature this PR addresses: Do not try install auto installable modules that are not installable Current behavior before PR: If you have an auto_installable module (auto_install = True) that is not installable (installable = False) odoo is trying to install it and displaying warnings on the log Desired behavior after PR is merged: Avoid trying to install modules that are auto_install = True and installable = False --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#141938
Since [1] the `user_id` represents the buyer, the string in the field was updated but not in the filter and the search which could be confusing. [1]: https://github.com/odoo/odoo/commit/470b7562 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179834
Original PR description
Since [1] the `user_id` represents the buyer, the string in the field was updated but not in the filter and the search which could be confusing. [1]: https://github.com/odoo/odoo/commit/470b7562 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179834
We revert Commit fe4208c1ed7f9f59736d36930ba77541c19ffaeb as it allows to perform button actions on records with invalid datas. Notably because of unset required fields. ### Steps to reproduce: - In the settings enable sbcontracting - Create 2 storable products tracked by SN: Final Product (FP) and COMP - Create a subcontracting BOM for FP with COMP as component - On COMP set the route Resupply Subcontractor on Order - Register 3 SN of COMP in stock: SN01, SN02, SN03 - Create and conf
Original PR description
We revert Commit fe4208c1ed7f9f59736d36930ba77541c19ffaeb as it allows to perform button actions on records with invalid datas. Notably because of unset required fields. ### Steps to reproduce: - In…
We revert Commit fe4208c1ed7f9f59736d36930ba77541c19ffaeb as it allows to perform button actions on records with invalid datas. Notably because of unset required fields. ### Steps to reproduce: - In the settings enable sbcontracting - Create 2 storable products tracked by SN: Final Product (FP) and COMP - Create a subcontracting BOM for FP with COMP as component - On COMP set the route Resupply Subcontractor on Order - Register 3 SN of COMP in stock: SN01, SN02, SN03 - Create and confirm a PO for your subcontractor for 3 units of FP - Validate the Resupply picking - Go to the reciept and click "Record components" - Record your first Final product SN: FP01 (required) - Continue - Dont register any SN on the second and third recording #### > Since you will not be able to edit this required field later on, the registration of such a SN should be required on FP. #### > This leads to a softlock as the field is readonly afterwards. ### Cause of the Issue: Since Commit fe4208c1ed7f9f59736d36930ba77541c19ffaeb, the `_checkValidity` of the `_save` call do not happen if we are not at record creation or if no change has been applied on the record. However, in our case, we are not at creation of the record and we did not perfom any change on the record form so that the `_save` call will return `true` rather than the `false` he would return if he performed a `_checkValidity` of the record. This is a drastic difference since the returned value of this `_save` is used by the `formController` when you click a button in order to determine if he should proceed with the action or cancel the call: https://github.com/odoo/odoo/blob/9b5eed7e215b2601c25b9d81c42dfa1bc1d06fee/addons/web/static/src/views/form/form_controller.js#L497-L510 https://github.com/odoo/odoo/blob/9b5eed7e215b2601c25b9d81c42dfa1bc1d06fee/addons/web/static/src/views/view_button/view_button_hook.js#L49-L60 In particular, in our case, the action will be called even thought the "required onchange" (and associated "websave") was never called. What I mean by "required onchange" is that the "lot_producing_id" is a required field of our form: https://github.com/odoo/odoo/blob/4d5d270e72fdec49ffc31269642683b68984adca/addons/mrp_subcontracting/views/mrp_production_views.xml#L24-L27 Hence it needs to be set and provoke an onchange that will it self provoke a `web_save` of the new record value in the `_save` before it proceeds with the button action. ### Additional note on Commit fe4208c1ed7f9f59736d36930ba77541c19ffaeb: This commit was initially added to avoid displaying Invalid Field notifications when you open a record with invalid data as a `_save` is also called in the `openRecord` of the `ListController` for instance. To me even in that case, it is usefull even if unnecessary to know that some record data's are currently invalid. opw-4267852 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185134
The issue: When setting an automation rule to trigger 'On Save' onto a model with a settable non-stored compute field it will sometimes cause an error. For example, the boolean_favortie widget on project.project, clicking the widget while there is an automation rule set to trigger "on save" will not properly update the view. This is because the initial write call to `is_favorite` triggers its inverse function, which also attempts to write to project.project.favorite_user_ids which retriggers th
Original PR description
The issue: When setting an automation rule to trigger 'On Save' onto a model with a settable non-stored compute field it will sometimes cause an error. For example, the boolean_favortie widget on…
The issue: When setting an automation rule to trigger 'On Save' onto a model with a settable non-stored compute field it will sometimes cause an error. For example, the boolean_favortie widget on project.project, clicking the widget while there is an automation rule set to trigger "on save" will not properly update the view. This is because the initial write call to `is_favorite` triggers its inverse function, which also attempts to write to project.project.favorite_user_ids which retriggers the automation rule again. During this retrigger, the `old_values` are populated which attempts to fetch the field values from project.project, causing is_favorite to be recomputed BEFORE the inverse function finishes writing the inverse data, causing this inconsistency. The Fix: Filter out non-stored values when memoizing old_values. This will avoid the issue entirely. It also does not make sense for non-stored field values to be "stored" in this way when they could be dynamically recomputed from the stored field values that will still be passed into the context. OPW: 4106799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180965
Once the ewaybill is generated, cancelled and resetted to pending the name is not resetted After this commit: we reset ewaybill name once it's been reset to pending task-4285220 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185066
Original PR description
Once the ewaybill is generated, cancelled and resetted to pending the name is not resetted After this commit: we reset ewaybill name once it's been reset to pending task-4285220 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185066