Friday, March 27, 2020
20 changes · master
Enhancements to existing features
This update adds clear internal names to key sections of the Sales form. It helps future customizations target those sections more reliably, reducing maintenance effort when the form layout changes.
Original PR description
Description of the issue/feature this PR addresses: Easier xpath expressions Current behavior before PR: It is not really easy to xpath into these groups and may require error-prone xpath expressions that are long(er) Desired behavior after PR is merged: Easy way to xpath by name into the groups. Safer and faster. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
New email templates created from event registrations now automatically use the correct related record type. This prevents setup mistakes and helps event communications work as expected without extra manual configuration.
Original PR description
Before this commit, Creating a new Email template from here doesn't add correct value for model_id. In this commit, we set default value so model_id is set correctly on new Templates 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
The settings documentation link now uses a green question-circle icon, making the help option clearer and easier to recognize. This is a small visual improvement with no expected impact on business processes or workflows.
Original PR description
Change icon for documentation link to fa-question-circle in green. Task ID 2226026 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Guided product tours can now be given a priority so they run in a predictable order when several are available. This improves consistency for workflows such as field service sales and timesheet grid onboarding, while tours without a priority continue to work as before.
Original PR description
Before this commit, tours were activated in a non deterministic way and there was no way to control the order. Now there is a `sequence` key in the options dict (i.e. the second parameters of `tour.register`) which will determine the tour sequence order, the lowest being first and going upward. Unsequenced tours will behave as before with no particular order. Also added a sequence on a few tours. Task 2191192 Community: https://github.com/odoo/odoo/pull/48230
Resolved issues and error corrections
This fix ensures database save operations during web requests are handled in the safe retry flow. It reduces the chance of failed requests caused by temporary database conflicts and avoids using temporary routing information after it is no longer valid.
Original PR description
Since the ORM serialization automatic retry is done in the checked call, committing outside of this context could potentially cause a postgres exception without trying a retry like a checked call should. Forward-port of #46719.
Miscellaneous changes
Steps to reproduce: - install project, studio - activate ratings for projects and create a kanban view with the rating model (trough studio) Previous behavior: some images in the kanban view are not displayed Current behavior: all images are displayed properly opw-2205549 Forward-Port-Of: odoo/odoo#48406
Original PR description
Steps to reproduce: - install project, studio - activate ratings for projects and create a kanban view with the rating model (trough studio) Previous behavior: some images in the kanban view are not displayed Current behavior: all images are displayed properly opw-2205549 Forward-Port-Of: odoo/odoo#48406
When the currency_id is unset from the invoice and account moves are set by means of updating taxes or the line itself traceback will occur because there are no checks on the presence of a currency. Imposing the condition directly on the onchange solves the issue. Since the currency_id is a required field for the invoice the recomputation will be triggered again with the correct values opw-2192628 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-
Original PR description
When the currency_id is unset from the invoice and account moves are set by means of updating taxes or the line itself traceback will occur because there are no checks on the presence of a currency. Imposing the condition directly on the onchange solves the issue. Since the currency_id is a required field for the invoice the recomputation will be triggered again with the correct values opw-2192628 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#48348
### Issue - Install eCommerce with any theme - Website > Enable optional product - Create a SO with an optional product - Save > Customer Preview - Mobile view with inspector - Click on the shopping cart icon in the optional product line Quantity selector is not correctly displayed ### Cause First, the input width is 50%, which means very small on mobile and there are paddings on the input and the buttons ### Solution Remove the 50% width and paddings on
Original PR description
### Issue - Install eCommerce with any theme - Website > Enable optional product - Create a SO with an optional product - Save > Customer Preview - Mobile view with inspector - Click on the shopping cart icon in the optional product line Quantity selector is not correctly displayed ### Cause First, the input width is 50%, which means very small on mobile and there are paddings on the input and the buttons ### Solution Remove the 50% width and paddings on mobile It allows to see 3 chars on very small mobile screen. **OPW-2220893** -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#48092
- Install CRM, sales and Automated Action - Create the automated action * Model -> Sale Order * Trigger Condition -> On creation * Action To Do -> Add followers * Add Channels -> sales - Create a new CRM opportunity with a partner set, Save - Click on the "New quotation" - Save A Traceback "Error: A follower must be either a partner or a channel (but not both)." will popup, blocking the user from completing the action. This occur because the context flag default_partner_i
Original PR description
- Install CRM, sales and Automated Action - Create the automated action * Model -> Sale Order * Trigger Condition -> On creation * Action To Do -> Add followers * Add Channels -> sales - Create a new…
- Install CRM, sales and Automated Action - Create the automated action * Model -> Sale Order * Trigger Condition -> On creation * Action To Do -> Add followers * Add Channels -> sales - Create a new CRM opportunity with a partner set, Save - Click on the "New quotation" - Save A Traceback "Error: A follower must be either a partner or a channel (but not both)." will popup, blocking the user from completing the action. This occur because the context flag default_partner_id is used by the model to override the empty partner_id which should remain empty Other use case (2210285): After adding a channel as a follower to a sales team it is not possible to create a sale order from a contact or opportunity. You can only create a sale order from the sales app in that case. Adding related test opw-2200219 opw-2210285 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#47761 Forward-Port-Of: odoo/odoo#46818
Commit https://github.com/odoo/odoo/commit/bb0cdec4594fab8c22265ed8af0c2d431a263b72#diff-e4ca107fe5c84ec39ba346fb90d1bdf6R76 added strange code affecting the whole editor when website_blog was installed. To stay consistent, commit https://github.com/odoo/odoo/commit/80f54f563a3917828c5f67dfe9c44d0f6b0c5324 moved it in standard website and marked it as to review. It is in fact the cause of a bug: *all* drop areas appeared with a big editor text "Drag and drop a building block here" because
Original PR description
Commit https://github.com/odoo/odoo/commit/bb0cdec4594fab8c22265ed8af0c2d431a263b72#diff-e4ca107fe5c84ec39ba346fb90d1bdf6R76 added strange code affecting the whole editor when website_blog was installed. To stay consistent, commit https://github.com/odoo/odoo/commit/80f54f563a3917828c5f67dfe9c44d0f6b0c5324 moved it in standard website and marked it as to review. It is in fact the cause of a bug: *all* drop areas appeared with a big editor text "Drag and drop a building block here" because of this code. As a fix in stable, this commit solves the code so that it works as intended: adding an editor message on a normal .oe_structure makes it an .oe_structure.oe_empty automatically. In master, this code will simply be removed and it will be up to the devs to not make errors in their xml so that the editor messages appear. Related to task-2210733 Forward-Port-Of: odoo/odoo#48450
### Issue When you send a form which create a customer from the website, you get a 400 error. I used the customer database to reproduce the issue. I guess this is due to specific settings who set a value for `meta` here https://github.com/odoo/odoo/blob/5381e9d900b344e7d48a6b347c5fc551d433b15e/addons/website_form/controllers/main.py#L187 ### Cause The cause is the same than the one for fc8a0474b4 Here, we use sudo: https://github.com/odoo/odoo/blob/5381e9d900b344e7d48a
Original PR description
### Issue When you send a form which create a customer from the website, you get a 400 error. I used the customer database to reproduce the issue. I guess this is due to specific settings who set a…
### Issue When you send a form which create a customer from the website, you get a 400 error. I used the customer database to reproduce the issue. I guess this is due to specific settings who set a value for `meta` here https://github.com/odoo/odoo/blob/5381e9d900b344e7d48a6b347c5fc551d433b15e/addons/website_form/controllers/main.py#L187 ### Cause The cause is the same than the one for fc8a0474b4 Here, we use sudo: https://github.com/odoo/odoo/blob/5381e9d900b344e7d48a6b347c5fc551d433b15e/addons/website_form/controllers/main.py#L211 sudo adds a flag "su" and does not replace the user in env So we have "public user" who doesn't have email instead of OdooBot who has an email, there is a raise who explain the issue but it's not forwarded to the error in the website ### Solution Use with_user(SUPERUSER_ID) instead of sudo, in order to have the right user (as it is done few lines above. **OPW-2220816** -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#48470
### Issue - Install Mass Mailing - Activate debug mode - Create a mass mailing - Select any template - Go in codeview The snippets hide a part of the code ### Cause The snippets container is not hidden when toggling codeview ### Solution Hide it when we toggle the codeview if it exists. This solution could solve other similar case if there are any too. **OPW-2220639** **OPW-2220639** -- I confirm I have signed the CLA and read the PR guidelines at ww
Original PR description
### Issue - Install Mass Mailing - Activate debug mode - Create a mass mailing - Select any template - Go in codeview The snippets hide a part of the code ### Cause The snippets container is not hidden when toggling codeview ### Solution Hide it when we toggle the codeview if it exists. This solution could solve other similar case if there are any too. **OPW-2220639** **OPW-2220639** -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#48073
There is a discrepancy between what country is used to compute the fees for a transaction depending on where we are in the payment flow. At rendering, the country of the order's shipping partner is used (since it is set as the main partner in the rendering values dict through `render_sale_button`). At creation, the country of the partner is used (since the `payment.transaction` record is created with the order's main `partner_id` in `_create_payment_transaction`). This is unfortuna
Original PR description
There is a discrepancy between what country is used to compute the fees for a transaction depending on where we are in the payment flow. At rendering, the country of the order's shipping partner is…
There is a discrepancy between what country is used to compute the fees for a transaction depending on where we are in the payment flow. At rendering, the country of the order's shipping partner is used (since it is set as the main partner in the rendering values dict through `render_sale_button`). At creation, the country of the partner is used (since the `payment.transaction` record is created with the order's main `partner_id` in `_create_payment_transaction`). This is unfortunate and can cause issues with payment flows if there is a mismatch between countries of the shipping/invoice/main partner, as the fees may be computed as 'international' in one case and 'domestic' in another - this causes the values sent to Paypal to differ from those saved on the transaction, which causes the transaction to be rejected upon return from Paypal because of an amount mismatch. Since the transaction is created using the main partner of the order, I believe it is preferrable to use it for the rendering as well. Some may dislike this choice, as it means that if you use these fees to manage your delivery fees, a customer with a shipping address to is not the same as the company's country will pay domestic fees, while they should pay international ones. However, this is mitigated by the fact that: - this did not work before this commit (hell of an argument) - the delivery module is there to handle those cases with much higher configurability - having a consistent computation is more important than managing this case opw-2225023 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#48499
During the recent refactoring, the order reversal of the post messages was dropped by mistake; 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#45817
Original PR description
During the recent refactoring, the order reversal of the post messages was dropped by mistake; 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#45817
We update the hence of the view to take into account the original invisible domain plus the domain we need for journals that use documents Before  After  -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo
Original PR description
We update the hence of the view to take into account the original invisible domain plus the domain we need for journals that use documents Before  After  -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#48113 Forward-Port-Of: odoo/odoo#47962
Bug === Can not copy a `mailing.mailing`. In ffe1d4047da181f97fafe2a69f64e6f283fbeb0e "onchange" were replaced by computed fields. But in 950296f661499f499b0a5776ce7fd91a66c2a63f, they use manually this onchange method in the copy, which is not needed with computed field (bug introduced certainly during a forward port). Task-2226235 Forward-Port-Of: odoo/odoo#48478
Original PR description
Bug === Can not copy a `mailing.mailing`. In ffe1d4047da181f97fafe2a69f64e6f283fbeb0e "onchange" were replaced by computed fields. But in 950296f661499f499b0a5776ce7fd91a66c2a63f, they use manually this onchange method in the copy, which is not needed with computed field (bug introduced certainly during a forward port). Task-2226235 Forward-Port-Of: odoo/odoo#48478
In a planning > schedule by project, with the gantt view, start date is automatically includes in domain. But with other view, start date is not always in domain. Now, we manage the case where the start date is not in domain. Task ID 2222973 Forward-Port-Of: odoo/enterprise#9466
Original PR description
In a planning > schedule by project, with the gantt view, start date is automatically includes in domain. But with other view, start date is not always in domain. Now, we manage the case where the start date is not in domain. Task ID 2222973 Forward-Port-Of: odoo/enterprise#9466
The product prediction could produce a traceback if the content of the description contained special characters such as '%'. Forward-Port-Of: odoo/enterprise#9506
Original PR description
The product prediction could produce a traceback if the content of the description contained special characters such as '%'. Forward-Port-Of: odoo/enterprise#9506
TaskID: 2225737 Forward-Port-Of: odoo/enterprise#9518
Original PR description
TaskID: 2225737 Forward-Port-Of: odoo/enterprise#9518
TaskID: 2225736 Forward-Port-Of: odoo/enterprise#9504
Original PR description
TaskID: 2225736 Forward-Port-Of: odoo/enterprise#9504