Navigate
Branch
Friday, October 25, 2024
129 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
70 changes
New functionality added to Odoo
Adds support for Epson fiscal printers in the Italian Point of Sale, helping businesses meet Italy's legal requirement to connect POS systems to government-compliant fiscal printers. The update enables fiscal receipts, invoices, required reports, reprints, refunds, and discounts, while aligning POS tax calculations with printer results.
Original PR description
### Purpose
Since July 2019, it's mandatory in Italy to have your POS connected to a "fiscal printer", meaning a printer connected to the government. so the goal is to make POS compliant with Italian fiscal law integrating it specifically with the Epson Italian Fiscal Printers.
### Updates Introduced:
- Support the Epson printer following operations:
- print Fiscal Receipt
- print Fiscal Invoice
- print X Report
- print Z Report
- print XZ Report
- re-print Receipt
- refunds
- discounts
- Adapt the POS tax calculations to be consistent with printer calculations
task-2092597
Community PR: odoo/odoo#180458Enhancements to existing features
The chatter composer now presents sending guidance and action buttons in a cleaner, more compact layout. This makes writing, sending, and editing messages easier to understand and keeps common actions more visible for users.
Original PR description
- Reword "Ctrl-Enter to send" to "or press Ctrl + Enter" - Show emoji action inline with 1st line of composer textarea - Other actions have been moved in same row as "Send message"/ "Log note", at the very end. Similar change has been made to editing message. Part of task-4260440 https://github.com/odoo/enterprise/pull/72074 <img width="795" alt="Screenshot 2024-10-18 at 12 48 11" src="https://github.com/user-attachments/assets/38d74a0b-3671-49dd-b7c0-cdc5d38b719f"> <img width="354" alt="Screenshot 2024-10-18 at 12 48 42" src="https://github.com/user-attachments/assets/acde081f-805f-4c18-8cc4-a838f4c2646e">
Invoice forms now open much faster on large databases when Indian withholding is installed. The change improves lookup performance for related withholding entries, reducing delays for users working with invoices.
Original PR description
## Description Opening of the form view for invoices is slow on large databases. It's due to the presence of the `l10n_in_withhold_move_ids` in the form view. It's inverse `l10n_in_withholding_ref_move_id` isn't indexed, defaulting to a Seq.Scan on `account.move`. ## Benchmark On next.odoo.com, opening an invoice form view | web_read > read | Before | After | |-----------------|--------|--------| | Timings | 3.35s | 0.02ms | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Stock deliveries to customers and production now default to being made to order rather than using the previous mixed stock-or-order behavior. This makes replenishment behavior clearer and updates related labels and messages so users better understand how quantities and procurement groups are handled.
Original PR description
This PR introduces a couple of modifications regarding procurement methods, namely - Stock to Customer/Production rules are now using make to order procurement method instead of `mts_else_mto` - `mts_else_mto` message has been modified to better reflect its behavior now task-4150122 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Italian point of sale setups can now connect with Epson fiscal printers to meet local legal requirements. The update supports fiscal receipts, invoices, daily reports, reprints, refunds, and discounts, while aligning tax calculations with printer output.
Original PR description
### Purpose
Since July 2019, it's mandatory in Italy to have your POS connected to a "fiscal printer", meaning a printer connected to the government. so the goal is to make POS compliant with Italian fiscal law integrating it specifically with the Epson Italian Fiscal Printers.
### Updates Introduced:
- Support the Epson printer following operations:
- print Fiscal Receipt
- print Fiscal Invoice
- print X Report
- print Z Report
- print XZ Report
- re-print Receipt
- refunds
- discounts
- Adapt the POS tax calculations to be consistent with printer calculations
task-2092597
Enterprise PR: odoo/enterprise#70164The messaging composer styling has been refined to provide a cleaner and more consistent experience in WhatsApp-related chatter interactions. This helps users write and review messages more comfortably without changing the underlying workflow.
Original PR description
https://github.com/odoo/odoo/pull/183823
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.The web interface now safely removes outdated breadcrumb entries when the server no longer returns data for them. This prevents users from seeing an error after refreshing certain pages, such as subcontracting views opened from a Bill of Materials overview.
Original PR description
When a breadcrumb contains a client action without a multi-record view, load_breadcrumbs skips this action, returning nothing for that key. However, on the frontend, we are not removing these…
When a breadcrumb contains a client action without a multi-record view, load_breadcrumbs skips this action, returning nothing for that key. However, on the frontend, we are not removing these controllers and attempt to access display_name each time the user reloads the page. This PR resolves this issue. If the backend result is undefined for a key stored in a breadcrumb cache, we remove it. Steps to test: We can open any sub-view from the BoM overview, as it is an action without a multi-record view. 1. Activate the Subcontracting feature in the settings tab. 2. Go to the Manufacturing app. 3. Click on the Product tab. 4. Select the Bills of Materials 5. Select Office Lamp BoM, for example 6. Click on BoM Overview 7. Click on Subcontracting 8. Refresh the page An error should appear, indicating an attempt to access display_name on an undefined object. Related Commit: https://github.com/odoo/odoo/commit/5047d1b3f4b2bd8061a15457350a0250bf93145f https://github.com/user-attachments/assets/57633318-cc24-4e0d-acb2-0f27f7ccd847 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error when checking OCR processing status for accounting documents that have no tax group data. It helps users avoid unexpected crashes while invoices or documents are being processed by OCR.
Original PR description
The error occurs at [1] because we are attempting to fetch the first record of ``tax_groups`` from ``subtotal``, but ``tax_groups`` is empty. As a result, there is no valid index for…
The error occurs at [1] because we are attempting to fetch the first record of ``tax_groups`` from ``subtotal``, but ``tax_groups`` is empty. As a result, there is no valid index for ``subtotal['tax_groups']``, leading to an index error.
Traceback:
---
```
IndexError: list index out of range
File "odoo/http.py", line 2365, in __call__
response = request._serve_db()
File "odoo/http.py", line 1892, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1955, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1922, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2169, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 329, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 728, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 517, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "home/odoo/src/enterprise/18.0/iap_extract/models/extract_mixin.py", line 214, in check_ocr_status
record._check_ocr_status()
File "home/odoo/src/enterprise/18.0/iap_extract/models/extract_mixin.py", line 338, in _check_ocr_status
self.with_company(self.company_id)._fill_document_with_results(ocr_results)
File "home/odoo/src/enterprise/18.0/account_invoice_extract/models/account_invoice.py", line 732, in _fill_document_with_results
self._save_form(ocr_results)
File "home/odoo/src/enterprise/18.0/account_invoice_extract/models/account_invoice.py", line 938, in _save_form
self._check_total_amount(total_ocr)
File "addons/account/models/account_move.py", line 3738, in _check_total_amount
subtotal['tax_groups'][0]['tax_amount_currency'] += tax_amount_rounding_error
```
[1]- https://github.com/odoo/odoo/blob/c047bf3d89e630c98c61bc45df7391fe0732c343/addons/account/models/account_move.py#L3747
sentry-6012011017
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prFixes 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 prevents pending local edits in embedded content from accidentally overwriting changes made by collaborators. It also streamlines how editor history updates are handled, improving consistency and reducing unnecessary processing.
Original PR description
### Issue: There was an issue when applying embedded state changes from a peer while there was a pending local embedded state change. Old unchanged properties of the local embedded change would…
### Issue: There was an issue when applying embedded state changes from a peer while there was a pending local embedded state change. Old unchanged properties of the local embedded change would overwrite peer changes. Instead, `commitStateChange` must check if a property has changed and replace the property only if that is the case. --- Furthermore, this PR introduces another small improvement: remove editor command "ADD_EXTERNAL_STEP" 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. Small fix to the table of content plugin, only `STEP_ADDED` has a `stepCommonAncestor` payload property, therefore commands which don't have it will use `this.editable` instead to search for new headings. task-4281356
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
This fixes an access error that prevented users with Invoicing Administrator rights from creating a company branch. Branch creation now works without requiring extra technical accounting permissions, reducing setup friction for finance administrators.
Original PR description
**Steps to reproduce:** - Install Invoicing - Make sure that current user has "Invoicing: Administrator" rights - Go to the configuration of a company - Create a branch - Save **Issue:** An Access Error is raised because a write is performed on an "account. reconcile.model.line" record while loading the chart template during the creation of the branch, but the user has not the appropriate group (i.e. Technical/Show Full Accounting Features). The creation of a branch should be possible for a user with the "Invoicing: Admnistrator" rights, even if he has no edition right on "account.reconcile. model.line" model. opw-4247717 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Updates the spreadsheet component with fixes and usability improvements for charts, pivots, formatting, and collaboration. Business users should see more accurate chart labels and tooltips, more reliable pivot behavior, and smoother formatting actions in spreadsheets.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/788df9213 [REL] 18.0.2 Task: 0 https://github.com/odoo/o-spreadsheet/commit/977b8f265 [IMP] charts: limit trending…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/788df9213 [REL] 18.0.2 Task: 0 https://github.com/odoo/o-spreadsheet/commit/977b8f265 [IMP] charts: limit trending line degree range Task: 4207820 https://github.com/odoo/o-spreadsheet/commit/9f337f326 [FIX] Charts: Fix tooltip value when data is zero Task: 4251681 https://github.com/odoo/o-spreadsheet/commit/f51993403 [IMP] pivot: disable automatic autofill Task: 4256700 https://github.com/odoo/o-spreadsheet/commit/4f2950a8b [FIX] paint format: copy conditional formats Task: 4226853 https://github.com/odoo/o-spreadsheet/commit/b977d1f66 [FIX] test: skipped test in `renderer_plugin.test.ts` Task: 4276968 https://github.com/odoo/o-spreadsheet/commit/5953d29a4 [FIX] format painter: use a single history step Task: 4277362 https://github.com/odoo/o-spreadsheet/commit/8ee4266a9 [FIX] logs: log performance information at debug level Task: 0 https://github.com/odoo/o-spreadsheet/commit/a81189ba1 [FIX] chart: avoid overlapping values on charts Task: 4207889 https://github.com/odoo/o-spreadsheet/commit/2e95535f0 [FIX] pivots: don't translate pivot titles Task: 4239967 https://github.com/odoo/o-spreadsheet/commit/b50c0f286 [FIX] pivot: autocomplete dimension after positional Task: 4235329 https://github.com/odoo/o-spreadsheet/commit/ab8b491c9 [FIX] chart: cleanup tooltip title code Task: 4269632 https://github.com/odoo/o-spreadsheet/commit/187843ed1 [FIX] side_panel: unify font weight across side panels Task: 4194259 https://github.com/odoo/o-spreadsheet/commit/3a77fe228 [FIX] pivot: divergent collaborative duplicated pivot name Task: 4199949 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
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
Financial report variants that depend on a matching chart of accounts are now available when users work across multiple companies. This prevents valid reports, such as localized profit and loss or balance sheet variants, from disappearing simply because several companies are selected.
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-4263627Automated 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
The HR contract dashboard now uses contract start and end dates instead of fixed dates or current status when showing historical contract data. This makes past reporting more accurate, including for archived employees who should still appear in historical figures.
Original PR description
Column L and M were static (hardcoded dates) Task: 4268760
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
Code cleanup and technical improvements
Odoo notification emails no longer show extra action links in the standard layout. This reduces clutter, makes messages easier to read, and helps email conversations feel more natural while keeping compatibility behind the scenes.
Original PR description
RATIONALE Improve email management and composition in Odoo, ease understanding and make flow more looking like email discussions. SPECIFICATIONS We consider actions to be mainly noise in notification emails as it bloats email content and hide real content. For Odoo v18 standard notification layout does not display them anymore but mechanism is kept for backward compatibility. It is going to be removed in master completely. Task-4284064
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