Friday, January 3, 2020
33 changes · master
Enhancements to existing features
This change improves how Odoo reports calculation errors by preserving the original error type, making issues easier to identify and handle. It also makes account ordering more consistent across companies, helping financial report tests and related behavior stay predictable.
Original PR description
For example, if a division by zero occurs, I expect a ZeroDivisionError insteaf of a TypeError to ease the catching of such errors. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves the wording used to describe HR department records. It helps make employee and department information easier to understand in the HR app, with no expected change to daily workflows.
Original PR description
Description of the issue/feature this PR addresses: Fixes https://github.com/odoo/odoo/issues/42559 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 update removes an unused internal method from the Mail module. It has no expected impact on day-to-day users, but helps keep the codebase simpler and easier to maintain.
Original PR description
Method '_channel_fetch_listeners_where_clause' is not used anywhere, So we can remove this. 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
Financial reports load faster and are easier to use, especially when grouping data or expanding report lines. The update also streamlines report calculations, supports more flexible headers, and adds a debug information popup for troubleshooting.
Original PR description
- Fix the groupby feature allowing some horizontal groupby & make it usable by the user. - Improve performances. - Simplify the formulas. - Add a debug info popup. - Allow having multiple headers lines in a more generic way(adapt the trial balance) + remove _get_super_column method.
Confirmed rental orders will no longer be labeled as reserved when stock may not actually be available for the requested rental period. This reduces confusion for sales and operations teams by making order status better reflect real availability.
Original PR description
The confirmed rental order are not guaranteed to be reserved because we allow user to confirm rental order when the stock isn't available for the product on requested period.
Resolved issues and error corrections
This updates the documentation for a core grouping feature to correctly state that sorting instructions should be provided as text. It helps developers avoid mistakes that could cause reporting or grouped data queries to fail.
Original PR description
Description of the issue/feature this PR addresses: The param "orderby" of the read_group should be str -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Previously, the code of the IoT Box was retrieved from the branch that was used during the build but the drivers were retrieved from the connected Odoo DB. Both could be in different versions, which forced used to make old drivers compatible with the new Box or new drivers compatible with old versions of the Box. All of this made it quite hard to modify the existing code, even for new versions of the Box in master. When connecting the IoT Box to an Odoo DB, we now retrieve the version
Original PR description
Previously, the code of the IoT Box was retrieved from the branch that was used during the build but the drivers were retrieved from the connected Odoo DB. Both could be in different versions, which forced used to make old drivers compatible with the new Box or new drivers compatible with old versions of the Box. All of this made it quite hard to modify the existing code, even for new versions of the Box in master. When connecting the IoT Box to an Odoo DB, we now retrieve the version of Odoo that is used and checkout the Box to this branch. This means that we can now modify the code of the Box in master without having to worry about users using the latest build with older DBs. TaskID: 2120749 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#40251
This fixes a small visual issue where some fields in invoice, sales order, and delivery forms showed doubled right borders. The change makes these forms look cleaner and more consistent, improving day-to-day usability without changing business behavior.
Original PR description
**account.move.form, sale.order.form,stock.picking.form: minor ux fix** Description of the issue/feature this PR addresses: - Field partner_id and invoice_date in form view account.move.form, - Field date_order in form view sale.order.form, - and Field partner_id in form view stock.picking.form have doubled right borders. FW from #42427 because no view update allowed for stable version -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Steps to reproduce the bug: - Creante a vendor V with a lang in French - Set lang English on your user U - Log with U - Create a lunch.order.line for V - Click on Lunch: Order meals Bug: The email was sent in the lang of U instead of V. opw:2155628 Forward-Port-Of: odoo/odoo#42536
Original PR description
Steps to reproduce the bug: - Creante a vendor V with a lang in French - Set lang English on your user U - Log with U - Create a lunch.order.line for V - Click on Lunch: Order meals Bug: The email was sent in the lang of U instead of V. opw:2155628 Forward-Port-Of: odoo/odoo#42536
Steps to reproduce the bug: - Let's consider the current user U logged in company C - Let's consider two operation types OT1 and OT2 with code = 'incoming' and warehouse_id.company_id = C - Let's define OT2 as default value for field picking_type_id in model 'purchase.order' - Try to create a new RFQ Bug: The default picking_type_id was OT1 instead of OT2 opw:2124083 Forward-Port-Of: odoo/odoo#41614
Original PR description
Steps to reproduce the bug: - Let's consider the current user U logged in company C - Let's consider two operation types OT1 and OT2 with code = 'incoming' and warehouse_id.company_id = C - Let's define OT2 as default value for field picking_type_id in model 'purchase.order' - Try to create a new RFQ Bug: The default picking_type_id was OT1 instead of OT2 opw:2124083 Forward-Port-Of: odoo/odoo#41614
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42684
Original PR description
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42684
Before this commit, trying to put a transaction in a state where it was already in was causing an error. For example: Putting a transaction in'Done' when it was already in'Done' caused an error 'Only draft/authorized transaction can be posted.' Now, we just log a note that the transaction is already in the required state and pass over. Forward-Port-Of: odoo/odoo#41389 Forward-Port-Of: odoo/odoo#39370
Original PR description
Before this commit, trying to put a transaction in a state where it was already in was causing an error. For example: Putting a transaction in'Done' when it was already in'Done' caused an error 'Only draft/authorized transaction can be posted.' Now, we just log a note that the transaction is already in the required state and pass over. Forward-Port-Of: odoo/odoo#41389 Forward-Port-Of: odoo/odoo#39370
Onchanges can be triggered after computes and therefore, we could have a line with an uom but without product, leading to a conversion from "no uom" to the order line uom, which isn't accepted. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42673
Original PR description
Onchanges can be triggered after computes and therefore, we could have a line with an uom but without product, leading to a conversion from "no uom" to the order line uom, which isn't accepted. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42673
Issue - Install Employee - Configuration > Plans - Open one of them - Activities > Quick edit activity type The description field is too small. Cause Width divided by 2 because of it's in a group Solution Put it off the group OPW-2158138 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42571
Original PR description
Issue
- Install Employee
- Configuration > Plans
- Open one of them
- Activities > Quick edit activity type
The description field is too small.
Cause
Width divided by 2 because of it's in a group
Solution
Put it off the group
OPW-2158138
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#42571Steps to reproduce: -install purchase -install inventory -go to purchase > control > incomig products -activate kanban view and group by picking Previous behavior: clicking create allows for quick creation and all cards are draggable, which creates inconsistency on the moves Current behavior: quick creation is not allowed and kanban cards are not draggable opw-2165106 closes https://github.com/odoo/odoo/issues/36043 Forward-Port-Of: odoo/odoo#42531
Original PR description
Steps to reproduce: -install purchase -install inventory -go to purchase > control > incomig products -activate kanban view and group by picking Previous behavior: clicking create allows for quick creation and all cards are draggable, which creates inconsistency on the moves Current behavior: quick creation is not allowed and kanban cards are not draggable opw-2165106 closes https://github.com/odoo/odoo/issues/36043 Forward-Port-Of: odoo/odoo#42531
Rev. bc131c0cfb51 aimed to handle the case of several (conditional and exclusive) <label> tags for a same field. The idea was to wrap those <label> tags into a div with className 'o_td_label' (typically set by the framework), and let the framework move it to the td wrapping the div. However, it causes an css issue (only in community), as the presence of two o_td_label classnames (one on the td, and one on the div), produces two right borders. This commit fixes the issue by removing t
Original PR description
Rev. bc131c0cfb51 aimed to handle the case of several (conditional and exclusive) <label> tags for a same field. The idea was to wrap those <label> tags into a div with className 'o_td_label' (typically set by the framework), and let the framework move it to the td wrapping the div. However, it causes an css issue (only in community), as the presence of two o_td_label classnames (one on the td, and one on the div), produces two right borders. This commit fixes the issue by removing the classname on the div (we simply 'transfer' it to the td). Closes #42589 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#42612
Before this commit, the corrected test crashed when the current date was before the arbitrary dates of the test because the wrong exchange rate was taken After this commit, the test passes 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#42657 Forward-Port-Of: odoo/odoo#42603
Original PR description
Before this commit, the corrected test crashed when the current date was before the arbitrary dates of the test because the wrong exchange rate was taken After this commit, the test passes 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#42657 Forward-Port-Of: odoo/odoo#42603
Issue - Install Employee - Settings > Enable skills management - Go on employee form view - In languages, click on add - Quick create a skill & save - Save the form ValidationError "The skill %s and skill type %s doesn't match" Cause You should not quick create a skill, you should edit the skill type, add your skill and then select it. Solution Disabling skill quick create because it's misleading OPW-2163059 -- I confirm I ha
Original PR description
Issue
- Install Employee
- Settings > Enable skills management
- Go on employee form view
- In languages, click on add
- Quick create a skill & save
- Save the form
ValidationError "The skill %s and skill type %s doesn't match"
Cause
You should not quick create a skill, you should edit the skill
type, add your skill and then select it.
Solution
Disabling skill quick create because it's misleading
OPW-2163059
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#42525Steps to reproduce: -install accounting -go to accounting > accounting > assets -create a deprecable asset (account moves for deprecations are set automatically) -change your user's language to blank -try to post one of the automatically created deprecations line Previous behavior: you get a traceback error "TypeError: strftime() argument 1 must be str, not bool" Current behavior: you get the intended error message opw-2162318 Forward-Port-Of: odoo/odoo#42409
Original PR description
Steps to reproduce: -install accounting -go to accounting > accounting > assets -create a deprecable asset (account moves for deprecations are set automatically) -change your user's language to blank -try to post one of the automatically created deprecations line Previous behavior: you get a traceback error "TypeError: strftime() argument 1 must be str, not bool" Current behavior: you get the intended error message opw-2162318 Forward-Port-Of: odoo/odoo#42409
Steps to reproduce: -install base_automation and contacts -go to settings > technical > automated actions -create an automated action on new contact creation -set your action to "create next activity" -leave the activity due type to blank -trigger the automated action by creating a new contact Previous behavior: you get a traceback error "TypeError: __init__() keywords must be strings" Current behavior: the field is required and does not allow a blank type opw-2159755 Forward-
Original PR description
Steps to reproduce: -install base_automation and contacts -go to settings > technical > automated actions -create an automated action on new contact creation -set your action to "create next activity" -leave the activity due type to blank -trigger the automated action by creating a new contact Previous behavior: you get a traceback error "TypeError: __init__() keywords must be strings" Current behavior: the field is required and does not allow a blank type opw-2159755 Forward-Port-Of: odoo/odoo#42412
Follow up on https://github.com/odoo/odoo/commit/6e5b211f4efd2f29b8bf582465284527e38bc763 Certificate field is not sufficient, scoring type should be set by default to avoid creating non certificates without knowing it. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: Cc: @tde-banana-odoo (I have copied commit message too :wink: ) -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/
Original PR description
Follow up on https://github.com/odoo/odoo/commit/6e5b211f4efd2f29b8bf582465284527e38bc763 Certificate field is not sufficient, scoring type should be set by default to avoid creating non certificates without knowing it. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: Cc: @tde-banana-odoo (I have copied commit message too :wink: ) -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42366
This commit fixes 9ac5f42cd0c381bdddfd196721983057bab7028b by correctly calling the probabilities computation method. It was a backport of a master fix and methods names are slightly different. 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#42573
Original PR description
This commit fixes 9ac5f42cd0c381bdddfd196721983057bab7028b by correctly calling the probabilities computation method. It was a backport of a master fix and methods names are slightly different. 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#42573
Description of the issue/feature this PR addresses: Add translation to the title of rename conversation dialog Current behavior before PR: The title of rename conversation dialog always display in englist. Desired behavior after PR is merged: The title of rename conversation dialog can be display in the configured language -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42428
Original PR description
Description of the issue/feature this PR addresses: Add translation to the title of rename conversation dialog Current behavior before PR: The title of rename conversation dialog always display in englist. Desired behavior after PR is merged: The title of rename conversation dialog can be display in the configured language -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42428
For performance reasons, the company_id of a lunch supplier is now stored. In a multi-company environment, the multi-company ir.rule was loading *all* the suppliers in order to check their related company_id. TaskID: 2152319 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#41616
Original PR description
For performance reasons, the company_id of a lunch supplier is now stored. In a multi-company environment, the multi-company ir.rule was loading *all* the suppliers in order to check their related company_id. TaskID: 2152319 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#41616
Description of the issue/feature this PR addresses: If the user doesn't have enough access rights to write on the `res.company` model, some workflows like _sending your first sale order by email_ will fail https://github.com/odoo/odoo/blob/13.0/addons/sale/models/sale.py#L704  Current behavior before PR: It's on the description Desired behavior after PR is merged:
Original PR description
Description of the issue/feature this PR addresses: If the user doesn't have enough access rights to write on the `res.company` model, some workflows like _sending your first sale order by email_ will fail https://github.com/odoo/odoo/blob/13.0/addons/sale/models/sale.py#L704  Current behavior before PR: It's on the description 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#42199
Task : https://www.odoo.com/web?#id=2117251&action=327&model=project.task&view_type=form&menu_id=4720 Pad : https://pad.odoo.com/p/openerp-project.task-L1UGO6T39Z Forward-Port-Of: odoo/enterprise#6641
Original PR description
Task : https://www.odoo.com/web?#id=2117251&action=327&model=project.task&view_type=form&menu_id=4720 Pad : https://pad.odoo.com/p/openerp-project.task-L1UGO6T39Z Forward-Port-Of: odoo/enterprise#6641
Purpose ======= - An employee without any access to Employees,Contracts and Sign should have access to its own documents - An Employee Officer without access to Contracts should have access to an employee form view. - An Employee Officer with Employee Sign accesses should have access to the signed documents he requested. TaskID: 2147953 Forward-Port-Of: odoo/enterprise#7149
Original PR description
Purpose ======= - An employee without any access to Employees,Contracts and Sign should have access to its own documents - An Employee Officer without access to Contracts should have access to an employee form view. - An Employee Officer with Employee Sign accesses should have access to the signed documents he requested. TaskID: 2147953 Forward-Port-Of: odoo/enterprise#7149
- Create customer / supplier invoice. - Pay the invoice. - Go to the payment, press the `reset to draft` button. - Press the `cancel` button. - Press the `reset to draft` button. In this case, a `expected singleton` traceback is obtained. [Video](https://youtu.be/o6AoAtzICAw) This change fix that. Forward-Port-Of: odoo/enterprise#7506
Original PR description
- Create customer / supplier invoice. - Pay the invoice. - Go to the payment, press the `reset to draft` button. - Press the `cancel` button. - Press the `reset to draft` button. In this case, a `expected singleton` traceback is obtained. [Video](https://youtu.be/o6AoAtzICAw) This change fix that. Forward-Port-Of: odoo/enterprise#7506
When opening another financial report by clicking on a financial report line (e.g. opening the P&L from the Balance Sheet using Current Year Earnings), don't pop the filter. Then, _init_filter_date will be able to create the new options properly according the previous used filter. Before this commit, the P&L was always opened using the 'this_year' default filter. After this commit, the P&L copies the BS's filter to keep consistency between them. Forward-Port-Of: odoo/enterprise#7510
Original PR description
When opening another financial report by clicking on a financial report line (e.g. opening the P&L from the Balance Sheet using Current Year Earnings), don't pop the filter. Then, _init_filter_date will be able to create the new options properly according the previous used filter. Before this commit, the P&L was always opened using the 'this_year' default filter. After this commit, the P&L copies the BS's filter to keep consistency between them. Forward-Port-Of: odoo/enterprise#7510
manual forward-port of https://github.com/odoo/odoo/commit/5512532820cc7bf84af3bae0ee46f5ca908fc43a Forward-Port-Of: odoo/enterprise#7511
Original PR description
manual forward-port of https://github.com/odoo/odoo/commit/5512532820cc7bf84af3bae0ee46f5ca908fc43a Forward-Port-Of: odoo/enterprise#7511
Forward-Port-Of: odoo/enterprise#7489 Forward-Port-Of: odoo/enterprise#7482
Original PR description
Forward-Port-Of: odoo/enterprise#7489 Forward-Port-Of: odoo/enterprise#7482
Related to https://github.com/odoo/odoo/pull/42199 Forward-Port-Of: odoo/enterprise#7437
Original PR description
Related to https://github.com/odoo/odoo/pull/42199 Forward-Port-Of: odoo/enterprise#7437
Issue - Have 2 company - Install Sales - General settings The field "Assign to" is required in the company form but not in the general settings. Cause Missing `required=True` Solution Adding it OPW-2162496 Forward-Port-Of: odoo/enterprise#7490
Original PR description
Issue
- Have 2 company
- Install Sales
- General settings
The field "Assign to" is required in the company form but
not in the general settings.
Cause
Missing `required=True`
Solution
Adding it
OPW-2162496
Forward-Port-Of: odoo/enterprise#7490