Friday, October 25, 2024
38 changes · saas-17.4
Enhancements to existing features
Invoice item descriptions exported in UBL XML now keep line breaks readable by replacing them with spaces instead of comma-separated text. This makes electronic invoice descriptions cleaner and closer to the original wording for recipients and integrations.
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
The chart configuration panel now uses clearer wording for stacked line and bar chart options. This small wording and spacing improvement makes chart settings easier to understand for users configuring spreadsheet charts.
Original PR description
Change the checkbox label of stacked charts from `stacked linechart` to `stacked line chart` in the chart configuration panel. Same for bar charts. Also removed padding between `stacked` and `cumulative` checkboxes in the line chart panel. Task: [3978443](https://www.odoo.com/web#id=3978443&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
Resolved issues and error corrections
Draft orders created through point of sale now keep the correct sales team assigned. This helps sales reporting and follow-up stay accurate when orders are saved before completion.
Original PR description
Before this commit, the sales team could be missing from an order captured as draft due to writing a false value. opw-4230882 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
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
The Inventory Overview now displays the back orders field and its label correctly when users group records or apply filters. This prevents visual overlap on inventory cards, making the overview easier to read and reducing confusion for warehouse users.
Original PR description
In the Inventory Overview, when 'group by' or custom filter is applied, the back orders field and its label overlap on the kanban card. Steps to reproduce: 1. Open Inventory --> Overview. 2. use 'group by' or apply a filter. 3. Observe the back order field on the kanban card for overlapping issues. OPW-4188426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents Odoo from trying to retrieve delivery tracking links from carriers that are not active. It reduces errors in testing or inactive carrier setups and helps keep delivery operations more reliable.
Original PR description
We should only try to fetch tracking_url for the delivery carriers which are active. We get errors when running database in test as this leads database trying to fetch url from external and neutralize of database not working as expected. 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
Alert link styling has been moved to the report-specific area so PDF reports keep the intended colors without affecting the rest of Odoo. This prevents dark mode screens from incorrectly using light mode alert link colors, improving visual consistency for users.
Original PR description
Changing bootstrap versions caused a change in how the color for the alert-link class was being chosen which broke something with pdf reports. A change was then made to fix pdf reports but this ended up breaking alert-links elsewhere in Odoo and the light mode colors for alert-links were being used in dark mode. This change moves the styling to a report specific scss file to resolve the issue in the backend. Here is the aforementioned change: https://github.com/odoo/odoo/pull/178824 opw-[4211334](https://www.odoo.com/web#id=4211334&view_type=form&model=project.task)
PDF generation no longer creates misleading device log entries that make automated report requests appear as real user devices. This keeps device history cleaner while preserving normal activity tracking for users working at the same time.
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.
A previous adjustment to a subscription performance test has been undone because the related underlying change is also being reverted. This keeps the test expectations aligned with the current system behavior and helps avoid misleading test failures.
Original PR description
This reverts commit a0a5dea9178d7db7ef35d8241ad13f8bac406044 as we're reverting e3acf5937cd7a65087a0178fadd666dead2b99db opw-4270399
Restaurant floor screens now show only appointments scheduled for the current day on tables. This prevents staff from seeing future bookings too early and helps avoid confusion during daily service.
Original PR description
Before this commit, next appointment was shown on a table even if this appointment was not for today. We not only allow to show today's appointment on the floor screen. task-id: 4285487
Fixed a display issue when moving signature fields in the Sign app. Users now see cleaner drag behavior, with the original field properly hidden and fields no longer disappearing when moved outside a page area.
Original PR description
Before this commit when dragging a sign item, the initial copy wasn't invisible completely. For example placeholder, dragging arrow were still visible. This commit aims to fix the issue by setting visibility of sign_item_body to be same as parent. Task: 4195899
* 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
### Issue: `test_dblclick_event_from_calendar` tour test fails on Saturday ### Explanation: In the tour, we test an event with daily recurrence. Since the Weekly Calendar starts on Sunday and ends on Saturday, if an event starts on Saturday, the second occurrence of the event is on the next week and can not be reached. ### Fix: Moving to next week for the occurrence test, limiting recurrence to 8 days to remove useless rendering. Setting `drag_and_drop` tour in Monthly Calendar v
Original PR description
### Issue: `test_dblclick_event_from_calendar` tour test fails on Saturday ### Explanation: In the tour, we test an event with daily recurrence. Since the Weekly Calendar starts on Sunday and ends on…
### Issue: `test_dblclick_event_from_calendar` tour test fails on Saturday ### Explanation: In the tour, we test an event with daily recurrence. Since the Weekly Calendar starts on Sunday and ends on Saturday, if an event starts on Saturday, the second occurrence of the event is on the next week and can not be reached. ### Fix: Moving to next week for the occurrence test, limiting recurrence to 8 days to remove useless rendering. Setting `drag_and_drop` tour in Monthly Calendar view to avoid issues caused by potential `drag_and_drop` behaviour changes. In Monthly Calendar view, some days from previous and following months are visible, with a maximum of 6 before (Feb 23, see Mar 2025) and 14 after (Mar 14, see Feb 2026). Initial date being set in the backend, it does not have to respect those limitations. Changes operated in the frontend are bound to these and must be set between 15 and 22 included with the current selector. runbot-error-65494 Forward-Port-Of: odoo/odoo#185062 Forward-Port-Of: odoo/odoo#166502
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
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
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
nodeValue on `input` always return null. To get the previous value of the input cell, the query should be `matrixInput.attributes.value.nodeValue`. That way unchanged cell won't be send to the list of data to be updated. opw: 3987284 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#184706
Original PR description
nodeValue on `input` always return null. To get the previous value of the input cell, the query should be `matrixInput.attributes.value.nodeValue`. That way unchanged cell won't be send to the list of data to be updated. opw: 3987284 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#184706 Forward-Port-Of: odoo/odoo#184294
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
## 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#176342Using 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
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
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
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
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
- 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
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
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
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
Issue: Mail scanners can send HTTP HEAD requests to links contained in emails, which can change the state of a sign request without user action. Steps: - send a sign request - look in mailhog to get the notification mail - copy the link at the bottom of the mail and `curl --head <url>` - the sign request is now ignored opw-4217355 Forward-Port-Of: odoo/enterprise#72182
Original PR description
Issue: Mail scanners can send HTTP HEAD requests to links contained in emails, which can change the state of a sign request without user action. Steps: - send a sign request - look in mailhog to get the notification mail - copy the link at the bottom of the mail and `curl --head <url>` - the sign request is now ignored opw-4217355 Forward-Port-Of: odoo/enterprise#72182
This is a complement of previous fix: https://github.com/odoo/enterprise/commit/9b2d9508745fb1b00e42c8d729d01ad7ae1b4b85 Add the company of the move in the context as it is possible that the company of the move and the current company are different. Related community PR: https://github.com/odoo/odoo/pull/185096 Forward-Port-Of: odoo/enterprise#71725
Original PR description
This is a complement of previous fix: https://github.com/odoo/enterprise/commit/9b2d9508745fb1b00e42c8d729d01ad7ae1b4b85 Add the company of the move in the context as it is possible that the company of the move and the current company are different. Related community PR: https://github.com/odoo/odoo/pull/185096 Forward-Port-Of: odoo/enterprise#71725
The 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
When the date in the modify wizard for assets is changed, the residual_value should be updated to give a better view to the user. As this value is changed, the tests had to be changed accordingly. The gain or loss account is now correctly adapted from the computed value (itself computed on the date) and the Asset Counterpart Account is hidden if there is no gain. task-3981380 Forward-Port-Of: odoo/enterprise#72030 Forward-Port-Of: odoo/enterprise#70277
Original PR description
When the date in the modify wizard for assets is changed, the residual_value should be updated to give a better view to the user. As this value is changed, the tests had to be changed accordingly. The gain or loss account is now correctly adapted from the computed value (itself computed on the date) and the Asset Counterpart Account is hidden if there is no gain. task-3981380 Forward-Port-Of: odoo/enterprise#72030 Forward-Port-Of: odoo/enterprise#70277
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
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
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 don't need the 'textarea[name="message"]:first:value()' tringger, we can use `run: 'edit` instead so removed that & used common classes that works on all version. Task-4210376 Forward-Port-Of: odoo/enterprise#72692 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 don't need the 'textarea[name="message"]:first:value()' tringger, we can use `run: 'edit` instead so removed that & used common classes that works on all version. Task-4210376 Forward-Port-Of: odoo/enterprise#72692 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