Friday, March 27, 2020
32 changes · master
Security fixes and vulnerability patches
This update removes duplicate access rules across several Odoo apps and corrects a recruitment permission so only the right managers can edit recruitment stages. This makes permissions easier to understand and reduces the risk of unintended access behavior.
Original PR description
First PR of ACL cleanup, removing duplicate rules, targeting same model/group in same csv file, making one of the two rules useless. [Task ID - 2207847](https://www.odoo.com/web#id=2207847&action=333&active_id=2818&model=project.task&view_type=form&cids=1&menu_id=4720)
New functionality added to Odoo
Invoice users can now preview the currency exchange rate that will be applied before validation and adjust it when needed. This helps businesses record vendor and customer invoices with the exact agreed or required rate, while keeping the used rate visible for later review.
Original PR description
Description of the issue/feature this PR addresses: Allow to use different rates than the one in odoo when encoding invoices Current behavior before PR: When encoding vendor/customer invoices, you're…
Description of the issue/feature this PR addresses: Allow to use different rates than the one in odoo when encoding invoices Current behavior before PR: When encoding vendor/customer invoices, you're not able to use a different rate than the one on odoo. You neither know the rate after/before invoice validation Desired behavior after PR is merged: The improvements after this PR are: 1. User can preview the rate that's going to be used before validating the invoice 2. User can modify the rate before validating invoice 3. You can have information regarding the rate used on an invoice (getting this value calculating aml.balance / aml.currency_amount or similar is not accurate) Check [this demo video](https://drive.google.com/file/d/1J28gaUpaCKU1lSsZh4s4w9Wgxema8DsQ/view) Some remarks: 1. there is an error when changing the rate that creates a new line. This error is already there in odoo and is not related to this PR. Check [this issue](https://github.com/odoo/odoo/issues/35198) 2. This behavior could be optional by some setting like to enable on purchase and or sales -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
Users with elevated access can now switch back to normal user mode directly from the web interface. This makes temporary admin work safer and more convenient by reducing the chance of staying in powerful superuser mode longer than needed.
Original PR description
Description of the issue/feature this PR addresses: `web` module, Follow Up on https://github.com/odoo/odoo/issues/27402 Current behavior before PR: No Option to Leave `Superuser` mode and add Become normal user again Desired behavior after PR is merged:  -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
The accounting accrual wizard now shows users a preview of the journal entries it will create before they proceed. Accrual processing is also changed to avoid modifying already posted entries, creating separate journal entries instead for a clearer and more audit-friendly accounting flow.
Original PR description
Task [2168064](https://www.odoo.com/web?#id=2168064&action=333&active_id=967&model=project.task&view_type=form&cids=1&menu_id=4720) [IMP] account: preview in accrual wizard Show a preview of what will be done when using the accrual wizard [IMP] account: accrual never change account on the fly Before this commit, the account on the original line was replaced by the accrual account. This could be problematic for hashed journals. Instead of having 2 different behaviors for hashed/non hashed journals, we decided to always create 2 journal entries, which is also more academic: * We don't replace something on an entry that has been posted * We don't end up with taxes on the accrual account * Accountants are used to do it this way -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
Website guidance tours can now be assigned an order so they start predictably instead of randomly. This improves consistency for users following onboarding or feature walkthroughs, with initial sequencing added for project-related tours.
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 Enterprise: https://github.com/odoo/enterprise/pull/9472 Closes https://github.com/odoo/odoo/issues/33405
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
This update adds support for area units, filling a gap where Odoo already supported length and volume measurements. Businesses can now manage products, pricing, or operations that rely on square measurements more consistently.
Original PR description
We have leng (m), volume (m^3), but not area (m²). @nim-odoo -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change lets businesses mark certain accounts so they are left out of tax closing entries. It helps produce more accurate tax closing results when some deductible or non-deductible amounts should not be included.
Original PR description
Description of the issue/feature this PR addresses: Some account should not taken into account during the tax closing entry (We should be able to exclude some account When there is dudictible vs non-deductibe part) Current behavior before PR: All accounts are taken into account during the tax closing entry Desired behavior after PR is merged: if an account is marked as 'is_tax_closing_entry', it is excluded from tax closing entry -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Accounting teams can now exclude selected tax repartition lines from tax closing entries. This helps ensure tax closing calculations match specific reporting or compliance needs without manual workarounds.
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
Financial reports now show the Hierarchy and Subtotals option automatically when account groups exist for the selected company, instead of requiring manual setup per report. This makes reports clearer when grouping is available and avoids showing hierarchy controls when they cannot be used.
Original PR description
Task [2065440](https://www.odoo.com/web#id=2065440&action=333&active_id=967&model=project.task&view_type=form&menu_id=4720) PURPOSE ========= To have to choose financial report by financial report if…
Task [2065440](https://www.odoo.com/web#id=2065440&action=333&active_id=967&model=project.task&view_type=form&menu_id=4720)
PURPOSE
=========
To have to choose financial report by financial report if we want or not the Hierarchy and Subtotals option is casse pied.
We want a smarter way to display a hierarchy in financial reports, when it's needed..
SPECIFICATIONS
===============
* Remove "Enable the hierarchy option" (field hierarchy_option) from account.financial.html.reports http://tinyurl.com/yxr4xk4e
* Always display the Hierarchy and Subtotals option for financial reports if there are account groups http://tinyurl.com/y4ybr25j
* The only way to have a Hierarchy is to create account groups
* If there isn't account groups for the selected company, hide the option (as we can't get hierarchy without account groups)
* Remove the "not so smart automatic Hierarchy and Subtotals structure" for the accounts which are not mapped to an account group
* Instead display a hierarchy when there are groups, otherwise display accounts without hierarchyMy Shifts now shows open shifts that match the user's default planning roles. If a user has no default planning roles, they will continue to see all open shifts, making shift discovery more relevant without reducing visibility for unconfigured users.
Original PR description
On "My Shifts", show the Open Shifts matching the default planning roles of the current user, or all if they don't have a default planning roles. TaskID: 2212344
Fixes several small issues in Odoo Surveys that affected live sessions, free text sections, leaderboards, answer chart highlighting, conditional navigation, and back button behavior. This makes survey participation and hosting more reliable, avoids duplicate leaderboard results, and prevents users from seeing empty or invalid pages.
Original PR description
PURPOSE After the latest developments on survey, notable sessions and "free text questions", a few minor bugs have been introduced. SPECIFICATIONS General specifications, see sub-commits for details: - When showing correct/incorrect answers on bar charts, the correct answers bars should not be faded out. - When going from the Leaderboard to the "Final Leaderboard", it should not duplicate the results. - Correctly handle "free text sections" in survey sessions. - Exclude pages that have no description in 'page_per_question' layout - Correctly navigate through survey with conditional questions activated - Fix minor issues with the "back" button on survey - Skip section with no active questions (when conditional questions configured) Task 2208574
This fix stops user groups from being deleted when they are still linked to access rules. It prevents accidental permission changes that could make rules apply too broadly and disrupt what users can see or do.
Original PR description
**Description of the issue/feature this PR addresses:** With a wrong manipulation you can unlink a group. During unlink - the `ir.model.access` is also unlink, - `ir.rule` are not unlink and become global **Current behavior before PR:** Go to runbot. Unlink Portal groups --> all Portal `ir.rule` become global --> there are lot of issue with access (you don't see all records). **Desired behavior after PR is merged:** You cannot unlink a group if it is used. @odony -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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