Thursday, December 21, 2023
31 changes · 17.0
Enhancements to existing features
This update adds automated testing for the carrier type widget in the EasyPost delivery integration. By implementing these tests, the team ensures that carrier selection functionality works correctly and remains reliable as the system evolves. This improves overall quality and reduces the risk of shipping-related issues.
Original PR description
Task: 3596494 Related: odoo/enterprise#51582 odoo/enterprise#52533
Resolved issues and error corrections
Fixed an issue that prevented users from saving general settings after all Point of Sale records were archived. This removes an unnecessary error and keeps configuration changes available even when no active PoS is set up.
Original PR description
Current behavior: The pos_self_ordering_mode field was not interpreted as invisible when no PoS existed. Because this is a required field you were not able to do any changes in the settings if you had no PoS. Steps to reproduce: - Archive all PoS - Go to Settings, and change any settings you want - Save the settings - You get an error "Invalid field 'pos_self_ordering_mode'" opw-3649784 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Documentation and clarification updates
This pull request records a signed contributor agreement for the contributor Fahad-2001. It supports Odoo's legal contribution process and does not change product behavior or customer-facing features.
Original PR description
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
Miscellaneous changes
Steps to Reproduce: Create 2 companies > Create employee in 1st company > Enable both companies > Create public holidays company-wise> In company 1 create a public holiday for (13/11/2023) > In company 2 create public holidays (13/11/2023) and (29/11/2023). Then switch to the one company (where the public holiday was created only for (13/11/2023))> Go to attendance > Configuration > Enable the count extra hours feature > Create attendance date (29/11/2023) for ex. 9 hours > Go to employee
Original PR description
Steps to Reproduce: Create 2 companies > Create employee in 1st company > Enable both companies > Create public holidays company-wise> In company 1 create a public holiday for (13/11/2023) > In…
This update corrects the security/support documentation to reflect that Odoo 14.0 is no longer supported after the 17.0 release. It helps customers and partners understand which versions remain eligible for support and security guidance.
Original PR description
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
This fixes an unreliable automated test around bus reconnection when a device changes network state. The change helps reduce false failures in the validation pipeline, making releases and maintenance more dependable without changing user-facing behavior.
Original PR description
Before this PR, the "can reconnect after late close event" test was relying on the `nextTick` helper to check which bus events were received when the device switches from online to offline. This test was non deterministic since a tick might not be enough to receive the related events: the bus service communicates with a shared worker through the MessagePort API, the worker uses a Websocket which dispatch events upon connection/reconnection. This commit replaces the use of the `nextTick` helper by the dedicated `waitForBusEvent` helper which resolves once the event is received. fixed runbot-45695
Live chat conversations now appear in the correct order based on their latest activity, including cases where activity dates are missing. This helps agents see the most relevant customer chats first and restores the reliability of related automated checks.
Original PR description
Since [1], the test that ensures live chat threads are sorted according to their last interrest date is broken. Indeed, the sort was moved from `im_livechat` to `website_livechat`. This is incorrect. This PR moves back the call to the sort function to the `im_livechat` module. [1]: https://github.com/odoo/odoo/pull/143382 fixes runbot-47784 enterprise: https://github.com/odoo/enterprise/pull/53065
The spacing between the Log note and Activities buttons has been adjusted to match the spacing between other nearby buttons. This makes the message area look more consistent after the WhatsApp button was added.
Original PR description
The margin between the `Log note`/`Activities` is more than `Send message`/`Log note` buttons. Which looks weird after the `WhatsApp` button is added. So, we update the margin between `Log note`/`Activities` to be the same as `Send message`/`Log note` buttons. task-[3497496](https://www.odoo.com/web#id=3497496&cids=2&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The spreadsheet dashboard multi-record selector now takes only the space it needs instead of stretching across a full line. This makes dashboard filters look cleaner and preserves space for other controls, while still wrapping when space is very limited.
Original PR description
### Before: Previously, the multi-record selector dropdown occupied an entire line. ### After: This PR addresses this issue by applying the `flex: 1 0 1rem;` property to the auto-complete dropdown. This adjustment confines the dropdown to the necessary space. If the space available is less than 1rem, it will wrap to a new line. Task ID: [3607067](https://www.odoo.com/web#id=3607067&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The gross margin button on analytic accounts now opens the correct list of related items instead of showing an empty result. This helps users review margin details without confusion or manual workarounds.
Original PR description
To reproduce: - Create a new plan with an account - Add an analytic item with this account - Go to the view of this account - Gross Margin Button has a value - Click on it => List is empty The reason being that the view should not include account_id, but auto_account_id 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
Cohort report action buttons now stay visible even when filters or measure choices return no records. This helps users recover from empty report results without losing access to key view controls.
Original PR description
This commit fixes an issue with the cohort view buttons which are not accessible when there is no data to display. This is annoying because it may happen when one changes the measures of the cohort view to one that won't display any data. This case will become quite common after https://github.com/odoo/enterprise/commit/684754430bc7062d7b69ea5b37e8aadc808c225c due to the fact that rows of null values will no longer be sent by the python to be displayed in the cohort. The fix here is therefore to move the cohort view buttons from the renderer to the controller so that they can be displayed above the no content helper and are therefore always visible even when the renderer is not present due to empty data. Steps to reproduce: - go to any cohort view (ex: Helpdesk -> Reporting -> Tickets Analysis) - filter records with a giberish filter task-3626278
This update corrects report calculation expressions used during upgrades for the Turkish localization. It helps ensure upgraded systems keep accurate localized financial reporting with minimal user-facing disruption.
The multi-record selector dropdown in spreadsheets was taking up too much space on the screen. This fix adjusts the dropdown styling so it only uses the space it needs, allowing other content to fit better on the same line. If space is limited, the dropdown will wrap to the next line instead of forcing everything to expand.
Original PR description
### Before: Previously, the multi-record selector dropdown occupied an entire line. ### After: This PR addresses this issue by applying the `flex: 1 0 1rem;` property to the auto-complete dropdown. This adjustment confines the dropdown to the necessary space. If the space available is less than 1rem, it will wrap to a new line. Task ID: [3607067](https://www.odoo.com/web#id=3607067&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
Steps to Reproduce: Create 2 companies > Create employee in 1st company > Enable both companies > Create public holidays company-wise> In company 1 create a public holiday for (13/11/2023) > In company 2 create public holidays (13/11/2023) and (29/11/2023). Then switch to the one company (where the public holiday was created only for (13/11/2023))> Go to attendance > Configuration > Enable the count extra hours feature > Create attendance date (29/11/2023) for ex. 9 hours > Go to employee form > You may see the extra hour of "1 hour" > Because there is no public holiday on 29/11/2023. Then enable both companies > Create attendance date (29/11/2023) for ex. 9 hours > Go to employee form > You may see the extra hours of "9 hours" > Because there is a public holiday in another company on 29/11/2023. Bug Source: commit 1407052 fixed the fact that public holidays are not taken into account when computing the overtime, but it doesn't cover the multi companies case. Solution: Verify that the public holiday company and the employee company are the same before applying the compute. An optimization was also added to avoid searching for public holidays in db by filtering with the employee company. opw-3597287 X-original-commit: 1407052 Forward-Port-Of: odoo/odoo#146877 Forward-Port-Of: odoo/odoo#143381
This deals with a bug when an expense re-invoiced with a 'sale_price' expense_policy and 'delivery' invoice_policy Current bad behaviour: - When re-invoicing another expense matching the first one's price_unit and product the quantities aren't updated properly - Furthermore, reversing the original move doesn't impact the sale order - Resetting the expense sheet to draft neither New correct behaviour: - When re-invoicing another expense matching the first one's they aren't groupe
Original PR description
This deals with a bug when an expense re-invoiced with a 'sale_price' expense_policy and 'delivery' invoice_policy Current bad behaviour: - When re-invoicing another expense matching the first one's price_unit and product the quantities aren't updated properly - Furthermore, reversing the original move doesn't impact the sale order - Resetting the expense sheet to draft neither New correct behaviour: - When re-invoicing another expense matching the first one's they aren't grouped together on the same line, allowing to update and reverse the lines independently - Reversing the original move sets its corresponding sale order line quantity and delivered quantity to 0 - Resetting the expense sheet to draft does the same - Resetting the original move does the same - Adds clarity to the sale_stock error message, so it's understandable from the expense view task-3458826 Forward-Port-Of: odoo/odoo#147026 Forward-Port-Of: odoo/odoo#140460
Current behavior: When you only used the "Next order coupons" loyalty program, the "enter code" button was not displayed. Steps to reproduce: - Install the pos_loyalty module - Archive all the loyalty programs - Create a loyalty program with "Next order coupons" as reward - Open a PoS session opw-3608894 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147044 Forward-Port-Of: odoo/odoo#146681
Original PR description
Current behavior: When you only used the "Next order coupons" loyalty program, the "enter code" button was not displayed. Steps to reproduce: - Install the pos_loyalty module - Archive all the loyalty programs - Create a loyalty program with "Next order coupons" as reward - Open a PoS session opw-3608894 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147044 Forward-Port-Of: odoo/odoo#146681
Current behavior: When grouping by warehouse in the sales report, the pos orders appeared under the "None" warehouse group. Steps to reproduce: - Create a PoS order - Validate the PoS order, and close the session - Go to sale reporting, group by warehouse - A group "None" appears, with the PoS order inside opw-3540797 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147033 Forward-Port-Of: odoo/odoo#145229
Original PR description
Current behavior: When grouping by warehouse in the sales report, the pos orders appeared under the "None" warehouse group. Steps to reproduce: - Create a PoS order - Validate the PoS order, and close the session - Go to sale reporting, group by warehouse - A group "None" appears, with the PoS order inside opw-3540797 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147033 Forward-Port-Of: odoo/odoo#145229
- Create a "/test" page, publish it - Set "/test" as homepage url directly on the website (in the settings) - Go to that page - Open the page properties and change its URL from /test to /else From there, the website setting (`homepage_url` field) was still set to /test and not /else. It means that the first "published" menu would then be used to avoid serving a 404 as homepage to your visitors. It is a bit confusing and people probably just expect to change that website setting too whe
Original PR description
- Create a "/test" page, publish it - Set "/test" as homepage url directly on the website (in the settings) - Go to that page - Open the page properties and change its URL from /test to /else From there, the website setting (`homepage_url` field) was still set to /test and not /else. It means that the first "published" menu would then be used to avoid serving a 404 as homepage to your visitors. It is a bit confusing and people probably just expect to change that website setting too when changing the page URL. We had some feedback about similar flows (that couldn't be reproduced or where people weren't sure) where people ended up writting on the wrong page or losing their content. Maybe this will mitigate the issue. Kind of related: task-3476840 Forward-Port-Of: odoo/odoo#145802
To reproduce ============ - on studio > create new report from internal layout - execute 2 columns command --> the second column will be under the first one Problem ======= the browser finds out that the `iframe` is small to keep two `col-lg-6` side by side. Solution ======== use `col-6` instead, like in 17 opw-3585043 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144956
Original PR description
To reproduce ============ - on studio > create new report from internal layout - execute 2 columns command --> the second column will be under the first one Problem ======= the browser finds out that the `iframe` is small to keep two `col-lg-6` side by side. Solution ======== use `col-6` instead, like in 17 opw-3585043 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144956
If customer did not have address,email and telephone fields, "False" would be send to Adyen resulting in these field containing False values, which in some cases was falsely triggering anti-fraud system. task-3159378 Forward-Port-Of: odoo/odoo#146869 Forward-Port-Of: odoo/odoo#139600
Original PR description
If customer did not have address,email and telephone fields, "False" would be send to Adyen resulting in these field containing False values, which in some cases was falsely triggering anti-fraud system. task-3159378 Forward-Port-Of: odoo/odoo#146869 Forward-Port-Of: odoo/odoo#139600
[FIX] survey: prevent soft lock with conditional questions If multiple questions are conditionally displayed if the user selects an answer in another multi-choice question, that answer was added multiple times in the list used to filter mandatory questions that have to be answered when displayed. This is an issue because the answer was only removed once if the user changes his choice resulting in a state where a mandatory question that is hidden stays mandatory even though it is not displa
Original PR description
[FIX] survey: prevent soft lock with conditional questions If multiple questions are conditionally displayed if the user selects an answer in another multi-choice question, that answer was added…
[FIX] survey: prevent soft lock with conditional questions
If multiple questions are conditionally displayed if the user selects an answer
in another multi-choice question, that answer was added multiple times in the
list used to filter mandatory questions that have to be answered when displayed.
This is an issue because the answer was only removed once if the user changes
his choice resulting in a state where a mandatory question that is hidden stays
mandatory even though it is not displayed to the user.
How to reproduce:
- create a new survey with:
- Question1:
- multi-choice with one answer
- 2 answers (A, B)
- Question2:
- single line text box
- mandatory answer
- conditional display depending on answer B of Question1
- Question3:
- single line text box
- conditional display depending on answer B of Question1
- start the survey
- click on answer B then click on answer A
Current behavior:
- user is not able to submit the survey with answer A selected
Expected behavior:
- user should be able to submit the survey
Note:
The issue was already fixed from 17.0 in this [commit], but the test is
still adjusted to ensure that displaying/hiding multiple questions at once
depending on conditional triggers works as intended without preventing the user
to finalize the survey.
[commit]: https://github.com/odoo/odoo/commit/55fa52be8a80e6f7ee2a526db29c0d97c24ae8f6
task-3630079
Co-authored-by: Salvo Rapisarda <sdrapisarda@gmail.com>
Co-authored-by: Damien Abeloos <abd@odoo.com>
Forward-Port-Of: odoo/odoo#146914
Forward-Port-Of: odoo/odoo#145392Steps to reproduce the issue: - In website edit mode, add newsletter block onto the page. - In the options of the snippet, change the template to "form". - Click on the "Display Thanks Button" checkbox. => Traceback. The "Display Thanks Button" should not be visible for "form" template. This commit hides the "Display Thanks Button" when the "from" template is selected in the option of the newsletter block. The "Display Thanks Button" was added by this this commit [1] and the "from
Original PR description
Steps to reproduce the issue: - In website edit mode, add newsletter block onto the page. - In the options of the snippet, change the template to "form". - Click on the "Display Thanks Button" checkbox. => Traceback. The "Display Thanks Button" should not be visible for "form" template. This commit hides the "Display Thanks Button" when the "from" template is selected in the option of the newsletter block. The "Display Thanks Button" was added by this this commit [1] and the "from" template was added by this this commit [2]. [1]: https://github.com/odoo/odoo/commit/a9eae10af88a0aba88ce6d3e3f517926edf36c00 [2]: https://github.com/odoo/odoo/commit/bd6ef64f4c79b9c04dc8b85dc2daccb61d55cad0 task-3610063 Forward-Port-Of: odoo/odoo#145429
When the verification code is saved, it triggers the full save and users get errors about other required fields, e.g. website language missing. This commit removes save on every focusout, as the save is triggered when clicking confirm. Ticket 3637773 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146973
Original PR description
When the verification code is saved, it triggers the full save and users get errors about other required fields, e.g. website language missing. This commit removes save on every focusout, as the save is triggered when clicking confirm. Ticket 3637773 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146973
According to: https://requests.readthedocs.io/en/stable/user/advanced/#timeouts There is 2 different timeout, the connect and read one. Both have their own exception if they timeout, the connect one was handled but not the read one. Before this commit: If the read timeout happen, a traceback will occur interrupting the (scheduled) job: ``` File ".../odoo/addons/product_images/wizard/product_fetch_image_wizard.py", line 308, in _get_image_from_url response = self._session.get(url,
Original PR description
According to:
https://requests.readthedocs.io/en/stable/user/advanced/#timeouts There is 2 different timeout, the connect and read one. Both have their own exception if they timeout, the connect one was handled but not the read one.
Before this commit:
If the read timeout happen, a traceback will occur interrupting
the (scheduled) job:
```
File ".../odoo/addons/product_images/wizard/product_fetch_image_wizard.py", line 308, in _get_image_from_url
response = self._session.get(url, timeout=5)
...
requests.exceptions.ReadTimeout: HTTPSConnectionPool(host='...', port=443): Read timed out. (read timeout=5)
```
After this commit:
We ignore the timeout-ing request the same way the
request.ConnectionError do
opw-3546601
Forward-Port-Of: odoo/odoo#145967Description: =========== Before this commit, when a line in edit mode in a list view is the last tabable element in a dialog, pressing "tab" does not cause a switch to the next line in edit mode. It is therefore not possible to navigate in this dialog using "tab". Problem: ======= Currently, the ListRenderer listens to keydown events using few t-on-keydown.synthetic in order to know whether to switch the next line to edition. For information, the effect of a synthetic is to create a singl
Original PR description
Description: =========== Before this commit, when a line in edit mode in a list view is the last tabable element in a dialog, pressing "tab" does not cause a switch to the next line in edit mode. It…
Description: =========== Before this commit, when a line in edit mode in a list view is the last tabable element in a dialog, pressing "tab" does not cause a switch to the next line in edit mode. It is therefore not possible to navigate in this dialog using "tab". Problem: ======= Currently, the ListRenderer listens to keydown events using few t-on-keydown.synthetic in order to know whether to switch the next line to edition. For information, the effect of a synthetic is to create a single listener on "document" instead of creating a listener for each element. There is a conflict with the ui service which listens to all the "tab" keydowns in order to check whether or not we are on the last tabable element of the current activeElement. If we are, we stop the event and focus on the first tabable element. This feature avoids the need to navigate outside dialogs by pressing tab. In our situation, this has the effect of stopping the keydown event before the synthetic can receive it, as the service ui listener is placed on the dialog and the synthetic listener on the document. Solution: ======== Remove the use of synthetic in the ListRenderer. No significant loss of performance was observed. 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#146942 Forward-Port-Of: odoo/odoo#146609
Prior to this change, anything passed in the context of a m2m avatar field would not be taken into account because the context was not passed properly in the many2many_tags_avatar_field template. This commit fixes that and also adds a test for future testing. task-3599601 Description of the issue/feature this PR addresses: The initial problem that this PR tried to address is that the resource's form view changed depending on when you opened it from the planning app. Specifically,
Original PR description
Prior to this change, anything passed in the context of a m2m avatar field would not be taken into account because the context was not passed properly in the many2many_tags_avatar_field template.…
Prior to this change, anything passed in the context of a m2m avatar field would not be taken into account because the context was not passed properly in the many2many_tags_avatar_field template. This commit fixes that and also adds a test for future testing. task-3599601 Description of the issue/feature this PR addresses: The initial problem that this PR tried to address is that the resource's form view changed depending on when you opened it from the planning app. Specifically, two additional fields would appear when opening the form view from the planning roles view in comparisson to the planning slot view. We made those fields invisible in an extension of the original resource form view and we set it to the field in the role view through the context. The context passed to the field though is not taken into account. With this change in this PR, both the evalContext and the context are combined for the field's context like it is done for many2one fields. Current behavior before PR: Context passed to many2many fields (using many2many_tags_field widget) is not taken into account when evaluating/rendering them. In consequence, the resource's form view changed depending on when you opened it from in the planning app. Desired behavior after PR is merged: Context passed should now be taken into account. In consequence, the resource's form view should be the same regardless on when you opened it from. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142470
### Before this PR: No hover pointer and there is no evidence of what is selected  ### After this PR: Evidence of what is selected and hover pointer  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144482
Original PR description
### Before this PR: No hover pointer and there is no evidence of what is selected  ### After this PR: Evidence of what is selected and hover pointer  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144482
To reproduce: 1. enable 'debug' mode 2. go to menu "Settings / Translations / Languages" and enable a new language (ex: nl_NL) 3 create a new lead and set that language (IMPORTANT: do not set a customer) 4. go back to menu "Settings / Translations / Languages" and disable the language you previously enabled at step 2. 5. from the lead list view, selection the lead you created at step 3, click "Action" and choose "Convert to opportunities" 6. In the wizard choose for: * Conversion A
Original PR description
To reproduce: 1. enable 'debug' mode 2. go to menu "Settings / Translations / Languages" and enable a new language (ex: nl_NL) 3 create a new lead and set that language (IMPORTANT: do not set a…
To reproduce:
1. enable 'debug' mode
2. go to menu "Settings / Translations / Languages" and enable a new language (ex: nl_NL) 3 create a new lead and set that language
(IMPORTANT: do not set a customer)
4. go back to menu "Settings / Translations / Languages" and disable the language you previously enabled at step 2.
5. from the lead list view, selection the lead you created at step 3, click "Action" and choose "Convert to opportunities"
6. In the wizard choose for:
* Conversion Action: Convert to opportunity
* Customer: Create a new customer
7. Click button "Convert to opportunity"
This crash with the following error:
```
Traceback (most recent call last):
...
File "/data/build/odoo/addons/crm/wizard/crm_lead_to_opportunity_mass.py", line 103, in action_mass_convert
return self.action_apply()
File "/data/build/odoo/addons/crm/wizard/crm_lead_to_opportunity.py", line 121, in action_apply
result_opportunity = self._action_convert()
File "/data/build/odoo/addons/crm/wizard/crm_lead_to_opportunity.py", line 144, in _action_convert
self._convert_and_allocate(result_opportunities, [self.user_id.id], team_id=self.team_id.id)
File "/data/build/odoo/addons/crm/wizard/crm_lead_to_opportunity_mass.py", line 78, in _convert_and_allocate
return super(Lead2OpportunityMassConvert, self)._convert_and_allocate(leads, salesmen_ids, team_id=team_id)
File "/data/build/odoo/addons/crm/wizard/crm_lead_to_opportunity.py", line 152, in _convert_and_allocate
self._convert_handle_partner(
File "/data/build/odoo/addons/crm/wizard/crm_lead_to_opportunity_mass.py", line 109, in _convert_handle_partner
return super(Lead2OpportunityMassConvert, self)._convert_handle_partner(lead, action, partner_id)
File "/data/build/odoo/addons/crm/wizard/crm_lead_to_opportunity.py", line 166, in _convert_handle_partner
lead.with_context(default_user_id=self.user_id.id)._handle_partner_assignment(
File "/data/build/odoo/addons/crm/models/crm_lead.py", line 1556, in _handle_partner_assignment
partner = lead._create_customer()
File "/data/build/odoo/addons/crm/models/crm_lead.py", line 1692, in _create_customer
return Partner.create(self._prepare_customer_values(self.name, is_company=False))
File "<decorator-gen-1007>", line 2, in create
File "/data/build/odoo/odoo/api.py", line 395, in _model_create_single
return create(self, arg)
File "/data/build/odoo/addons/l10n_cl/models/res_partner.py", line 55, in create
return super().create(values)
File "<decorator-gen-329>", line 2, in create
File "/data/build/odoo/odoo/api.py", line 417, in _model_create_multi
return create(self, [arg])
File "/data/build/odoo/addons/base_vat/models/res_partner.py", line 718, in create
return super(ResPartner, self).create(vals_list)
File "<decorator-gen-263>", line 2, in create
File "/data/build/odoo/odoo/api.py", line 418, in _model_create_multi
return create(self, arg)
File "/data/build/odoo/addons/account/models/partner.py", line 557, in create
return super().create(vals_list)
File "<decorator-gen-227>", line 2, in create
File "/data/build/odoo/odoo/api.py", line 418, in _model_create_multi
return create(self, arg)
File "/data/build/odoo/addons/partner_autocomplete/models/res_partner.py", line 163, in create
partners = super(ResPartner, self).create(vals_list)
File "<decorator-gen-223>", line 2, in create
File "/data/build/odoo/odoo/api.py", line 398, in _model_create_single
return self.browse().concat(*(create(self, vals) for vals in arg))
File "/data/build/odoo/odoo/api.py", line 398, in <genexpr>
return self.browse().concat(*(create(self, vals) for vals in arg))
File "/data/build/odoo/addons/mail_plugin/models/res_partner.py", line 32, in create
partner = super(ResPartner, self).create(vals)
File "<decorator-gen-100>", line 2, in create
File "/data/build/odoo/odoo/api.py", line 417, in _model_create_multi
return create(self, [arg])
File "/data/build/odoo/odoo/addons/base/models/res_partner.py", line 652, in create
partners = super(Partner, self).create(vals_list)
File "<decorator-gen-137>", line 2, in create
File "/data/build/odoo/odoo/api.py", line 418, in _model_create_multi
return create(self, arg)
File "/data/build/odoo/addons/mail/models/mail_thread.py", line 265, in create
threads = super(MailThread, self).create(vals_list)
File "<decorator-gen-306>", line 2, in create
File "/data/build/odoo/odoo/api.py", line 418, in _model_create_multi
return create(self, arg)
File "/data/build/odoo/addons/website/models/mixins.py", line 211, in create
records = super(WebsitePublishedMixin, self).create(vals_list)
File "<decorator-gen-69>", line 2, in create
File "/data/build/odoo/odoo/api.py", line 418, in _model_create_multi
return create(self, arg)
File "/data/build/odoo/odoo/addons/base/models/ir_fields.py", line 613, in create
recs = super().create(vals_list)
File "<decorator-gen-15>", line 2, in create
File "/data/build/odoo/odoo/api.py", line 418, in _model_create_multi
return create(self, arg)
File "/data/build/odoo/odoo/models.py", line 4088, in create
records = self._create(data_list)
File "/data/build/odoo/odoo/models.py", line 4152, in _create
col_val = field.convert_to_column(val, self, stored)
File "/data/build/odoo/odoo/fields.py", line 2538, in convert_to_column
value = self.convert_to_cache(value, record)
File "/data/build/odoo/odoo/fields.py", line 2550, in convert_to_cache
raise ValueError("Wrong value for %s: %r" % (self, value))
Exception
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/data/build/odoo/odoo/http.py", line 654, in _handle_exception
return super(JsonRequest, self)._handle_exception(exception)
File "/data/build/odoo/odoo/http.py", line 301, in _handle_exception
raise exception.with_traceback(None) from new_cause
ValueError: Wrong value for res.partner.lang: 'nl_NL'
```
This commit ensure that when converting a lead to an opportunity, we
don't crash if language is archived.
OPW-3617359
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#146638
Forward-Port-Of: odoo/odoo#145331Transation of the 'Sale: Payment Done' template is missing latest fixes opw-3624026 Forward-Port-Of: odoo/odoo#146284
Original PR description
Transation of the 'Sale: Payment Done' template is missing latest fixes opw-3624026 Forward-Port-Of: odoo/odoo#146284
Steps to reproduce: - Install event_crm module - Go to Website and visit the Events page - Register for Hockey Tournament with an email containing `@example.com` - Go to CRM in backend and open the new lead created. Issue: HTML tags are not escaped in the lead description. Cause: The override of `_get_lead_description_registration` is returning a string that escape also the `</br>` tags. Solution: Use Markup around strings that contain the `</br>` tags to
Original PR description
Steps to reproduce: - Install event_crm module - Go to Website and visit the Events page - Register for Hockey Tournament with an email containing `@example.com` - Go to CRM in backend and open the new lead created. Issue: HTML tags are not escaped in the lead description. Cause: The override of `_get_lead_description_registration` is returning a string that escape also the `</br>` tags. Solution: Use Markup around strings that contain the `</br>` tags to be not escaped. opw-3471097 Forward-Port-Of: odoo/odoo#146545 Forward-Port-Of: odoo/odoo#133736
This traceback arises when the user removes the `from` or `to` values. To reproduce this traceback: 1) Install `account_accountant` and make sure the debugger mode on 2) Open `Accounting/Configuration/Account Groups` 3) Create a new record 4) Give the `from` and `to` values and save the record. 5) Now remove the `From` value and try to save it Error:- ``` TypeError: '<' not supported between instances of 'str' and 'bool' File "odoo/http.py", line 2157, in __call__ res
Original PR description
This traceback arises when the user removes the `from` or `to` values. To reproduce this traceback: 1) Install `account_accountant` and make sure the debugger mode on 2) Open…
This traceback arises when the user removes the `from` or `to` values.
To reproduce this traceback:
1) Install `account_accountant` and make sure the debugger mode on
2) Open `Accounting/Configuration/Account Groups`
3) Create a new record
4) Give the `from` and `to` values and save the record.
5) Now remove the `From` value and try to save it
Error:-
```
TypeError: '<' not supported between instances of 'str' and 'bool'
File "odoo/http.py", line 2157, in __call__
response = request._serve_db()
File "odoo/http.py", line 1732, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1759, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1960, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 24, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 466, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "addons/web/models/models.py", line 1069, in onchange
todo = [
File "addons/web/models/models.py", line 1072, in <listcomp>
if field_name not in done and snapshot0.has_changed(field_name)
File "addons/web/models/models.py", line 1185, in has_changed
return self[field_name] != self.record[field_name]
File "odoo/models.py", line 6584, in __getitem__
return self._fields[key].__get__(self, type(self))
File "odoo/fields.py", line 1151, in __get__
self.recompute(record)
File "odoo/fields.py", line 1366, in recompute
apply_except_missing(self.compute_value, recs)
File "odoo/fields.py", line 1339, in apply_except_missing
func(records)
File "odoo/fields.py", line 1388, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 4858, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 101, in determine
return needle(*args)
File "addons/account/models/account_account.py", line 835, in _compute_code_prefix_end
if not group.code_prefix_end or group.code_prefix_end < group.code_prefix_start:
```
When removing the `From` value `code_prefix_start` will be False.
It leads to the above traceback from here.
https://github.com/odoo/odoo/blob/8266af83398e3f544506d904d0a366797f467328/addons/account/models/account_account.py#L832-L836
sentry-4715927815
Forward-Port-Of: odoo/odoo#146920Steps to reproduce: - Install `website_appointment` module - Go to Calendar -> Online Appointments - Open any published appointment - Go to `Messages` tab and set any text with a link in `Introduction Message` - Go to `Website` and click on Appointment menu Issue: The card of the edited appointment is not displayed correctly; introduction message is bellow users avatars. Cause: Since we have a link inside a link, the browser try to fix the html by addi
Original PR description
Steps to reproduce:
- Install `website_appointment` module
- Go to Calendar -> Online Appointments
- Open any published appointment
- Go to `Messages` tab and set any text with a link in
`Introduction Message`
- Go to `Website` and click on Appointment menu
Issue:
The card of the edited appointment is not displayed correctly;
introduction message is bellow users avatars.
Cause:
Since we have a link inside a link, the browser try to fix the html
by adding the outer link (+ his css class) to each element (except the
one with a link) so that both links are still clickable.
By doing so, the classes `d-flex flex-column` of the link are also
duplicated and therefore broke the card display.
Solution:
Remove the `d-flex flex-column` on the outer link.
opw-3595058
Forward-Port-Of: odoo/enterprise#52073