Thursday, February 20, 2020
42 changes · master
New functionality added to Odoo
A new automated test verifies that the web interface reloads when a company is created or updated. This helps ensure users always see the correct company context after administrative changes, reducing the risk of stale information in the system.
Original PR description
The purpose of this task is to when a company is created, the web-client is refresh Task-ID: 2188789
Enhancements to existing features
Recruitment applications now keep a history of changes to important fields such as job, department, company, salary expectations, proposed salary, and availability. This improves visibility for HR teams by making it easier to understand how an applicant record evolved over time.
Original PR description
Track following fields:
- job_id
- department_id
- company_id
- salary_proposed
- salary_expected
- availability
TaskID: 2195796
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-prResolved issues and error corrections
This update removes unused selection settings from related fields across several Odoo apps and adds a warning to help prevent the issue from returning. It improves code quality and helps avoid confusing or incorrect field labels without changing core business workflows.
Original PR description
Code cleanup and technical improvements
This update removes unnecessary internal processing when survey pages are prepared for display. It simplifies the survey code path without changing what users see, helping keep the system easier to maintain.
Original PR description
This commit cleans some useless .decode('utf-8') calls when we return rendered
templates results in the survey controllers.
The http module is capable of handling that type of results and the calls were
not necessary / added complexity.
Task '2187328'
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-prMiscellaneous changes
Line return will add a space between icon & text, as it is done for the one just above and the one below. Forward-Port-Of: odoo/odoo#45862
Original PR description
Line return will add a space between icon & text, as it is done for the one just above and the one below. Forward-Port-Of: odoo/odoo#45862
This update clarifies company-related labels in the Time Off module for multi-company setups. It reduces confusion by distinguishing the company grouping mode from the employee's actual company, without changing the underlying business behavior.
Original PR description
Task:https://www.odoo.com/web#id=2168320&action=327&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.2b35e4880768ecb612ff9358ad6ad378 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
When a future driver is applied to a fleet vehicle, the previous driver's history record now receives an end date matching the new driver's start date. This keeps vehicle assignment history complete and avoids unclear or overlapping driver records.
Original PR description
Purpose ======= If you set a future driver and click on "apply change", a new assignation log is automatically created for the new driver. But the end date of the former assignation isn't populate. Specifications ============== Set the date "end date" for the former driver with the "start date" of the new driver. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now warns developers when selection settings are defined on related fields where they have no effect. Several existing field definitions were corrected, reducing hidden configuration mistakes across business apps without changing day-to-day user workflows.
Original PR description
When a field is related, defining a selection or selection_add will have no effect and the paramater is ignored. Log a warning and fix all fields badly definied Closes odoo/odoo#45716
Internal compatibility warnings are now shown only when debug mode is enabled. This reduces unnecessary noise during normal use while keeping diagnostic information available for troubleshooting.
Original PR description
Before this commit ComponentAdapter warned on every update and render. This can make a lot of noises when we use some adpaters. After this commit ComponentAdapter will warn only in debug mode.
This update gives Odoo's web interface more flexibility in how it reacts to user actions such as clicks. It helps developers fine-tune interaction behavior without changing the user experience directly.
Original PR description
Helpful if for example one wants to trigger the capture phase of the event
processing.
e.g.
`useListener('click', 'button', this.onClick, { capture: true })`
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr**Description of the issue/feature this PR addresses:** Some selection fields that are related have an explicit selection attribute that is not being used. Sometimes, those are just strings that don't have the "string=" part. This PR adds a logged warning to avoid this issue. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes error handling behave more consistently between standard web requests and JSON-based requests. It allows custom modules to handle JSON request errors in the same centralized way, reducing unexpected differences without materially changing normal behavior.
Original PR description
The idea is to make the dispatching and error-handling consistent for JsonRequest and HTTPRequest.
In 8809c77 we introduced a way for request-specific error-handling, but JsonRequest.dispatch() was still catching all errors internally, instead of letting them bubble up to ir_http._handle_exception()
By removing the internal try/except in JsonRequest.dispatch(), we do not
change the behavior much as there are only a couple of "ifs" in ir_http._handle_exception() before returning to the request-specific handle_exception. However we give the opportunity to modules to customize exception handling even for JsonRPC, the same way it is possible for HTTP requests.
Here is a simple pseudo code of the flow
```python
ir_http.dispatch():
try:
request.dispatch()
catch Exception as e:
ir_http._handle_exception(e)
```
```python
ir_http.handle_exception(e):
request._handle_exception(e)
```Since Chrome version 80, the V8 javascript engine is using an new pointer compression feature [1]. This features tries to reserve more the 4GiB of memory. As a consequence, during HttpCase tests, odoo tries to launch chrome headless in a subprocess but fails because of the memory-limit-soft. With this commit, the Chrome browser is spawned in a forked process that removes the memory limit. Also: * a new Chrome CLI switch is used to prevent crash reports to be sent to google *
Original PR description
Since Chrome version 80, the V8 javascript engine is using an new pointer compression feature [1]. This features tries to reserve more the 4GiB of memory. As a consequence, during HttpCase tests, odoo tries to launch chrome headless in a subprocess but fails because of the memory-limit-soft. With this commit, the Chrome browser is spawned in a forked process that removes the memory limit. Also: * a new Chrome CLI switch is used to prevent crash reports to be sent to google * a bug that only occurs during Chrome crash is fixed [2] [1] https://v8.dev/blog/v8-release-80 [2] None type object does not have a send method Forward-Port-Of: odoo/odoo#45799 Forward-Port-Of: odoo/odoo#45347
Before this fix, if the user has no PoS access rights, he cannot delete a contact due to a check done on open PoS sessions. Description of the issue/feature this PR addresses: opw-2199860 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#45795
Original PR description
Before this fix, if the user has no PoS access rights, he cannot delete a contact due to a check done on open PoS sessions. Description of the issue/feature this PR addresses: opw-2199860 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#45795
Before this commit, the popup activity in kanban was rendered using the position of the button. So the left popup was nearly in the center of the screen but the width is too large to be contained on the screen. After this commit, in mobile, the popup activity in kanban will be placed on the left of the button to avoid to go outside of the viewport. S
Original PR description
Before this commit, the popup activity in kanban was rendered using the position of the button. So the left popup was nearly in the center of the screen but the width is too large to be contained on the screen. After this commit, in mobile, the popup activity in kanban will be placed on the left of the button to avoid to go outside of the viewport. Steps to reproduce: * Go to sale app (in mobile) * Click on the activity button of a kanban card (clock icon) BUG Task ID: 2198429 Forward-Port-Of: odoo/odoo#45802
The computed field 'session_show_ranking' was only computed based on the fact that the survey had a scoring mechanism. It's not very accurate since we also need a question that saves as the attendee nickname to be able to display a relevant ranking chart. This commit fixes the compute method by adding the necessary condition. Task ID 2188482 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I conf
Original PR description
The computed field 'session_show_ranking' was only computed based on the fact that the survey had a scoring mechanism. It's not very accurate since we also need a question that saves as the attendee nickname to be able to display a relevant ranking chart. This commit fixes the compute method by adding the necessary condition. Task ID 2188482 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#45277
`require_signature`and `require_payment` were visible in debug-mode only for seemingly no reasons, making our sales team having difficulties with our customers payments. Issue introduced by TaskID #2033229. Forward-Port-Of: odoo/odoo#45816
Original PR description
`require_signature`and `require_payment` were visible in debug-mode only for seemingly no reasons, making our sales team having difficulties with our customers payments. Issue introduced by TaskID #2033229. Forward-Port-Of: odoo/odoo#45816
Previously, When we edit a link in website page will be fetched to find the anchor that will result in lots of useless requests. In this commit We have added a delay of 1000 ms to avoid the above issue. PR #45485 task - 2187754 Forward-Port-Of: odoo/odoo#45485
Original PR description
Previously, When we edit a link in website page will be fetched to find the anchor that will result in lots of useless requests. In this commit We have added a delay of 1000 ms to avoid the above issue. PR #45485 task - 2187754 Forward-Port-Of: odoo/odoo#45485
Description of the issue/feature this PR addresses: fix parsing failure for Japanese tax report Current behavior before PR: fail to parse Japanese tax report Desired behavior after PR is merged: success to parse Japanese tax report -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45760
Original PR description
Description of the issue/feature this PR addresses: fix parsing failure for Japanese tax report Current behavior before PR: fail to parse Japanese tax report Desired behavior after PR is merged: success to parse Japanese tax report -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45760
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#45793
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 Forward-Port-Of: odoo/odoo#45793
The compute_all JS-side hasn't be updated since recent changes in the tax computation. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45733
Original PR description
The compute_all JS-side hasn't be updated since recent changes in the tax computation. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45733
- create a SO with a section; - create an invoice from the SO. Before this commit, an SQL constraint was raised : 'Forbidden unit price, account and quantity on non-accountable invoice line'. This error occurs, because the default_get function adds a default account_id to all the lines (including section lines) if a journal_id is passed in the context. The journal_id is added in the context since : 0335311 Now, the default_get function only adds a default account_id if the line is no
Original PR description
- create a SO with a section; - create an invoice from the SO. Before this commit, an SQL constraint was raised : 'Forbidden unit price, account and quantity on non-accountable invoice line'. This error occurs, because the default_get function adds a default account_id to all the lines (including section lines) if a journal_id is passed in the context. The journal_id is added in the context since : 0335311 Now, the default_get function only adds a default account_id if the line is not a section line or a note line. This avoids the SQL constraint to be raised, and the invoice is correctly created. opw-2199356 opw-2199017 opw-2198781 opw-2198650 Forward-Port-Of: odoo/odoo#45774 Forward-Port-Of: odoo/odoo#45684
In case of MTO+Manufacture, a sale order have a count of manufacturing order created from it : 1. create SO with MFG+MTO product with quantity of 5. 2. confirm it. MO will be created for 5 Nos. 3. increase it to 7 . another MO created for 2 Nos. 4. there are 2 MO created based on 1 SO. It was due that new stock move was merge, and the 'created_production_id' info was lost during the merge (keep only the original one). To fix, avoid merging stock move with distinct 'created_productio
Original PR description
In case of MTO+Manufacture, a sale order have a count of manufacturing order created from it : 1. create SO with MFG+MTO product with quantity of 5. 2. confirm it. MO will be created for 5 Nos. 3. increase it to 7 . another MO created for 2 Nos. 4. there are 2 MO created based on 1 SO. It was due that new stock move was merge, and the 'created_production_id' info was lost during the merge (keep only the original one). To fix, avoid merging stock move with distinct 'created_production_id' (done by override '_prepare_merge_moves_distinct_fields' and '_prepare_merge_move_sort_method' methods ). task-2199568 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#45722
Fix bad forward-port of https://github.com/odoo/odoo/commit/e09798098679fa6719cfd9f8e1cac69731387bd9 made in https://github.com/odoo/odoo/commit/51d49517a8b5af2d1c85d9c620e45a0941cdc6b4 Original commit message was: [FIX] account: fix bank account requirement on account.payment form When making a payment for multiple vendor bills at once, it is possible that payments will be generated without any recipient bank account for payment methods normally requiring one. In such cases, the u
Original PR description
Fix bad forward-port of https://github.com/odoo/odoo/commit/e09798098679fa6719cfd9f8e1cac69731387bd9 made in https://github.com/odoo/odoo/commit/51d49517a8b5af2d1c85d9c620e45a0941cdc6b4 Original commit message was: [FIX] account: fix bank account requirement on account.payment form When making a payment for multiple vendor bills at once, it is possible that payments will be generated without any recipient bank account for payment methods normally requiring one. In such cases, the user needs to be able to correct the payments by cancelling them. It was not possible. Forward-Port-Of: odoo/odoo#45676
The product demo file marks a lot of product as 'invoice on delivery' (the default is invoice on order), but the invoice status and amount to invoice on order lines is _not_ recomputed when the product's invoice policy changes (this is a conscious choice, as it would trigger recomputation on past orders). This means that the demo for products must be loaded _before_ the orders demo, otherwise the computation for what is to invoice or not will seem to make no sense on a demo db (even tho
Original PR description
The product demo file marks a lot of product as 'invoice on delivery' (the default is invoice on order), but the invoice status and amount to invoice on order lines is _not_ recomputed when the product's invoice policy changes (this is a conscious choice, as it would trigger recomputation on past orders). This means that the demo for products must be loaded _before_ the orders demo, otherwise the computation for what is to invoice or not will seem to make no sense on a demo db (even though the computation is in fact correct): a lot of orders where marked as 'to invoice' while the products where not delivered; invoice those and the system will again mark them as 'to invoice' and will immediately want to generate a refund... Forward-Port-Of: odoo/odoo#45753
### Issue - Install Sale and/or Purchase - Create new order - Debugger > Set Defaults - Set default value for payment terms - Quit and re-create Default value is not filled ### Cause The default value is set but it's overridden by a onchange ### Solution Remove the override who puts the value to False **OPW-2197940** -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45727
Original PR description
### Issue - Install Sale and/or Purchase - Create new order - Debugger > Set Defaults - Set default value for payment terms - Quit and re-create Default value is not filled ### Cause The default value is set but it's overridden by a onchange ### Solution Remove the override who puts the value to False **OPW-2197940** -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45727