Thursday, August 27, 2020
21 changes · master
Enhancements to existing features
Odoo no longer shows an extra internal warning when certain database items are removed during upgrades. This avoids duplicate messages because upgrade scripts now perform their own checks, making upgrade feedback cleaner and less confusing.
Original PR description
Upgrade scripts are now doing custom check on view/field/model unlink. This check can be removed from odoo.
Resolved issues and error corrections
This fix keeps product availability information visible on rental sales order lines after a related platform widget changed. It helps rental teams continue checking whether items are available when preparing orders.
Original PR description
The `qty_at_date_widget` has been replace in community, make some change to keep the feature of avaibility in renting app. task-2324039
Miscellaneous changes
If there is no `date_end`, sorting will crash. opw-2326262 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#56557
Original PR description
If there is no `date_end`, sorting will crash. opw-2326262 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#56557
task-2282334 upgrade: odoo/upgrade#1700 original PR: https://github.com/odoo/odoo/pull/55238 Forward-Port-Of: odoo/odoo#56584
Original PR description
task-2282334 upgrade: odoo/upgrade#1700 original PR: https://github.com/odoo/odoo/pull/55238 Forward-Port-Of: odoo/odoo#56584
Before this commit, `stock.warehouse.orderpoint` `_compute_qty` didn't depend on `purchase.order.line` (POL). This means when a relevant POL was edited/cancelled, then the `qty_forecast` wouldn't correctly update. To reproduce: - Create a product w/ a vendor and buy route active, - Go to replenishment report and hit order for product (RFQ should be created) - Cancel the RFQ and go back to replenishment report The product should reappear in the list view, but does not because it's
Original PR description
Before this commit, `stock.warehouse.orderpoint` `_compute_qty` didn't depend on `purchase.order.line` (POL). This means when a relevant POL was edited/cancelled, then the `qty_forecast` wouldn't correctly update. To reproduce: - Create a product w/ a vendor and buy route active, - Go to replenishment report and hit order for product (RFQ should be created) - Cancel the RFQ and go back to replenishment report The product should reappear in the list view, but does not because it's `qty_forecast` has not updated and therefore has not updated corresponding `qty_to_order` value. Note string rename of `purchase_line_warn` 'Purchase Order Line' => 'Purchase Order Line Warning' is due to repeat label use issue. It is better to rename the poorly labeled `purchase_line_warn` than to give a hacky label for new One2many field. Task: 2285912 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#56580
Doesn't seem used since it's been broken forever on python 3: base64.b64encode returns binary data, on which json.dumps chokes. Still, removing the endpoint on old stables seems a bit brutal so just fix it. Forward-Port-Of: odoo/odoo#56622
Original PR description
Doesn't seem used since it's been broken forever on python 3: base64.b64encode returns binary data, on which json.dumps chokes. Still, removing the endpoint on old stables seems a bit brutal so just fix it. Forward-Port-Of: odoo/odoo#56622
Steps to reproduce the bug: - Let's consider a user U linked to an employee E - U has no right in Project and he is timesheet user - Let's consier a leave type LT generating timesheets - LT is linked to Internal Project IP and Internal Task for timesheet ITT - IP has privacy "on invitation only" - U makes leave request LR for leave of type LT - His manager approves LR - U goes to My timesheets list view and select the timesheet generated by the approval of LR - U prints Timesheet Entr
Original PR description
Steps to reproduce the bug: - Let's consider a user U linked to an employee E - U has no right in Project and he is timesheet user - Let's consier a leave type LT generating timesheets - LT is linked to Internal Project IP and Internal Task for timesheet ITT - IP has privacy "on invitation only" - U makes leave request LR for leave of type LT - His manager approves LR - U goes to My timesheets list view and select the timesheet generated by the approval of LR - U prints Timesheet Entries Bug: An access rights error was raised. opw:2321040 Forward-Port-Of: odoo/odoo#56552 Forward-Port-Of: odoo/odoo#56528
Forward-Port-Of: odoo/odoo#56630
Original PR description
Forward-Port-Of: odoo/odoo#56630
when creating the first bank statement on a journal. It will trigger manual field recomputations: https://github.com/odoo/odoo/blob/d19477f982e046ba563ce18706f0eab2b250738d/addons/account/models/account_bank_statement.py#L288-L297 previous_statement_id will correctly be False The manual recomputation in create will recalculate all bank statements that have a False previous_statement_id. These bank statements are usually the first ones in a journal. When they get recomputed it triggers r
Original PR description
when creating the first bank statement on a journal. It will trigger manual field recomputations: https://github.com/odoo/odoo/blob/d19477f982e046ba563ce18706f0eab2b250738d/addons/account/models/account_bank_statement.py#L288-L297 previous_statement_id will correctly be False The manual recomputation in create will recalculate all bank statements that have a False previous_statement_id. These bank statements are usually the first ones in a journal. When they get recomputed it triggers recomputations for every bank statement that follows it. This commit try to limit this behavior by recomputing statements only in the same journal opw-2311173 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#56472
Specifications Current: The Admin has the ability to manually create new visitors. To Be: Users shouldn't be able to manually create visitors at all. Only the system does when people browse the website. LINKS: PR: #53934 Task-id: 2288363 Forward-Port-Of: odoo/odoo#53934
Original PR description
Specifications Current: The Admin has the ability to manually create new visitors. To Be: Users shouldn't be able to manually create visitors at all. Only the system does when people browse the website. LINKS: PR: #53934 Task-id: 2288363 Forward-Port-Of: odoo/odoo#53934
A few changes in the demo data to makes things more practical and/or more constant. Also, don't forget... Demo Data is love, Demo Data is life. Forward-Port-Of: odoo/odoo#55502
Original PR description
A few changes in the demo data to makes things more practical and/or more constant. Also, don't forget... Demo Data is love, Demo Data is life. Forward-Port-Of: odoo/odoo#55502
- Create a Contact named "Alpha" - Create another Contact named "Mister X" with "misterx@alpha.com" as email - Go to CRM and create an Opportunity for Mister X - Go to Contacts and open Alpha The Opportunities smart button shows 0, but when clicking on it, Mister X's Opportunity is displayed. The Opportunity smart button displays a "crm.lead" view with a filter on partner_id. The filter applies an "ilike" with the Contact's name on several fields of "crm.lead", including "email_from".
Original PR description
- Create a Contact named "Alpha" - Create another Contact named "Mister X" with "misterx@alpha.com" as email - Go to CRM and create an Opportunity for Mister X - Go to Contacts and open Alpha The Opportunities smart button shows 0, but when clicking on it, Mister X's Opportunity is displayed. The Opportunity smart button displays a "crm.lead" view with a filter on partner_id. The filter applies an "ilike" with the Contact's name on several fields of "crm.lead", including "email_from". As Mister X's email address contains Alpha's name, its opportunity is wrongly retrieved. opw-2320299 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#56627 Forward-Port-Of: odoo/odoo#56559
opw-2320456 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#56199
Original PR description
opw-2320456 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#56199
- flush must be done before executing queries - when the current partner is given, it shouldn't be checked twice - when a channel includes the given partners but also has more partners, it shouldn't be returned - query can be limited to 1 result, minor performance gain in the rare case where more than one canonical channel exists task-2324119 Note: diff best viewed with whitespace off due to changed indent Forward-Port-Of: odoo/odoo#56284
Original PR description
- flush must be done before executing queries - when the current partner is given, it shouldn't be checked twice - when a channel includes the given partners but also has more partners, it shouldn't be returned - query can be limited to 1 result, minor performance gain in the rare case where more than one canonical channel exists task-2324119 Note: diff best viewed with whitespace off due to changed indent Forward-Port-Of: odoo/odoo#56284
Before this commit, on page reload, sometimes web client crashed with `Cannot read 'messagingMenu' of undefined`. This happens due to messaging components making use of `messaging` in `env` as if it was always set. In some rare cases, this is false, hence the crash. This happens on root components of messaging such as the messaging menu. Creation of `env.messaging` has to be async, in other to ensure all JS module that patches messaging are applied. The mounting of messaging root com
Original PR description
Before this commit, on page reload, sometimes web client crashed with `Cannot read 'messagingMenu' of undefined`. This happens due to messaging components making use of `messaging` in `env` as if it was always set. In some rare cases, this is false, hence the crash. This happens on root components of messaging such as the messaging menu. Creation of `env.messaging` has to be async, in other to ensure all JS module that patches messaging are applied. The mounting of messaging root components depends on other parts of the web client like the SystrayMenu. So the proper fix is to guard `env.messaging` on these root components. Task-2238245 Forward-Port-Of: odoo/odoo#56120
This commit adds a website-specific and customizable app name for the Events' Progressive Web Application, configurable through the website's settings. Defaults to '<website_name> Events'. Forward-Port-Of: odoo/odoo#56542 Forward-Port-Of: odoo/odoo#56532
Original PR description
This commit adds a website-specific and customizable app name for the Events' Progressive Web Application, configurable through the website's settings. Defaults to '<website_name> Events'. Forward-Port-Of: odoo/odoo#56542 Forward-Port-Of: odoo/odoo#56532
task-2280184 Forward-Port-Of: odoo/odoo#55607
Original PR description
task-2280184 Forward-Port-Of: odoo/odoo#55607
A deprecated account should not be selectable by the user when creating a new move. Related issue: https://github.com/odoo/odoo/issues/56586 Forward-Port-Of: odoo/odoo#56676
Original PR description
A deprecated account should not be selectable by the user when creating a new move. Related issue: https://github.com/odoo/odoo/issues/56586 Forward-Port-Of: odoo/odoo#56676
apply given solution and add res_config_settings file in l10n_be_hr_contract_salary Forward-Port-Of: odoo/enterprise#12612 Forward-Port-Of: odoo/enterprise#12482
Original PR description
apply given solution and add res_config_settings file in l10n_be_hr_contract_salary Forward-Port-Of: odoo/enterprise#12612 Forward-Port-Of: odoo/enterprise#12482
Forward-Port-Of: odoo/enterprise#12723
Original PR description
Forward-Port-Of: odoo/enterprise#12723
Forward-Port-Of: odoo/enterprise#12722
Original PR description
Forward-Port-Of: odoo/enterprise#12722