Daily updates from Odoo
Friday, October 25, 2024
107 changes
30 changes
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
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
14 changes
Enhancements to existing features
The Planning app now includes clearer demo examples showing how employee shifts and allocated hours vary across different contract periods. This helps business users better understand and evaluate contract-based planning scenarios during demonstrations or testing.
Original PR description
- master Before this commit, there was not quite much demo data to showcase about shifts and its allocated hours depending on various contracts of employees. This commit adds demo data to show shifts allocated to resource depending on their different contract period. task-3128491
Resolved issues and error corrections
This update aligns Odoo spreadsheet side panels with recent spreadsheet engine changes, improving consistency in menus, titles, fonts, and chart controls. It also adds test coverage for pivot autocomplete behavior to help prevent regressions in spreadsheet reporting features.
Miscellaneous changes
Fixed onboarding Social Marketing tour which is not working properly. Reason ====== We're not getting this `'textarea[name="message"]` for some reasons, & there is no `name` attribute in textarea. Also, we removed `extra_tringger` in later version, and we can use `run: 'edit` instead so removed that & used common classes that works on all version. Task-4210376 Forward-Port-Of: odoo/enterprise#72754 Forward-Port-Of: odoo/enterprise#71016
Original PR description
Fixed onboarding Social Marketing tour which is not working properly. Reason ====== We're not getting this `'textarea[name="message"]` for some reasons, & there is no `name` attribute in textarea. Also, we removed `extra_tringger` in later version, and we can use `run: 'edit` instead so removed that & used common classes that works on all version. Task-4210376 Forward-Port-Of: odoo/enterprise#72754 Forward-Port-Of: odoo/enterprise#71016
In this commit, we close active modals when the focussed element of a step (trigger) is below the modal. https://github.com/odoo/odoo/pull/185231 Forward-Port-Of: odoo/enterprise#72756
Original PR description
In this commit, we close active modals when the focussed element of a step (trigger) is below the modal. https://github.com/odoo/odoo/pull/185231 Forward-Port-Of: odoo/enterprise#72756
### Steps to reproduce the issue: 1. In a Multi-Company setup with different Charts of Accounts, create (or find) a Report with Availability set to Chart of Account Matches - For example, you can use Belgian Profit and Loss or Balance Sheet reports 2. With multiple companies visible, including the one with the correct Chart of Accounts, go to the Root Report of the one you created (or found) 3. Under the Report Variants filter, the "coa" Report can not be found, or the filter is simply
Original PR description
### Steps to reproduce the issue: 1. In a Multi-Company setup with different Charts of Accounts, create (or find) a Report with Availability set to Chart of Account Matches - For example, you can use…
### Steps to reproduce the issue:
1. In a Multi-Company setup with different Charts of Accounts, create (or find) a Report with Availability set to Chart of Account Matches
- For example, you can use Belgian Profit and Loss or Balance Sheet reports
2. With multiple companies visible, including the one with the correct Chart of Accounts, go to the Root Report of the one you created (or found)
3. Under the Report Variants filter, the "coa" Report can not be found, or the filter is simply not displayed
### Explanation:
When looking for variants with `availability_condition="coa"`, the current condition is for `companies.mapped("chart_template")` to consist of only `account.report.chart_template`.
Before 18.0, `account.report` using `account.account.code` as filter retrieved accounts from all active companies. `account.account` with a `code` corresponding to the request, even if their function is not the same, would be added into the report, falsing the amounts as a result.
### Fix reasoning:
Since 18.0, with commits odoo/odoo@854c3b27aa5476c208572f19e64f8f3364bfc381 and odoo/enterprise@92bf8e36c40f99c697318ddc9784cde0a1b3736e, `account.account.code` became company dependent, and only `self.env.company` is used to retrieve them in `account.report`.
Thanks to this change, `availability_condition="coa"` does no longer require a restriction to environments where all companies have `account.report.chart_template`.
opw-4263627
Forward-Port-Of: odoo/enterprise#72365When deleting the measure on which the pivot is sorted, the side panel would crash. This commit fixes this issue by removing the sortedColumn from the pivot when the measure is deleted. Task: [4154831](https://www.odoo.com/web#id=4154831&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#72684 Forward-Port-Of: odoo/enterprise#69926
Original PR description
When deleting the measure on which the pivot is sorted, the side panel would crash. This commit fixes this issue by removing the sortedColumn from the pivot when the measure is deleted. Task: [4154831](https://www.odoo.com/web#id=4154831&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#72684 Forward-Port-Of: odoo/enterprise#69926
### 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
Before this commit, in single app mode (only studio is installed), a tour failed because we added approvals on a button on the Form View of Apps without specifying which. At the end of the day, a module got actually installed which triggered a lot of crashes, including the tour itself and a few low-level cursor-related functions. After this commit, we precisely specify in the tour on which button and function we make approvals for. The tour succeeds and there is no crash. Forward-Port-Of: od
Original PR description
Before this commit, in single app mode (only studio is installed), a tour failed because we added approvals on a button on the Form View of Apps without specifying which. At the end of the day, a module got actually installed which triggered a lot of crashes, including the tour itself and a few low-level cursor-related functions. After this commit, we precisely specify in the tour on which button and function we make approvals for. The tour succeeds and there is no crash. Forward-Port-Of: odoo/enterprise#72702
Steps to reproduce the issue: 1. Install the MRP module 2. Go to Production Analysis 3. Click on the pivot table 4. Select the `Expected component cost / unit` field 5. The miscalculation will be show for `expected_component_cost_unit`. It is dividing by the MO quantity produced rather than the BOM quantity. Explanation: The issue lies in the SQL query, where the expected cost is divided by `prod_qty.product_quantity`, meaning we are using the quantity produced by a MO. instead,
Original PR description
Steps to reproduce the issue: 1. Install the MRP module 2. Go to Production Analysis 3. Click on the pivot table 4. Select the `Expected component cost / unit` field 5. The miscalculation will be show for `expected_component_cost_unit`. It is dividing by the MO quantity produced rather than the BOM quantity. Explanation: The issue lies in the SQL query, where the expected cost is divided by `prod_qty.product_quantity`, meaning we are using the quantity produced by a MO. instead, it should be divided by the BOM quantity. Fix reasoning: With this commit, the issue is resolved by dividing the expected cost by the BOM `product_qty`. Forward-Port-Of: odoo/enterprise#72647 Forward-Port-Of: odoo/enterprise#69905
Column L and M were static (hardcoded dates) Task: 4268760 Forward-Port-Of: odoo/enterprise#72445
Original PR description
Column L and M were static (hardcoded dates) Task: 4268760 Forward-Port-Of: odoo/enterprise#72445
Forward-Port-Of: odoo/enterprise#72577
Original PR description
Forward-Port-Of: odoo/enterprise#72577
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
Steps to reproduce: - Sign app > Upload a PDF & Sign - Add a Date field > Sign Now > Sign Now - Click the date field The value 'undefined' fills the field instead of today's date. This was caused by an oversight when resolving a conflict in https://github.com/odoo/enterprise/pull/71864, the query selector should have grabbed the date from the HTML document but didn't. opw-4278391 Forward-Port-Of: odoo/enterprise#72574
Original PR description
Steps to reproduce: - Sign app > Upload a PDF & Sign - Add a Date field > Sign Now > Sign Now - Click the date field The value 'undefined' fills the field instead of today's date. This was caused by an oversight when resolving a conflict in https://github.com/odoo/enterprise/pull/71864, the query selector should have grabbed the date from the HTML document but didn't. opw-4278391 Forward-Port-Of: odoo/enterprise#72574
Steps to reproduce: - install Documents and CRM - login as Marc Demo - go to any pivot view - click on "Insert in spreadsheet" - select the Dashboards tab and confirm => boom Task: 4273554 Forward-Port-Of: odoo/enterprise#72711 Forward-Port-Of: odoo/enterprise#72395
Original PR description
Steps to reproduce: - install Documents and CRM - login as Marc Demo - go to any pivot view - click on "Insert in spreadsheet" - select the Dashboards tab and confirm => boom Task: 4273554 Forward-Port-Of: odoo/enterprise#72711 Forward-Port-Of: odoo/enterprise#72395
56 changes
Enhancements to existing features
The Knowledge editor no longer uses an extra internal command for each individual collaborative editing step. This simplifies processing for embedded content and should reduce unnecessary background work without changing the user experience.
Original PR description
This command's purpose was to dispatch the event at each individual external step, but it was only used for embedded components, and `onExternalHistorySteps` resource (which handles every batch of collaborative steps) is enough for embedded components, and it is called less often. This commit therefore removes `ADD_EXTERNAL_STEP` command. task-4281356
This update adds automated checks for the WhatsApp functionality in marketing automation. It helps reduce the risk of regressions and supports a more reliable experience for teams using WhatsApp campaigns.
Original PR description
The commit intends to add tests to newly introduced functionality of marketing automation where we added whatsapp.
Resolved issues and error corrections
This update restores outstanding accounts in the Ecuador chart of accounts that were available in earlier versions. It helps Ecuadorian companies keep expected payment and receipt flows correctly represented in their accounting setup.
Original PR description
Add the Outstanding Accounts we had in V17.4 and earlier versions --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents errors when users navigate to client actions that include a record in the URL breadcrumb. Invalid breadcrumb entries are now handled cleanly and removed, improving navigation reliability without changing user workflows.
Original PR description
In the case of a client action with a record id on the breadcrumb part of the url (`myClient/22` for instance). The controller should return the display name for the combination action + record id. And for the action alone (a multi-record if it was the case of a window action), the controller should return an error, to be removed from the breadcrumb. This is because client actions don't have multi-records views. Before this commit, the controller avoids returning anything, and an error raised. Now, the controller returns correctly an error, and it's correctly removed from the breadcrumb.
This fix moves shared VAT reference data into the Accounting module so Accounting can operate correctly even when the separate VAT validation module is not installed. It prevents setup issues for businesses that use Accounting without that optional module.
Original PR description
In #180744, we used the `_ref_vat` dictionary in the `account` module in order to provide a placeholder for the company and partner VAT. However, `_ref_vat` was defined only in `base_vat` which depends on `account`, not the other way around. As such, some users might want to use `account` without `base_vat`. We therefore move `_ref_vat` to `account` to allow this. task-none
Fixed a visual issue in Manufacturing where hovering over sample data in the Work Center Overview graph could show an unwanted black spot. This keeps the dashboard cleaner and avoids confusion when reviewing work center information.
Original PR description
In the Work Center Overview, when sample data is present on graph overview, a black spot appears on hover. This PR fixes the issue by preventing it.
This update fixes how text color is chosen inside website cards so it better matches the card background and surrounding page. It helps prevent hard-to-read or inconsistent text when cards inherit different background styles.
Original PR description
Bootstrap sets up background-color using `var(--card-bg)` but forces a color using `var(--body-color)`. It relies on `var(--card-color)` being used on the card-body... but there does not seem to be a…
Bootstrap sets up background-color using `var(--card-bg)` but forces a
color using `var(--body-color)`. It relies on `var(--card-color)` being
used on the card-body... but there does not seem to be a valid reason
to force the body one on the card above. Given the fact that card-color
is actually null by default, we end up with an inconsistent body-color
forced on the card whatever the value of `card-bg`. In the website case,
we often set up `card-bg` to inherit by default, which means the text
color would only work if the card was over the body background color.
By forcing card-color we enforce something consistent and controllable,
which by default will result as the card text color just following the
parent environment one (as `card-color` is null by default). We assume
that if `card-bg` is set, then `card-color` should be too.
Note: doing `color: var(--card-color)` would prevent overriding
--body-color in the card context (which is a bit weird) but it does not
work: it would override the color given by bg-xxx in the .card.bg-xxx
case, which is not what we want.Fixes an issue where undoing an icon size change removed the icon instead of restoring its previous size. This makes editing website content more predictable and reduces accidental content loss.
Original PR description
**Behaviour before PR:** Steps to reproduce: - Add an icon. - Change it's size from 1x to 2x or whatever. - Try to undo. Icon is removed at all instead of resizing to 1x. **Behaviour after PR:** Now undo works properly after changing icon's size. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes automated guided flows behave correctly when pop-up windows are present, ensuring steps target the active window or close it when needed. This improves reliability of website, point of sale, eLearning, and asset validation tests without changing day-to-day user features.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: https://github.com/odoo/enterprise/pull/72756 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a visual issue where status bar arrows could appear broken or separated from their labels on touchscreen devices. It improves the appearance and usability of status indicators in form views, such as CRM leads, without changing business workflows.
Original PR description
On touchscreen, the interactive elements' padding is extended to make them easier to target with fingers. This commit fixes a glitch in the StatusBarField's arrow where the said arrow doesn't touch the bottom of its element. Further more, it reworks the shape to avoid having a small (but visible) gap between the "arrow" part and the "label" one (in addition to weird background, appearing border occasional glitches). Steps to reproduce (on touchscreen): - Open CRM app - Open a lead (form view) => check the statusbar field arrow is "broken" at the bottom and a gap between the arrow and the label task-4212908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Sign app’s automated test was made more stable by ensuring it uses the correct signing template and by allowing more time for the test to complete. This reduces false test failures in the development pipeline without changing customer-facing features.
Original PR description
The shared_sign_request_tour, attempts to open some template and then click on some sign item. However it fails when it tries to click on the sign item, because it's not found. This happened because the tour sometimes open the wrong sign template (one with no items). This commit aims to fix the issue by archiving other sign templates when testing this flow. fixes runbot-98036
The Planning test data now gives Aaron's calendar a full-time hours value, so the expected workload indicator appears during automated checks. This helps keep the Planning schedule view reliable after changes to flexible working hours.
Original PR description
Before this commit, since the `full_time_required_hours` field is unset on the calendar of Aaron employee, the test `/planning:TestUi.test_01_ui` fails because no progressbar is displayed for that employee in the gantt view of `planning.slot` model, meaning the employee is not supposed to work. This commit sets `full_time_required_hours` on the calendar of `Aaron` employee to display the progressbar for that employee as it was expected before the rework of flexible hours for resources. runbot-99111
Non-timesheet analytic entries can now be edited without incorrectly triggering the timesheet-specific unit amount limit. This prevents unnecessary errors when business data uses larger values outside timesheets.
Original PR description
Before this commit, when the user alters the unit_amount field of an analytic account line which is not a timesheet and the amount has more than 6 digits then the user will get a user error saying he cannot encode a number with more than 6 digits for the unit amount field. This commit makes sure the check made on the unit amount is only made when the analytic line altered is a timesheet.
A Studio approval test was corrected so it targets the right button instead of accidentally triggering an app installation. This prevents crashes during automated checks and helps keep Studio validation reliable.
Original PR description
Before this commit, in single app mode (only studio is installed), a tour failed because we added approvals on a button on the Form View of Apps without specifying which. At the end of the day, a module got actually installed which triggered a lot of crashes, including the tour itself and a few low-level cursor-related functions. After this commit, we precisely specify in the tour on which button and function we make approvals for. The tour succeeds and there is no crash.
The quality measurement screen no longer shows a “Take measure” prompt when no scale or device is connected. This avoids confusing operators because they need to enter the measurement manually in that case.
Original PR description
When real time measure is not linked to a device (scale), no need to add the 'Take measure' label as the user must input a value
Automated product walkthroughs now close any open pop-up window when the next item to interact with is hidden behind it. This helps internal testing flows run more consistently for areas such as Helpdesk timesheets and point-of-sale account settlement.
Original PR description
In this commit, we close active modals when the focussed element of a step (trigger) is below the modal. https://github.com/odoo/odoo/pull/185231
Spreadsheet side panel headings now use a shared bold style, making the interface more visually consistent across filters, lists, pivots, and related panels. A related test was also added to help ensure pivot autocomplete behavior remains reliable.
Original PR description
The font weight of this side panel was previously inconsistent with other side panels. This commit introduces a constant for the side panel title font weight to ensure consistency and replaces Bootstrap classes with custom class o-fw-bold. Task: 4194259
Miscellaneous changes
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#185153 Forward-Port-Of: odoo/odoo#178999
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
- Some are out of date since the last batch export - Some were incorrectly manually modified - Also some cleanup of the `code` comments --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
- Some are out of date since the last batch export - Some were incorrectly manually modified - Also some cleanup of the `code` comments --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Item description node in UBL is merged to one line in the XML by replacing the new line with ', '. This commit improves on it by using single spacebar without the comma. opw-4213014 Forward-Port-Of: odoo/odoo#183935
Original PR description
Item description node in UBL is merged to one line in the XML by replacing the new line with ', '. This commit improves on it by using single spacebar without the comma. opw-4213014 Forward-Port-Of: odoo/odoo#183935
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#185125 Forward-Port-Of: odoo/odoo#182914
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
Correctly set the flag `install_demo` in demo data for some localisation, they were triggering some warnings otherwise. RunbotError: 103691 Forward-Port-Of: odoo/odoo#185226
Original PR description
Correctly set the flag `install_demo` in demo data for some localisation, they were triggering some warnings otherwise. RunbotError: 103691 Forward-Port-Of: odoo/odoo#185226
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#185212 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#185212 Forward-Port-Of: odoo/odoo#185101
Some payment request are failing when sent to viva wallet. Steps to reproduce: ------------------- * Configure viva wallet payment for shop session * Configure one product to have a price unit of 5.1 and na taxes * Open shop session * Add that product to order (only once) * Select **Payment** * Select viva wallet payment method that you configured * Select **Send** > Observation: Error. There are some issues betwees us and Viva Wallet, try again later. [{'type': 'int_from_float', 'lo
Original PR description
Some payment request are failing when sent to viva wallet.
Steps to reproduce:
-------------------
* Configure viva wallet payment for shop session
* Configure one product to have a price unit of 5.1 and na taxes
* Open shop session
* Add that product to order (only once)
* Select **Payment**
* Select viva wallet payment method that you configured
* Select **Send**
> Observation: Error. There are some issues betwees us and Viva Wallet, try again later. [{'type': 'int_from_float', 'loc': ['body', 'amount'], 'msg': 'Input should be a valid integer, got a number with fractional part', 'input': 510.00000000000006, 'url': '...'}]
Why the fix:
------------
Just a floating point precision issue. `3.1 * 100 = 310` but `5.1 * 100 = 510.00000000000006`, explaining why the issue does not always happen.
opw-4076168
Forward-Port-Of: odoo/odoo#184855
Forward-Port-Of: odoo/odoo#184048The 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
* 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
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
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: ------ During pdf generation, wkhtmltopdf creates device logs via a request. The user agent of this request is: ``` Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) wkhtmltopdf Safari/534.34. ``` The result is that a `Linux - Safari` device log is created. Solution: --------- This must be prevented using the `_disable_trace` server-side mechanism of the session object. However, we don't want to add this flag to the session currently used by the user in
Original PR description
Issue: ------ During pdf generation, wkhtmltopdf creates device logs via a request. The user agent of this request is: ``` Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) wkhtmltopdf Safari/534.34. ``` The result is that a `Linux - Safari` device log is created. Solution: --------- This must be prevented using the `_disable_trace` server-side mechanism of the session object. However, we don't want to add this flag to the session currently used by the user in order to continue generating logs even during report generation for activities performed in parallel. The possibility of creating a temporary session on the filesystem which is a copy of the current session with the `_trace_disable` flag is a good solution. Forward-Port-Of: odoo/odoo#180262
Before this commit, product variants not initially loaded but fetched during the processing of product attributes would remain visible, leading to duplicate product displays. opw-4246879 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184200
Original PR description
Before this commit, product variants not initially loaded but fetched during the processing of product attributes would remain visible, leading to duplicate product displays. opw-4246879 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184200
Description of the issue/feature this PR addresses: - Rremove redundant call to `addPendingOrder`. Current behavior before PR: - Currently, `addPendingOrder` is invoked once by the `point_of_sale` module, and immediately again by `pos_restaurant` [when](https://github.com/odoo/odoo/blob/875ea840b913fd31ef73df9e10e4426df6195bfc/addons/pos_restaurant/static/src/overrides/components/product_screen/product_screen.js#L16-L18) the ProductScreen component mounts. Desired behavior after PR i
Original PR description
Description of the issue/feature this PR addresses: - Rremove redundant call to `addPendingOrder`. Current behavior before PR: - Currently, `addPendingOrder` is invoked once by the `point_of_sale` module, and immediately again by `pos_restaurant` [when](https://github.com/odoo/odoo/blob/875ea840b913fd31ef73df9e10e4426df6195bfc/addons/pos_restaurant/static/src/overrides/components/product_screen/product_screen.js#L16-L18) the ProductScreen component mounts. Desired behavior after PR is merged: - Following the fix for #182495, the 'addPendingOrder' call in pos_restaurant becomes redundant and is no longer necessary. - As now we call the same function in root component. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184266
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
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
How to reproduce: 1. install l10n_pe_edi_pos 2. run `test_pos_js` The following traceback is obtained: ``` Error received after termination: QUnit test failed: point_of_sale > Chrome > test unsynch data error filtering : message: "Promise rejected during "test unsynch data error filtering": Cannot read properties of undefined (reading 'code')" ``` Adding demo data fixes the error. runbot-73446 Forward-Port-Of: odoo/odoo#184751
Original PR description
How to reproduce: 1. install l10n_pe_edi_pos 2. run `test_pos_js` The following traceback is obtained: ``` Error received after termination: QUnit test failed: point_of_sale > Chrome > test unsynch data error filtering : message: "Promise rejected during "test unsynch data error filtering": Cannot read properties of undefined (reading 'code')" ``` Adding demo data fixes the error. runbot-73446 Forward-Port-Of: odoo/odoo#184751
Fixed onboarding CRM tour which is not working properly. Task-4210376 Forward-Port-Of: odoo/odoo#181846
Original PR description
Fixed onboarding CRM tour which is not working properly. Task-4210376 Forward-Port-Of: odoo/odoo#181846
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
Discuss displays an unread counter for the user to keep track of unread messages. This counter is notably shown in the sidebar and in the unread messages banner. However, these counters sometimes have different values, which is inconsistent. Steps to reproduce: - Open two browsers (admin/demo). - Send enough messages from demo to admin to get a scrollbar. - Scroll to the top with admin, mark the first message as unread. - Focus the composer: only the banner remains. - Send another messag
Original PR description
Discuss displays an unread counter for the user to keep track of unread messages. This counter is notably shown in the sidebar and in the unread messages banner. However, these counters sometimes have different values, which is inconsistent. Steps to reproduce: - Open two browsers (admin/demo). - Send enough messages from demo to admin to get a scrollbar. - Scroll to the top with admin, mark the first message as unread. - Focus the composer: only the banner remains. - Send another message from demo. - The sidebar displays 1 unread message while the banner still shows the same value. To better indicate unread messages, the banner/indicator remains until the user returns to the thread. As a result, server and local values can sometimes become desynced. This PR ensures both counters account for this desync, adding the local counter to the server one when necessary. Forward-Port-Of: odoo/odoo#185044
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
- Some are out of date/module was added since the last batch export. - Some were incorrectly manually modified - Also some cleanup of the `code` comments
Original PR description
- Some are out of date/module was added since the last batch export. - Some were incorrectly manually modified - Also some cleanup of the `code` comments
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
The error occurs when we validate the quality worksheet template. Steps to reproduce: --- - Install the ``quality_mrp_workorder_worksheet`` module - Quality > Configuration > Quality Worksheet Templates - Click on ``Design Template`` - Click on ``Close`` - Click on ``Validate`` Traceback: --- ``ValueError: Expected singleton : quality.check()`` This error occurs at [1], where we are receiving ``self`` as empty. Previous behavior: --- When we try to design a template in the
Original PR description
The error occurs when we validate the quality worksheet template. Steps to reproduce: --- - Install the ``quality_mrp_workorder_worksheet`` module - Quality > Configuration > Quality Worksheet…
The error occurs when we validate the quality worksheet template. Steps to reproduce: --- - Install the ``quality_mrp_workorder_worksheet`` module - Quality > Configuration > Quality Worksheet Templates - Click on ``Design Template`` - Click on ``Close`` - Click on ``Validate`` Traceback: --- ``ValueError: Expected singleton : quality.check()`` This error occurs at [1], where we are receiving ``self`` as empty. Previous behavior: --- When we try to design a template in the ``Quality Worksheet Templates`` the studio opens as expected. However, if we close it without making any changes, we are redirected to the form view. In this view, we encounter strange behavior and are unable to perform any actions. After behavior: --- Now, when we click on ``Design Template`` from the list view and then close it, we are redirected to the form view of the ``Quality Worksheet Templates``. [1]- https://github.com/odoo/enterprise/blob/7eb1131b413afc2549382d2524ec83445803b682/quality_mrp_workorder_worksheet/models/quality.py#L12 sentry-5695518176 Forward-Port-Of: odoo/enterprise#68341
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 reverts commit a0a5dea9178d7db7ef35d8241ad13f8bac406044 as we're reverting e3acf5937cd7a65087a0178fadd666dead2b99db opw-4270399 Forward-Port-Of: odoo/enterprise#72749
Original PR description
This reverts commit a0a5dea9178d7db7ef35d8241ad13f8bac406044 as we're reverting e3acf5937cd7a65087a0178fadd666dead2b99db opw-4270399 Forward-Port-Of: odoo/enterprise#72749
**Version:** - 17.0 **Current Behaviour:** - Whenever tags were added to the document, the saved notification would appear, which looked odd. - Adding multiple tags caused the field size to increase, which was inappropriate. **Updated Behaviour:** - The saved notification will only appear when exiting the document. - A CSS class has been added to maintain a fixed size when adding multiple tags. task-4164151 Forward-Port-Of: odoo/enterprise#72664 Forward-Port-Of: odoo/enterpris
Original PR description
**Version:** - 17.0 **Current Behaviour:** - Whenever tags were added to the document, the saved notification would appear, which looked odd. - Adding multiple tags caused the field size to increase, which was inappropriate. **Updated Behaviour:** - The saved notification will only appear when exiting the document. - A CSS class has been added to maintain a fixed size when adding multiple tags. task-4164151 Forward-Port-Of: odoo/enterprise#72664 Forward-Port-Of: odoo/enterprise#70195
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
Due to a quirk in the JS framework, when a device form view is opened from the IoT box form view, it opens in a dialog box where it's `js_class` is not run. This causes updates to Display URL and Keyboard layout not to sync to the IoT box. This PR works around the issue by forcing the full device form view to open, rather than the dialog box. task-4141053 Forward-Port-Of: odoo/enterprise#72461 Forward-Port-Of: odoo/enterprise#72351
Original PR description
Due to a quirk in the JS framework, when a device form view is opened from the IoT box form view, it opens in a dialog box where it's `js_class` is not run. This causes updates to Display URL and Keyboard layout not to sync to the IoT box. This PR works around the issue by forcing the full device form view to open, rather than the dialog box. task-4141053 Forward-Port-Of: odoo/enterprise#72461 Forward-Port-Of: odoo/enterprise#72351
Fixed onboarding Social Marketing tour which is not working properly. Reason ====== We're not getting this `'textarea[name="message"]` for some reasons, & there is no `name` attribute in textarea. Also, we removed `extra_tringger` in later version, and we can use `run: 'edit` instead so removed that & used common classes that works on all version. Task-4210376 Forward-Port-Of: odoo/enterprise#72705 Forward-Port-Of: odoo/enterprise#71016
Original PR description
Fixed onboarding Social Marketing tour which is not working properly. Reason ====== We're not getting this `'textarea[name="message"]` for some reasons, & there is no `name` attribute in textarea. Also, we removed `extra_tringger` in later version, and we can use `run: 'edit` instead so removed that & used common classes that works on all version. Task-4210376 Forward-Port-Of: odoo/enterprise#72705 Forward-Port-Of: odoo/enterprise#71016
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
When deleting the measure on which the pivot is sorted, the side panel would crash. This commit fixes this issue by removing the sortedColumn from the pivot when the measure is deleted. Task: [4154831](https://www.odoo.com/web#id=4154831&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#69926
Original PR description
When deleting the measure on which the pivot is sorted, the side panel would crash. This commit fixes this issue by removing the sortedColumn from the pivot when the measure is deleted. Task: [4154831](https://www.odoo.com/web#id=4154831&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#69926
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
Steps to reproduce: - Sign app > Upload a PDF & Sign - Add a Date field > Sign Now > Sign Now - Click the date field The value 'undefined' fills the field instead of today's date. This was caused by an oversight when resolving a conflict in https://github.com/odoo/enterprise/pull/71864, the query selector should have grabbed the date from the HTML document but didn't. opw-4278391 Forward-Port-Of: odoo/enterprise#72574
Original PR description
Steps to reproduce: - Sign app > Upload a PDF & Sign - Add a Date field > Sign Now > Sign Now - Click the date field The value 'undefined' fills the field instead of today's date. This was caused by an oversight when resolving a conflict in https://github.com/odoo/enterprise/pull/71864, the query selector should have grabbed the date from the HTML document but didn't. opw-4278391 Forward-Port-Of: odoo/enterprise#72574
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