Monday, January 31, 2022
32 changes · master
New functionality added to Odoo
This update adds a shared styling class for avatar images shown in mail threads and live chat conversations. It supports a broader interface restyling effort by making avatar presentation more consistent and easier to maintain.
Original PR description
Adds a new CSS class to handle avatars images when used in threads. Part of the overall v16 SCSS optimization/restyle (task-2704984). task-2731819 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A new shared styling class standardizes how avatar images appear when embedded in text, such as activity or messaging views. This helps keep user pictures aligned and consistently sized as part of the broader interface restyling work.
Original PR description
New css class to handle avatars images when rendered within text. Part of the overall v16 SCSS optimisation/restyle (task-2704984). task-2731819 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
This change makes the list of user profile fields that trigger automatic cache refreshes easier to customize. It helps future extensions adapt cache behavior without changing core code, reducing maintenance effort and upgrade risk.
Original PR description
Whenever a user is modified, if at least one of a predefinet-field list is being touched (e.g. companies or groups), cache is automatically invalidated. However, that field list is harcoded, which prevents it from being inherited and extended. This commit unarcodes such fields by moving them to a separate method, which makes possible to inherit such method and extend the list. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Marketing automation participant records must now always point to a real related document. This prevents incomplete or invalid participant data from being saved, improving data reliability for campaigns and follow-up processes.
Original PR description
Marketing participants records are linked to documentss through a model and an integer res_id field. The latter one is required but is implemented using an integer field, meaning writing 0 is actually a valid value for 'required'. In this commit we add a constraint to ensure we never update participants with a void res_id value. See community PR that updated mail activities and mailing traces for the same reason. Task-2694133
Code cleanup and technical improvements
The web interface now prioritizes loading FontAwesome icons from a CDN, with local files kept as a fallback. This can improve icon loading performance and keeps the styling code cleaner by removing outdated browser-specific rules.
Original PR description
This commit reviews how fontAwesome is loaded by the system adding a priority CDN option and using font-files in '/lib' as a fallback only. It will also convert the original CSS file to SCSS, allowing to use a SCSS function to output the necessary quite complicated src string. FontAweome was made in 2017 and the original file included several deprecated selector and vendor-prefix rules. These lines were no longer necessary and have been removed. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Steps : - Attendances > Kiosk Mode - Log in or out several times Issue : - Interface slows down Cause : - When a kiosk is destroyed, poll is started - Yet each time a kiosk is started, the old kiosk is destroyed, which starts a new poll. Fix : - Given that the kiosk mode can't be escaped from the interface, it is not necessary to restart polling when destroying. opw-2735324 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavi
Original PR description
Steps : - Attendances > Kiosk Mode - Log in or out several times Issue : - Interface slows down Cause : - When a kiosk is destroyed, poll is started - Yet each time a kiosk is started, the old kiosk is destroyed, which starts a new poll. Fix : - Given that the kiosk mode can't be escaped from the interface, it is not necessary to restart polling when destroying. opw-2735324 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#83489
This update removes an unused piece of code from the messaging area. It has no visible impact for users, but helps keep the system easier to maintain and reduces unnecessary complexity.
This update adjusts the French chart of accounts to correct some account names and types. It helps reduce the risk of accounting report misconfiguration for companies using the French localization.
Original PR description
While updating financial reports to help avoid misconfiguration, slightly update the coa to fix some wrong account types or name. Tax id #2585627 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Spanish localization now classifies account 5585 as a current liability instead of a non-current liability. This better reflects how the account is expected to be treated in financial reporting, improving the accuracy of Spanish accounting setup.
Original PR description
Change the type of the account 5585 to be current liabilities instead of non-current as it makes more sense. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update avoids showing a demo data loading message when a module has no demo data to load. It keeps system logs clearer and reduces unnecessary noise for teams monitoring installations or updates.
Original PR description
when there is no demo data available for the given module -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Inventory screens now use updated badge styling to make stock move statuses easier to read at a glance. This improves day-to-day usability for warehouse and inventory teams without changing the underlying workflow.
Original PR description
task: 2654703-4
This change reorganizes how the mail app tracks automated scrolling in message lists. It helps keep message list behavior more consistent and easier to maintain, with no expected disruption for users.
A small issue in the appointment sharing wizard was corrected so the right staff users are selected and processed. This helps ensure appointment sharing behaves reliably when staff members are involved.
Original PR description
A 's' is missing in staff_user_ids definition, the compute method is _compute_staff_user_ids and not _compute_staff_user_id. This has been hiding an issue on the format of ids in the compute method that is corrected too. Task-2748075 X-original-commit: eb9ff5b4de8eb342a53e3090de8b4410ef6f11b9 Part of odoo/enterprise#17934
Steps to reproduce: - install only sale_project - go to Project > Configuration > Projects -> Warning in the JS console OPW-2717655 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83298 Forward-Port-Of: odoo/odoo#83270
Original PR description
Steps to reproduce: - install only sale_project - go to Project > Configuration > Projects -> Warning in the JS console OPW-2717655 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83298 Forward-Port-Of: odoo/odoo#83270
Issue: Padding impacting all reports since css file imported in common report assets. Solution: part revert of commit: https://github.com/odoo/odoo/commit/69a1289eca79272efe7e53f8b3ad70de6df3d96a opw-2686597 Forward-Port-Of: odoo/odoo#83198 Forward-Port-Of: odoo/odoo#81436
Original PR description
Issue: Padding impacting all reports since css file imported in common report assets. Solution: part revert of commit: https://github.com/odoo/odoo/commit/69a1289eca79272efe7e53f8b3ad70de6df3d96a opw-2686597 Forward-Port-Of: odoo/odoo#83198 Forward-Port-Of: odoo/odoo#81436
Italians do not always mention the country code in the VAT number of the partner, but we can suppose in that case that it is within Italy. Instead of IT0477472701, they would put just 0477472701. 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#82953
Original PR description
Italians do not always mention the country code in the VAT number of the partner, but we can suppose in that case that it is within Italy. Instead of IT0477472701, they would put just 0477472701. 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#82953
Steps to reproduce: - go to inventory report - remove the `"Product > Location"` Group by filter. Problem: The buttons `“Inventory at Date”` and `“Create”` are like merged together because there is no margin right Before the commit:  After: ![2022-01-26_15-18_1](https://user-images.githubusercontent.com/78867936/151179652-f6a2aecc-5f82-42c0-a68a-10afd4aa1337.p
Original PR description
Steps to reproduce: - go to inventory report - remove the `"Product > Location"` Group by filter. Problem: The buttons `“Inventory at Date”` and `“Create”` are like merged together because there is no margin right Before the commit:  After:  opw-2721995 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83425
The current behavior is that we are exporting the line subtotal as chargeAmount of the line. This is an issue as this field is expecting the unit price instead. A bugfix was done for importing extern invoices properly that broke importing factur-x files from Odoo as it doesn't support that custom behavior anymore. Thus, this will correct the export to properly store the unit price in the GrossPriceProductTradePrice ChargeAmount. At the same time, add the NetPriceProductTradePrice Charg
Original PR description
The current behavior is that we are exporting the line subtotal as chargeAmount of the line. This is an issue as this field is expecting the unit price instead. A bugfix was done for importing extern invoices properly that broke importing factur-x files from Odoo as it doesn't support that custom behavior anymore. Thus, this will correct the export to properly store the unit price in the GrossPriceProductTradePrice ChargeAmount. At the same time, add the NetPriceProductTradePrice ChargeAmount, which is required and should contain the unit price with discount applied. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83548 Forward-Port-Of: odoo/odoo#82993
Prior to this change, if the user use a full refund option and choose a document type different than default one, the default document type was use regardless of the choosen one. This was broken on this commit dfd01b8#diff-1369ca152be95632086495cfcfbd54a0d18d893c2389670ff1d516f1596f3e0d As l10n_latam_document_type_id is not stored, it's change is not saved and sended to to backend. We make this hack so that we don't break stable policy This should be FP only till v15, on master this sho
Original PR description
Prior to this change, if the user use a full refund option and choose a document type different than default one, the default document type was use regardless of the choosen one. This was broken on this commit dfd01b8#diff-1369ca152be95632086495cfcfbd54a0d18d893c2389670ff1d516f1596f3e0d As l10n_latam_document_type_id is not stored, it's change is not saved and sended to to backend. We make this hack so that we don't break stable policy This should be FP only till v15, on master this should be applied https://github.com/odoo/odoo/pull/82670 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#82931
Field `QuantPackage.name` was allowed to be left empty, which lead to confusing situations for customers (cfr. ref for more details). task: 2654703-5 ref: https://www.odoo.com/web#action=333&active_id=809&cids=1&id=2671818&menu_id=4720&model=project.task&view_type=form Forward-Port-Of: odoo/odoo#83491
Original PR description
Field `QuantPackage.name` was allowed to be left empty, which lead to confusing situations for customers (cfr. ref for more details). task: 2654703-5 ref: https://www.odoo.com/web#action=333&active_id=809&cids=1&id=2671818&menu_id=4720&model=project.task&view_type=form Forward-Port-Of: odoo/odoo#83491
Current behavior: When using variant in PoS the price was not always correct Steps to reproduce: 1. Set up items with modifiers (Modifier type must be of type `variant creation mode : never`, where adding a modifier leads to a different price than with the base item e.g. base item is 10 USD, modifier is 5 USD, total price is 15 USD; 2. Activate Product configurator and make sure it's a Bar/Restaurant in the PoS settings 3. Select the items with the modifier; 5. Leave the table and come b
Original PR description
Current behavior: When using variant in PoS the price was not always correct Steps to reproduce: 1. Set up items with modifiers (Modifier type must be of type `variant creation mode : never`, where adding a modifier leads to a different price than with the base item e.g. base item is 10 USD, modifier is 5 USD, total price is 15 USD; 2. Activate Product configurator and make sure it's a Bar/Restaurant in the PoS settings 3. Select the items with the modifier; 5. Leave the table and come back to the table 5. Change the quantity of this product 6. The price is back to the base price without the modifier opw-2696529 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#82490
This reverts commit f22364c32ac1438ededd611578b64a69186d7c9c. - go to a partner - click on the button "Sale" - Create a new order --> Issue you see all product archived (and all the python logique run with active_test = False) note: since the original issue would be reintroduced, this commit apply the active_test only to the search filter so it will only be applied in the search unless the filter is removed. closes #83600 Forward-Port-Of: odoo/odoo#83616
Original PR description
This reverts commit f22364c32ac1438ededd611578b64a69186d7c9c.
- go to a partner
- click on the button "Sale"
- Create a new order
--> Issue you see all product archived (and all the python logique run
with active_test = False)
note: since the original issue would be reintroduced, this commit apply
the active_test only to the search filter so it will only be applied in
the search unless the filter is removed.
closes #83600
Forward-Port-Of: odoo/odoo#83616Description of the issue/feature this PR addresses: The currency rate could be different if the invoice date is different that the accounting date Steps to reproduce: 1- Install l10n_ar 2- Create two different currency rate for foreign currency (i.e: Dollar) with also different Date 3- Create an invoice setting the currency as foreign currency (i.e: Dollar) Current behavior before PR: In page "Journal Items" could see that each account line use the currency rate defined by the account
Original PR description
Description of the issue/feature this PR addresses: The currency rate could be different if the invoice date is different that the accounting date Steps to reproduce: 1- Install l10n_ar 2- Create two different currency rate for foreign currency (i.e: Dollar) with also different Date 3- Create an invoice setting the currency as foreign currency (i.e: Dollar) Current behavior before PR: In page "Journal Items" could see that each account line use the currency rate defined by the accounting date, however the currency rate filed (which is not visible) is defined by the invoice date. Desired behavior after PR is merged: Use always the accounting date to set the currency rate -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83297 Forward-Port-Of: odoo/odoo#82743
website{_*}: website, website_blog, website_sale, website_slides Before this commit tips could be revived after being destroyed if a resize event occurred, because the resize was being debounced and could trigger a request to rebuild the bubble mode of the tip. After this commit the resize debounce is cancelled if the tip was destroyed in the meantime. However another unidentified reason still manages to trigger an asynchronous re-creation of the tip after destroy() is called, even
Original PR description
website{_*}: website, website_blog, website_sale, website_slides Before this commit tips could be revived after being destroyed if a resize event occurred, because the resize was being debounced and…
website{_*}: website, website_blog, website_sale, website_slides
Before this commit tips could be revived after being destroyed if a
resize event occurred, because the resize was being debounced and could
trigger a request to rebuild the bubble mode of the tip.
After this commit the resize debounce is cancelled if the tip was
destroyed in the meantime.
However another unidentified reason still manages to trigger an
asynchronous re-creation of the tip after destroy() is called, even
though all timeouts are cleared.
The following remaining sequence has been identified:
- mouseenter.anchor is triggered: but this is disabled during destroy
- it calls _to_info_mode() which registers the timer_in timeout: but
this timeout is cleared during destroy
- it calls _build_info_mode() which registers the _transitionEndTimer
timeout: but this timeout is cleared during destroy
- it calls _onTransitionEnd() which calls _updatePosition() which
revives the tip
Therefore an additional guard is added to prevent _updatePosition() from
being executed if destroy() was called.
Note that the mouseleave > to_bubble_mode chain being symmetrical to
this one, it is likely that it could also happen.
This PR also fixes the following issues:
- "+New" steps now only appear if the new content menu is not opened
- Only the visible "+New" step is consumed (instead of all colliding steps)
- The blog tour step about selecting an image now accepts any of the image (instead of only the first one)
- Move blog cover selection step on top of button. (instead of right which was outside the display)
task-2728994 (was task-2675252)
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#83611
Forward-Port-Of: odoo/odoo#79282Steps to reproduce: - Activate the cookie dialog from the website settings - Remove the backdrop from the cookie dialog - Add some blocks to the cookie dialog in the website editor until the dialog height is bigger than the page height. Result: The cookie dialog is not scrollable, so it's impossible to reach the "I agree" button and close the dialog, leaving the user stuck at the first page. I check if the popup content is higher than the window. If it is, I give priority to the po
Original PR description
Steps to reproduce: - Activate the cookie dialog from the website settings - Remove the backdrop from the cookie dialog - Add some blocks to the cookie dialog in the website editor until the dialog…
Steps to reproduce: - Activate the cookie dialog from the website settings - Remove the backdrop from the cookie dialog - Add some blocks to the cookie dialog in the website editor until the dialog height is bigger than the page height. Result: The cookie dialog is not scrollable, so it's impossible to reach the "I agree" button and close the dialog, leaving the user stuck at the first page. I check if the popup content is higher than the window. If it is, I give priority to the popup scroll over the page one. I had to overwrite the _showElement method to call _setScrollbar after the content rendering, in this way I can get its correct height. I also try to update the scrollbar each time a block in the cookie bar has been changed and each time the window resize. This is optimize, so if the overflow isn't changed from the last time I tried to update the scrollbar no action will be taken. In this way you can always see the whole popup without refreshing the page. Also I have to set 'pointer-events' to none only if the popup is smaller than the page itself (to interact with and scroll the page behind), otherwise the popup won't be scrollable. I did this by adding a class "s_popup_overflow_page" if the popup is higher than the page and I adapted the pointer-events property accordingly. opw-2660786 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#83607 Forward-Port-Of: odoo/odoo#80092
Description of the issue/feature this PR addresses: TaskID: https://www.odoo.com/web?#id=2092269&action=333&active_id=974&model=project.task&view_type=form&menu_id=4720 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#83617 Forward-Port-Of: odoo/odoo#40918
Original PR description
Description of the issue/feature this PR addresses: TaskID: https://www.odoo.com/web?#id=2092269&action=333&active_id=974&model=project.task&view_type=form&menu_id=4720 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#83617 Forward-Port-Of: odoo/odoo#40918
Purpose ======= In the US salaries are always discussed on a yearly basis. The "Generate offer" wizard supports this but it only uses the yearly cost to calculate the monthly wage field. final_yearly_costs is then calculated from the monthly wage field. This leads to rounding errors. When I create an offer via the "Generate offer" wizard for $100.000 yearly the salary configurator and contract end up like this: - 8333.33 (for 8333.3333333) - 99999.96 (for 100000) To avoid confus
Original PR description
Purpose ======= In the US salaries are always discussed on a yearly basis. The "Generate offer" wizard supports this but it only uses the yearly cost to calculate the monthly wage field. final_yearly_costs is then calculated from the monthly wage field. This leads to rounding errors. When I create an offer via the "Generate offer" wizard for $100.000 yearly the salary configurator and contract end up like this: - 8333.33 (for 8333.3333333) - 99999.96 (for 100000) To avoid confusion for the end users, even if this behavior is logical and not severe (4 cents dispatched over a whole year), this commit prevents the amount to be modified no a nearby value. Of courses, writing on an advantage will trigger the recompute to be set to the new value. Forward-Port-Of: odoo/enterprise#23838
When the bank account is not shown because the salary structure doesn't apply the following traceback occurred: Traceback (most recent call last): ... File ".../addons/hr_contract_salary/controllers/main.py", line 578, in update_salary new_contract = self.create_new_contract(contract, advantages) File ".../addons/l10n_be_hr_contract_salary/controllers/main.py", line 306, in create_new_contract new_contract = super().create_new_contract(contract, advantages, no_write=no_wri
Original PR description
When the bank account is not shown because the salary structure doesn't apply the following traceback occurred: Traceback (most recent call last): ... File…
When the bank account is not shown because the salary structure
doesn't apply the following traceback occurred:
Traceback (most recent call last):
...
File ".../addons/hr_contract_salary/controllers/main.py", line 578, in update_salary
new_contract = self.create_new_contract(contract, advantages)
File ".../addons/l10n_be_hr_contract_salary/controllers/main.py", line 306, in create_new_contract
new_contract = super().create_new_contract(contract, advantages, no_write=no_write, **kw)
File ".../addons/hr_contract_salary/controllers/main.py", line 552, in create_new_contract
self._update_personal_info(employee, contract, personal_infos, no_name_write=bool(kw.get('employee')))
File ".../addons/hr_contract_salary/controllers/main.py", line 514, in _update_personal_info
('acc_number', '=', bank_account_vals['acc_number'])], limit=1)
Exception
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File ".../http.py", line 644, in _handle_exception
return super(JsonRequest, self)._handle_exception(exception)
File ".../http.py", line 302, in _handle_exception
raise exception.with_traceback(None) from new_cause
KeyError: 'acc_number'
This solves this issue by not trying to create or find a bank account
if no bank account information was provided.
opw-2747520
Forward-Port-Of: odoo/enterprise#23842When the default tax is kept by the OCR and it is a price included tax, the unit price of the line should be updated accordingly. Forward-Port-Of: odoo/enterprise#23700 Forward-Port-Of: odoo/enterprise#23673
Original PR description
When the default tax is kept by the OCR and it is a price included tax, the unit price of the line should be updated accordingly. Forward-Port-Of: odoo/enterprise#23700 Forward-Port-Of: odoo/enterprise#23673
Before this PR: When checking dte status, if successful and try to send DTE to the partner, there is an exception related to the email template (record instead of "object" name of object). After this PR: Corrected. This replaces #23332 Forward-Port-Of: odoo/enterprise#23844 Forward-Port-Of: odoo/enterprise#23690
Original PR description
Before this PR: When checking dte status, if successful and try to send DTE to the partner, there is an exception related to the email template (record instead of "object" name of object). After this PR: Corrected. This replaces #23332 Forward-Port-Of: odoo/enterprise#23844 Forward-Port-Of: odoo/enterprise#23690
### Current behavior Unable to print via IoT box due to a JS Error : `Uncaught Promise > Cannot set properties of undefined (setting 'device_id')` ### Steps - Install Sales and IoT - Enable dev mode - Go to Technical > Reports (under Reporting) - Search for Quotation (model `sale.order`) - Select an IoT device if none is selected - Go to sales and try to print a quotation ### Reason Since this commit and especially this diff [1], we are assigning the device id to `action.data.devi
Original PR description
### Current behavior Unable to print via IoT box due to a JS Error : `Uncaught Promise > Cannot set properties of undefined (setting 'device_id')` ### Steps - Install Sales and IoT - Enable dev mode - Go to Technical > Reports (under Reporting) - Search for Quotation (model `sale.order`) - Select an IoT device if none is selected - Go to sales and try to print a quotation ### Reason Since this commit and especially this diff [1], we are assigning the device id to `action.data.device_id` but in some case `action.data` is undefined and leads to an error [1] : https://github.com/odoo/enterprise/pull/23076/files#diff-aba3790fff7e8fe5e297f321094f6ba3136de6bd3d0e7aa241a1ba3e07d1f269R29 OPW-2738587 Forward-Port-Of: odoo/enterprise#23792
... due to adding values in demo data and data. Adding the module sale_subscription will add the DATA yearly_subscription sale_subscription_template) in the xml file of the DATA, we can see that the dscription field is not populated. However, in the xml file of the DEMO data, the yearly_subscription is populated. If you create a db without the demo data and add a language, the translation of the yearly_subscription template for the description will be populated however we did not h
Original PR description
... due to adding values in demo data and data. Adding the module sale_subscription will add the DATA yearly_subscription sale_subscription_template) in the xml file of the DATA, we can see that the dscription field is not populated. However, in the xml file of the DEMO data, the yearly_subscription is populated. If you create a db without the demo data and add a language, the translation of the yearly_subscription template for the description will be populated however we did not have a value. After discussing with our Translation expert, we should not modify the same data in DATA and DEMO. This would lead to translation issue like the current one. To solve the issue, let's simply remove the translation of the description in order to avoid seeing terms being translated upon language adding. opw-2692782 (where customer was upset thinking somebody was adding translation on his db) Forward-Port-Of: odoo/enterprise#23828 Forward-Port-Of: odoo/enterprise#23774