Monday, September 7, 2020
26 changes · master
Enhancements to existing features
Manufacturing orders now trigger automatic replenishment rules when components are unavailable during availability checks, including subcontracting flows. This reduces manual scheduler runs and helps teams reserve materials or feed downstream demand more quickly after production is completed.
Original PR description
Description of the issue/feature this PR addresses: A feature was added into `stock.picking` to look for and trigger automatic reordering rules for products not in stock when "Check Availability" is…
Description of the issue/feature this PR addresses: A feature was added into `stock.picking` to look for and trigger automatic reordering rules for products not in stock when "Check Availability" is triggered. This feature adds in the same check and trigger of reordering rules when "Check Availability" is triggered within a Manufacturing Order (MO). This includes subcontractor MOs. In order to reuse logic and make code more maintainable, logic to handle auto-checking/assigning has been moved to `stock.move` so both `stock.picking` and `mrp.production` can both use it easily. Tests updated/added to match new feature. Current behavior before PR: When "Check Availability" is triggered in a MO and products are unavailable to be reserved but have an auto reordering rule, a manual trigger of "Run Scheduler" or of the specific relevant reordering rule(s) is still necessary. Desired behavior after PR is merged: The relevant "auto" reordering rules will be triggered automatically when "Check Availability' is triggered. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves how stock and manufacturing operations split stock movements by allowing them to be processed in batches. This should make related inventory and production workflows more reliable and efficient when multiple movements are handled at once.
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
Calendar meeting popups now show each attendee's participation status directly next to their name and photo. This makes it easier for users to quickly see who has accepted, declined, or is tentative without opening the full event.
Original PR description
PURPOSE There's currenty no easy way to see if the attendees of an event will participate or not. We should add this information on the meeting popup. SPEC On the meeting popup, in the attendees section: display the attendance of everyone, adding the status bullet before their picture. TASK 2058767 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
- Go to Contacts > Configuration > Country Group - Open Europe United Kingdom is still in the group, but should not. opw-2328125 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#56922
Original PR description
- Go to Contacts > Configuration > Country Group - Open Europe United Kingdom is still in the group, but should not. opw-2328125 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#56922
This reverts commit d949cb88abbf8f64b383bceba07105df578a4a14 in favor of https://github.com/odoo/odoo/commit/f4162a75bdc47cd94610ee7626cc68e078313329 To avoid misleading users into thinking that "everything is allright" while actually there are missing tax_id on the credit note lines -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#56813
Original PR description
This reverts commit d949cb88abbf8f64b383bceba07105df578a4a14 in favor of https://github.com/odoo/odoo/commit/f4162a75bdc47cd94610ee7626cc68e078313329 To avoid misleading users into thinking that "everything is allright" while actually there are missing tax_id on the credit note lines -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#56813
When pos_hr is installed but not checked in the current pos.config, the close button was not showing for non admin users. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#57064
Original PR description
When pos_hr is installed but not checked in the current pos.config, the close button was not showing for non admin users. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#57064
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#56138
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#56138
Multiple performance fixes in mail/mass-mailing. [FIX] mass_mailing: speed up recipients filtering --- Using a `set` to lookup recipients that already received an email is much faster on average than with a list. `x in list` is O(n) on average, whereas `x in set` closer to O(1) on average. Example: for a sample mailing with 50k recipients that is half-through, filtering the remaining half (25k) took 10s with a list, and 1s with the set. [FIX] mail: speed up filtering out blocked
Original PR description
Multiple performance fixes in mail/mass-mailing. [FIX] mass_mailing: speed up recipients filtering --- Using a `set` to lookup recipients that already received an email is much faster on average than…
Multiple performance fixes in mail/mass-mailing.
[FIX] mass_mailing: speed up recipients filtering
---
Using a `set` to lookup recipients that already received an email is
much faster on average than with a list. `x in list` is O(n) on
average, whereas `x in set` closer to O(1) on average.
Example: for a sample mailing with 50k recipients that is half-through,
filtering the remaining half (25k) took 10s with a list, and 1s with
the set.
[FIX] mail: speed up filtering out blocked emails
---
For large lists of blocked emails, the time taken to load the records in
cache becomes prohibitive. For instance on a sample blocklist of 600k
entries, the `search([])` to load them could take 80-90s to run!
And this toll is taken every time the mail composer processes an email
batch in mass-mailing mode. Technically, most of the time is spent
iterating on the list of ids many time, in order to prefetch fields
into cache by determining what's missing.
Loading the contents of the list in raw SQL takes a fraction of that
time (400ms vs 90s).
Subsequently using a set for lookups in that blocklist is also much
faster (average time complexity O(1) vs O(n)).
Example: looking up an item in a 600k-entry blocklist is easily 5
orders of magnitude faster!
```py
In [1]: blocklist = set(x[0] for x in self._cr.fetchall())
In [2]: len(blocklist)
Out[2]: 634610
In [3]: self._cr.execute("SELECT email from mail_blacklist")
In [4]: blocklist = set(x[0] for x in self._cr.fetchall())
In [5]: %timeit "hello@hello.com" in blocklist
The slowest run took 35.29 times longer than the fastest. This could mean that an intermediate result is being cached.
10000000 loops, best of 3: 31.6 ns per loop
In [6]: self._cr.execute("SELECT email from mail_blacklist")
In [7]: blocklist = [x[0] for x in self._cr.fetchall()]
In [8]: %timeit "hello@hello.com" in blocklist
100 loops, best of 3: 2.24 ms per loop
```
Forward-Port-Of: odoo/odoo#57125Odoo CLA for v13 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#56301
Original PR description
Odoo CLA for v13 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#56301
Fixing bugs found after odoo/odoo#53335 Forward-Port-Of: odoo/odoo#56876
Original PR description
Fixing bugs found after odoo/odoo#53335 Forward-Port-Of: odoo/odoo#56876
Currently on branch saas-13.5 Without demo data Forward-Port-Of: odoo/odoo#57148
Original PR description
Currently on branch saas-13.5 Without demo data Forward-Port-Of: odoo/odoo#57148
When multiple date (or datetime) pickers are added to a website form, the uniqueId value is used to differenciate them thanks to 694af9a19a. It works well in a lot of case (eg. when adding several field at the same time, or by change because other code consume uniqueId) but in this scenario: - add a date field on a form - save - add a date field on a form it is possible have the second field targetting the first one because they have the same `'datepicket'+uniqueId()` ID. This happens because
Original PR description
When multiple date (or datetime) pickers are added to a website form, the uniqueId value is used to differenciate them thanks to 694af9a19a. It works well in a lot of case (eg. when adding several field at the same time, or by change because other code consume uniqueId) but in this scenario: - add a date field on a form - save - add a date field on a form it is possible have the second field targetting the first one because they have the same `'datepicket'+uniqueId()` ID. This happens because uniqueId is reset at each page opening. found when working on opw-2326882 Forward-Port-Of: odoo/odoo#57100 Forward-Port-Of: odoo/odoo#57092
Before this commit, when a user posted a message from a chatwindow, the scroll did not move to the last message. task-2314409 Forward-Port-Of: odoo/odoo#56510
Original PR description
Before this commit, when a user posted a message from a chatwindow, the scroll did not move to the last message. task-2314409 Forward-Port-Of: odoo/odoo#56510
With: - Anglo-saxon activated, - Costing Method: FIFO, - Inventory Valuation: Automated. Create a PO for product AAA, receive the product and archive it, create and try to POST the vendor bill. > This lead to a ZeroDivisionError: float division by zero The anglo-saxon entries cannot be generated as the product is not valued anymore. This commit is displaying a clearer error message for end users. more info from SLE on 2250451 opw-2307562, 2317338, 2320080, 2311843 Fine tuni
Original PR description
With: - Anglo-saxon activated, - Costing Method: FIFO, - Inventory Valuation: Automated. Create a PO for product AAA, receive the product and archive it, create and try to POST the vendor bill. > This lead to a ZeroDivisionError: float division by zero The anglo-saxon entries cannot be generated as the product is not valued anymore. This commit is displaying a clearer error message for end users. more info from SLE on 2250451 opw-2307562, 2317338, 2320080, 2311843 Fine tuning of https://github.com/odoo/odoo/commit/8ce4db8ca04cd8e5266fc186b35deef76506da46 Co-authored-by: simongoffin <sig@odoo.com> Forward-Port-Of: odoo/odoo#56486 Forward-Port-Of: odoo/odoo#56400
Forward-Port-Of: odoo/odoo#57124
Original PR description
Forward-Port-Of: odoo/odoo#57124
- Go to Sales > Configuration > Settings and activate "Product Configurator" - Go to Sales > Configuration > Attributes and create an Attribute: * Attribute Name: Attribute X * Variants Creation Mode: Never (create_variant='no_variant') * Attribute Values: - Value 1 - Value 2 - Go to Sales > Products > Products and create a Product: * Product Name: Product X * Variants: Attribute X (Value 1, Value 2) - Go to Sales > Configuration > Quotation Templates and create a
Original PR description
- Go to Sales > Configuration > Settings and activate "Product Configurator" - Go to Sales > Configuration > Attributes and create an Attribute: * Attribute Name: Attribute X * Variants Creation…
- Go to Sales > Configuration > Settings and activate "Product Configurator"
- Go to Sales > Configuration > Attributes and create an Attribute:
* Attribute Name: Attribute X
* Variants Creation Mode: Never (create_variant='no_variant')
* Attribute Values:
- Value 1
- Value 2
- Go to Sales > Products > Products and create a Product:
* Product Name: Product X
* Variants: Attribute X (Value 1, Value 2)
- Go to Sales > Configuration > Quotation Templates and create a Template:
* Quotation Template: Template X
* Lines:
- Product: Product X - Description: XXX
- Go to Sales > Orders > Quotations and create a Quotation
- Select Template X as Quotation Template
- Add Product X in Order Lines and validate Product Configurator
The Product is added to the SO line but the selected Attribute value is not displayed
in the SO line description, as it usually does.
It comes from the fact that when using a Quotation Template, if an added Product is
defined in the Template, the description from the Template (i.e. XXX) is used instead of
the default generated description.
This is not practical as it is not possible to differentiate several Product X with
different values for Attribute X, because of its Variants Creation Mode set to Never.
opw-2322827
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#57162
Forward-Port-Of: odoo/odoo#56953This commit adds a test to save the effort of re-setting the tz cookie when it is already set. We also merge the tz cookie script with the one defining session_info. Commit motivated by discussion on PR #55726 Forward-Port-Of: odoo/odoo#57147
Original PR description
This commit adds a test to save the effort of re-setting the tz cookie when it is already set. We also merge the tz cookie script with the one defining session_info. Commit motivated by discussion on PR #55726 Forward-Port-Of: odoo/odoo#57147
The following commit fixes >=py3.7.4 compatibility: - https://github.com/gevent/gevent/commit/9d27d269ed01a7e752966caa7a6f85d773780a1a It was released in stable version gevent==1.5.0 on April 10, 2020: - https://pypi.org/project/gevent/1.5.0/ gevent==1.3.4 was released on June 20, 2018 - https://github.com/gevent/gevent/releases/tag/1.3.4 And python3.7.0 was released June 27, 2018 - https://www.python.org/downloads/release/python-370/ So, the current pinned version 1.3.4 is n
Original PR description
The following commit fixes >=py3.7.4 compatibility: - https://github.com/gevent/gevent/commit/9d27d269ed01a7e752966caa7a6f85d773780a1a It was released in stable version gevent==1.5.0 on April 10,…
The following commit fixes >=py3.7.4 compatibility: - https://github.com/gevent/gevent/commit/9d27d269ed01a7e752966caa7a6f85d773780a1a It was released in stable version gevent==1.5.0 on April 10, 2020: - https://pypi.org/project/gevent/1.5.0/ gevent==1.3.4 was released on June 20, 2018 - https://github.com/gevent/gevent/releases/tag/1.3.4 And python3.7.0 was released June 27, 2018 - https://www.python.org/downloads/release/python-370/ So, the current pinned version 1.3.4 is not optimized for py3.7 It could be a possible reason to reproduce the following error: - https://github.com/odoo/odoo/pull/50861 This change upgrades the pinned version to gevent==1.5.0 in order to get an optimized version for py3.7 Bump version to greenlet==0.4.14 for py3.7 since that it is the version defined in the sha of release of gevent==1.5.0 - https://github.com/gevent/gevent/commit/a1a72cb9 - https://github.com/gevent/gevent/blob/a1a72cb9/setup.py#L188 Forward-Port-Of: odoo/odoo#57179 Forward-Port-Of: odoo/odoo#56167
task-2333915 Forward-Port-Of: odoo/enterprise#12982
Original PR description
task-2333915 Forward-Port-Of: odoo/enterprise#12982
The aim of this commit is to move the spreadsheet folder to the last position Task-ID 2325353 Forward-Port-Of: odoo/enterprise#12776
Original PR description
The aim of this commit is to move the spreadsheet folder to the last position Task-ID 2325353 Forward-Port-Of: odoo/enterprise#12776
…_locality_id field together Before, when l10n_mx_edi_locality_id was not set, both l10n_mx_edi_locality and l10n_mx_edi_locality_id were shown, so when you created a new partner, you would see 2 locality fields in a weird way. Now, we only show both fields when l10n_mx_edi_locality is set, but not l10n_mx_edi_locality_id. That way, in case you have some old partners before the installation of the FIX, it will still work. opw-2312641 Forward-Port-Of: odoo/enterprise#12993 Forward-P
Original PR description
…_locality_id field together Before, when l10n_mx_edi_locality_id was not set, both l10n_mx_edi_locality and l10n_mx_edi_locality_id were shown, so when you created a new partner, you would see 2 locality fields in a weird way. Now, we only show both fields when l10n_mx_edi_locality is set, but not l10n_mx_edi_locality_id. That way, in case you have some old partners before the installation of the FIX, it will still work. opw-2312641 Forward-Port-Of: odoo/enterprise#12993 Forward-Port-Of: odoo/enterprise#12843
Currently stored in saas-13.5 Without demo data Enterprise part of odoo/odoo#57148 Forward-Port-Of: odoo/enterprise#12985
Original PR description
Currently stored in saas-13.5 Without demo data Enterprise part of odoo/odoo#57148 Forward-Port-Of: odoo/enterprise#12985
The helper message was changed in the analysis menu of hr_expense . The condition in the get_empty_list_help function needed to be adapted accordingly. Task-2320205 PR community : 56733 Forward-Port-Of: odoo/enterprise#12778
Original PR description
The helper message was changed in the analysis menu of hr_expense . The condition in the get_empty_list_help function needed to be adapted accordingly. Task-2320205 PR community : 56733 Forward-Port-Of: odoo/enterprise#12778
Avoid being able to read any action Enterprise part of odoo/odoo#56876 Forward-Port-Of: odoo/enterprise#12844
Original PR description
Avoid being able to read any action Enterprise part of odoo/odoo#56876 Forward-Port-Of: odoo/enterprise#12844
Forward-Port-Of: odoo/enterprise#12853
Original PR description
Forward-Port-Of: odoo/enterprise#12853
[FIX] hr_contract_salary: update 13rd month salary configuration Before this commit, in the salary configuration, if the parameters were modified, the 13rd month wasn't updated. wage_with_holidays must to be added into the fields that are updated when the net salary is updated. opw-2309679 ---------------------------------------------------------------------------------- [FIX] l10n_be_hr_contract_salary: update double holiday salary configuration Before this commit, in the B
Original PR description
[FIX] hr_contract_salary: update 13rd month salary configuration Before this commit, in the salary configuration, if the parameters were modified, the 13rd month wasn't updated. wage_with_holidays must to be added into the fields that are updated when the net salary is updated. opw-2309679 ---------------------------------------------------------------------------------- [FIX] l10n_be_hr_contract_salary: update double holiday salary configuration Before this commit, in the Belgian salary configuration, if the parameters were modified, the double holiday salary wasn't updated. double_holiday_wage must to be added into the fields that are updated when the net salary is updated. opw-2309679 Forward-Port-Of: odoo/enterprise#12791 Forward-Port-Of: odoo/enterprise#12293