Daily updates from Odoo
Navigate
Branch
Thursday, October 31, 2019
26 changes
Enhancements to existing features
Website editors can now install missing snippet modules directly from the editor after confirming they want to save their current changes. This keeps users in their editing flow and reloads the page back into edit mode once installation is complete.
Original PR description
In the editor, the snippets from uninstalled module are shown with the possibility to install the module to get snippet. Before this commit: When clicking on it, it will redirect to the module page, in the backend from where you can install the module. Now: A popup will be shown to save current changes and install the module. The installation will be done without changing page, in the editor. Once done, the page will reload in editor enabled mode. task-2089285
Resolved issues and error corrections
This fix removes invalid spaces from identifiers used in the Italian localization tax data. It prevents crashes when loading or updating the Italian accounting configuration, helping businesses keep tax setup reliable.
Original PR description
After #38139, space in xmlid will crash
This fixes a small data issue in the Dominican Republic localization where an invalid identifier could cause the system to crash when loading tax report data. Businesses using this localization get a more reliable setup or update process without any functional change to tax reporting.
Original PR description
After #38139, space in xmlid will crash http://runbot.odoo.com/runbot/build/673006
This fix updates how sales and point-of-sale report data is prepared so it follows the expected application pattern. It is a small internal correction intended to keep report behavior consistent without changing standard user workflows.
Original PR description
**Description of the issue/feature this PR addresses:** Put correct decorator in some calls of `_get_report_values` method. As commented in https://github.com/odoo/odoo/pull/39527#issuecomment-547525722, the change of decorator cannot be done in stable. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Installing the Mercury payment terminal integration no longer fails when the IoT module is not installed. The related barcode scanner label is now handled in the right place, preventing setup errors and later label conflicts if IoT is added afterward.
Original PR description
We had a traceback when installing pos_mercury if pos_iot was not installed because the field `iot_barcode_scanner` was not present in the view of pos_enterprise. Furthermore, if pos_iot is installed after pos_mercury, this label will be again overridden. We fix this by removing the override and changing the label when pos_mercury is not installed. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a routing cache issue that could make newly installed apps, such as Discuss, appear to have missing or unknown pages on a fresh database. The change ensures routing information is rebuilt correctly during installation and not incorrectly reused across databases.
Original PR description
Initial b6ed34e1 idea was to ensure that we always have _rewrite_len and _routing_map defined. Unfortunately, this is not always correct since class attribute defined dynamically are actually added in registry, and recomputed on each install. After b6ed34e1, after installing discuss on a fresh database without demo, all discuss routes will be unknown since None is already in _routing_map and thus routing_map is not recomputed. When routing_map is in registry class, the install will remove the _routing_map attribute, which will fix the problem.
This fixes a small naming issue in the Swiss reporting setup that could prevent reports from loading correctly after a related platform change. Businesses using Swiss localization reports should see more reliable behavior with no change to their workflow.
Original PR description
After odoo/odoo#38139, space in xmlid will crash
This update corrects validation around internal report identifiers so they no longer include spaces. It helps prevent configuration or loading issues in localized accounting reports, with minimal visible impact for users.
Installing the Mercury payment option no longer fails when POS IoT is not already installed. The label handling was adjusted so installation order does not cause configuration screens to break or show overwritten labels.
Original PR description
We had a traceback when installing pos_mercury if pos_iot was not installed because the field `iot_barcode_scanner` was not present in the view of pos_enterprise. Furthermore, if pos_iot is installed after pos_mercury, this label will be again overridden. We fix this by removing the override and changing the label when pos_mercury is not installed.
Miscellaneous changes
It was technically possible that two editors for the same element are created in the same JS stack execution... and since 13.0 and the use of native promises, it happens every time a block is dropped in the page. Note: this commit fixes the problem with minimal code but the logic should be improved in master. Forward-Port-Of: odoo/odoo#39641 Forward-Port-Of: odoo/odoo#39575
Original PR description
It was technically possible that two editors for the same element are created in the same JS stack execution... and since 13.0 and the use of native promises, it happens every time a block is dropped in the page. Note: this commit fixes the problem with minimal code but the logic should be improved in master. Forward-Port-Of: odoo/odoo#39641 Forward-Port-Of: odoo/odoo#39575
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#39049
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#39049
There recently were some fixes to the system of onFocus/onBlur with the new left panel of the 13.0 editor and one still remained: the onBlur method was most of the time called only on the main snippet options and not the child ones. Now it works as it should, even if the system logic has to be improved to be more robust. One difference remains with 12.0 but this can be considered as a change for the 13.0 version: the parent options onFocus/onBlur are called before the child options whil
Original PR description
There recently were some fixes to the system of onFocus/onBlur with the new left panel of the 13.0 editor and one still remained: the onBlur method was most of the time called only on the main snippet options and not the child ones. Now it works as it should, even if the system logic has to be improved to be more robust. One difference remains with 12.0 but this can be considered as a change for the 13.0 version: the parent options onFocus/onBlur are called before the child options while it was the opposite before. Forward-Port-Of: odoo/odoo#39648
No need to bind events for editable mode. Forward-Port-Of: odoo/odoo#39596
Original PR description
No need to bind events for editable mode. Forward-Port-Of: odoo/odoo#39596
When you create an invoice, you can register a payment to mark it as "paid". Before this commit: - You can't send & print the invoice anymore. After this commit: - The button send & print is displayed The second "send & print" button's domain was incorrect. OPW-2115720 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 ww
Original PR description
When you create an invoice, you can register a payment to mark it as
"paid".
Before this commit:
- You can't send & print the invoice anymore.
After this commit:
- The button send & print is displayed
The second "send & print" button's domain was incorrect.
OPW-2115720
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#39624Steps to reproduce the bug: - Let's consider two companies C1 and C2 - Let's consider website W - Activate multi-company - Disable common contact book and common catalog - Switch the superuser in company C2 - Activate pricelist - Create a public pricelist PL for C1 and available on W - Set up a pricelist with compute price = formula and based on = cost - Go Sales > Configuration > tick Multiple Sales Prices per Product and tick Prices computed from formulas - Create a portal user PU a
Original PR description
Steps to reproduce the bug: - Let's consider two companies C1 and C2 - Let's consider website W - Activate multi-company - Disable common contact book and common catalog - Switch the superuser in company C2 - Activate pricelist - Create a public pricelist PL for C1 and available on W - Set up a pricelist with compute price = formula and based on = cost - Go Sales > Configuration > tick Multiple Sales Prices per Product and tick Prices computed from formulas - Create a portal user PU and set PL on him - Create a product P with cost = 10$ and publish it on W - Set up the product valuation as: automated - Log as PU and go on the shop - Put P on your cart Bug: The price of P was 0$ instead of 10$ opw:2092695 Forward-Port-Of: odoo/odoo#39589
Fine-tunning of 937b5c076e7175bec664ed0cf4b77505e342f1e2 Have a multiwebsite setup have a payment installed for one of the two websites Make an order on that website and try to pay Before this commit, the transaction doesn't come back to odoo's payment success controller This was because the return url was set to the web base url ICP After this commit, the payment success page is opened as we took the request's url as the return url opw-2080352 Forward-Port-Of: odoo/odoo#3958
Original PR description
Fine-tunning of 937b5c076e7175bec664ed0cf4b77505e342f1e2 Have a multiwebsite setup have a payment installed for one of the two websites Make an order on that website and try to pay Before this commit, the transaction doesn't come back to odoo's payment success controller This was because the return url was set to the web base url ICP After this commit, the payment success page is opened as we took the request's url as the return url opw-2080352 Forward-Port-Of: odoo/odoo#39587
Be in Right to left Open a m2o search more, to get onto the list modal toggle the filters menu Before this commit, the filters dropdown was almost invisble and too much on the right anyway This was because the RTL was not taken into account After this commit, we anchor the dropdown on the right (both as in good and as in side) side of its trigger button Also, when modifying the dropdown, by developping the Custom Filter we force the repositioning of the dropdown, to take those
Original PR description
Be in Right to left Open a m2o search more, to get onto the list modal toggle the filters menu Before this commit, the filters dropdown was almost invisble and too much on the right anyway This was because the RTL was not taken into account After this commit, we anchor the dropdown on the right (both as in good and as in side) side of its trigger button Also, when modifying the dropdown, by developping the Custom Filter we force the repositioning of the dropdown, to take those new elements into account 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#39620 Forward-Port-Of: odoo/odoo#39353
Activate developer mode, generate a report (print an invoice) The report will have missing pieces, like the footer or some part of the header. This is probably caused by wkhtmltopdf not loading properly some resources Wkhtmtopdf generate the same warning message for every problematic resource: "Warning: Received createRequest signal on a disposed ResourceObject's NetworkAccessManager. This might be an indication of an iframe taking too long to load." Related issue on wkhtmltopdf pr
Original PR description
Activate developer mode, generate a report (print an invoice) The report will have missing pieces, like the footer or some part of the header. This is probably caused by wkhtmltopdf not loading…
Activate developer mode, generate a report (print an invoice) The report will have missing pieces, like the footer or some part of the header. This is probably caused by wkhtmltopdf not loading properly some resources Wkhtmtopdf generate the same warning message for every problematic resource: "Warning: Received createRequest signal on a disposed ResourceObject's NetworkAccessManager. This might be an indication of an iframe taking too long to load." Related issue on wkhtmltopdf project page: wkhtmltopdf/wkhtmltopdf#1865 wkhtmltopdf/wkhtmltopdf#3933 wkhtmltopdf/wkhtmltopdf#2565 The problem is located in the response that wkhtmltopdf receive: in debug mode the header of the response contains 'Cache-Control: no-cache' which probably create a race condition during the rendering while a second request is attempted to verify the resources. Adding a raw user agent check to not include this header directive fix the problem Notes from odony: We've considered some alternative solutions to preserve the purpose of the DisableCacheMiddleware without having to explicitly test for wkhtmltopdf. * 'Cache-Control: no-cache' (current behavior) breaks wkhtmltopdf rendering * 'Cache-Control: no-store' breaks wkhtmltopdf rendering too * 'Cache-Control: max-age=0' breaks wkhtmltopdf rendering too. It works when increasing the delay to a few seconds, but no magic value will work for very long documents, or it will stop serving its purpose, so it's not a viable option. * 'Cache-Control: must-revalidate' does not break wkhtmltopdf rendering (no duplicate requests at all), but it is not clear from the RFC (https://tools.ietf.org/html/rfc7234#section-5.2.2.1) that it will have the intended effect for our middlewar opw-2086708 Closes #38394 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#39236
Be in RTL mode, on a list view Click on the button to set up optional fields Before this commit, the dropdown expanded to the right, and was partly invisible After this commit, we dynamically set to which direction the dropdown should expand depending on RTL/LTR Consequently the dropdown is fully visible in either mode, and expands to the list rather than away from it Issue #39402 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavi
Original PR description
Be in RTL mode, on a list view Click on the button to set up optional fields Before this commit, the dropdown expanded to the right, and was partly invisible After this commit, we dynamically set to which direction the dropdown should expand depending on RTL/LTR Consequently the dropdown is fully visible in either mode, and expands to the list rather than away from it Issue #39402 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#39558
Since a many2one_reference is simply an int, we can defer _str_to_many2one_reference to _str_to_integer. Note that to really validate the integer, we need the model_field of the field, which should be stored in the record's values. To get this information, _extract_records would have to be modified. For the reported use-case, it does not matter as the create of the message record checks for the existence of the related record, so the validation works as expected. Better support for
Original PR description
Since a many2one_reference is simply an int, we can defer _str_to_many2one_reference to _str_to_integer. Note that to really validate the integer, we need the model_field of the field, which should be stored in the record's values. To get this information, _extract_records would have to be modified. For the reported use-case, it does not matter as the create of the message record checks for the existence of the related record, so the validation works as expected. Better support for this type of fields would be to allow for import/export of xml_ids, which would avoid the need for the model. opw 2087353 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#39591
Commit https://github.com/odoo/odoo/commit/c3c98e937e575853fe0b25fa6cb3c916e73fc591 introduced a z-index on parallax element to restrict the z-index -1 of the s_parallax_bg in the snippets... this was however a bad idea as it also restricts other positioned elements in there (like dropdown menus) making them go under other elements in the page. Fortunately, this z-index is in fact not needed at all since the z-index -1 mentioned above has been removed with another commit: https://github
Original PR description
Commit https://github.com/odoo/odoo/commit/c3c98e937e575853fe0b25fa6cb3c916e73fc591 introduced a z-index on parallax element to restrict the z-index -1 of the s_parallax_bg in the snippets... this…
Commit https://github.com/odoo/odoo/commit/c3c98e937e575853fe0b25fa6cb3c916e73fc591 introduced a z-index on parallax element to restrict the z-index -1 of the s_parallax_bg in the snippets... this was however a bad idea as it also restricts other positioned elements in there (like dropdown menus) making them go under other elements in the page. Fortunately, this z-index is in fact not needed at all since the z-index -1 mentioned above has been removed with another commit: https://github.com/odoo/odoo/commit/22745668cf66d802899dac526d810eba64b28c4b However, the z-index -1 was necessary to force the s_parallax_bg under static elements that go after it... and this was solved in 12.0 by making those relative elements. See snippet refactoring in 12.0 with https://github.com/odoo/odoo/commit/4dce6cc98b2b95a00249ac29245305e08f288e6c#diff-a50ffff96791f36c6dbe5c9273135e5aR783 This commit thus also contains a backport of that work. Forward-Port-Of: odoo/odoo#39599 Forward-Port-Of: odoo/odoo#39497
After deleting records from model 'ir.model.fields', make sure to not trigger recomputations based on those fields, as they have been removed from the database schema. Also shorten the deletion of 'ir.model.fields.selection' records: as they are deleted after 'ir.model.fields', most of them have already been deleted on cascade. Forward-Port-Of: odoo/odoo#39600
Original PR description
After deleting records from model 'ir.model.fields', make sure to not trigger recomputations based on those fields, as they have been removed from the database schema. Also shorten the deletion of 'ir.model.fields.selection' records: as they are deleted after 'ir.model.fields', most of them have already been deleted on cascade. Forward-Port-Of: odoo/odoo#39600
Forward-Port-Of: odoo/enterprise#6264
Original PR description
Forward-Port-Of: odoo/enterprise#6264
Steps to reproduce the bug: - Create an asset model - Duplicate the model in order to create a new model Bug: Odoo created a new asset instead of an asset model opw:2115454 Forward-Port-Of: odoo/enterprise#6501
Original PR description
Steps to reproduce the bug: - Create an asset model - Duplicate the model in order to create a new model Bug: Odoo created a new asset instead of an asset model opw:2115454 Forward-Port-Of: odoo/enterprise#6501
In the next case: 1. Create a vendor bill with the tax ``16%`` 2. Register the payment 3. Cancel the entry for cash basis In this case, how the entry is in draft not must be considered in the DIOT report. Forward-Port-Of: odoo/enterprise#6437
Original PR description
In the next case: 1. Create a vendor bill with the tax ``16%`` 2. Register the payment 3. Cancel the entry for cash basis In this case, how the entry is in draft not must be considered in the DIOT report. Forward-Port-Of: odoo/enterprise#6437
Forward-Port-Of: odoo/enterprise#6415
Original PR description
Forward-Port-Of: odoo/enterprise#6415