Update odoo 12.0 #10
Merged
Update odoo 12.0 #10
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In JS, the groupBy attribute is a list of strings The default_group_by key that is sometimes present in the XML views gets converted to a list at somepoint. Before this commit, the task action couldn't be used in the app Dashboard After this commit, it can OPW 1894751 closes odoo#27908
Steps to reproduce the bug: - Create a customer invoice I with an amount of 100$ and validate it - Register three payments P1 at 11/10, P2 at 12/10 and P3 at 13/10 - Click on button "Print" and the report displays the payments in the right order P3, P2, P1 - Click on button "Send by email" and click on the attachment with the report Bug: The report didn't display the payments in the same order, it displayed P1, P2, P3 opw:1888251 closes odoo#27895
Oversight of previous forward-port
"may be be void" -> "may be void" closes odoo#27919
The test was comparing a scheduled date was correctly computed. The runbot build 363053 failed because runbot12 is a bit slower and computed the delay in 2 seconds instead of the 1 previously tolerated. Increase the delta to 10 seconds. The delay is a matter of days. Having a difference of 1, 10 or even 100 seconds should be equivalent functionnaly. Having a 100 seconds delay could indicate a serious performance issue though...
The on_delete value on an ir.model.field did not reflect the value set on the field loaded in the registry Fixes odoo#24464 closes odoo#27906
The CRON job that sends email sends them in a LIFO order instead of a FIFO order which can lead to confusion when the order is important. Exemple, when updating multiple time an appointement, the last update should be the newest mail clients receive in their mail box which was not the case before this PR. opw-1888601 closes odoo#27888
* Make phantomjs logging clearer by logging within the test case's module, not odoo.tests.common. This way, a tour in e.g. point of sale is clearly logged as that, rather than be logged as odoo.tests.common.phantomjs and require hunting which module/test we happen to be in. * Clarify tagging causes for exclusion of selection of tests.
As the phantomjs project was suspended[1], there was a need to change the js test engine. Moreover, the engine was rather old and leading to non deterministic crashes. Chrome headless was choosen for simplicity and the long term vision of the devtools protocol [2]. The 'phantom_js' method still exists but will be deprecated in favor of 'browser_js' with the same parameters. In order to communicate with the browser, the python websocket-client package is needed. [1] ariya/phantomjs#15344 [2] https://chromedevtools.github.io/devtools-protocol/ closes odoo#25991
The account module needs to import Form from "tests.common" causing a traceback when websocket-client module is not installed. As this module is only required for the tests, there is no reason to add it to the "requirements.txt" file. With this commit, Odoo account can be installed even when websocket-client is not installed, in that case, the HttpCase tests that needs to run Chrome headless will be skipped with a warning. Closes: odoo#26404
When a Chrome headless test fails the browser is not cleaned and could lead to a mix with other tests when the same method is called. Also, the multiline assertions gives an unreadable message when the assertion fails. Finally, it happens that a thread does not have an 'url' attribute and lead to a crash when the logger tries to show the thread url. With this commit, the browser is cleaned, even on failure and the assertions are now one line. Closes: odoo#26432
Before starting a JS test/tour the _wait_ready method evaluates if the test is ready with a timeout of 10 sec. From times to times, it happens that the page is not ready after this timeout but the problem is hidden. In order to help fixing that kind of issue, the timeout is increased to 60 sec and a warning is logged to emphasis the fact that an issue exists. Also some unused imports are removed with this commit
Since chrome headless has been merged, js error messages are difficult to read: some information was missing or only displayed in full all log. All console.error() will now be displayed in build details, and will appear just before the python assertion. XMO's improvement will also be used on all log: Using module and classname of the class calling phantomJS. Also: some small improvements on error messages to make them easier to read Note: this commit also shown that some error were not detected: now we will fail in any case if js log an error.
When executing a very long HttpCase browser_js test, it happens that one of the chrome process PIPE is full (ie. clickEverywhere test). In that case, the communication with Chrome is blocked. With this commit the stdout and stderr of the Chrome process are redirected to /dev/null.
When an HttpCase browser_js test is started, the screencast is started and is discarded at the end of the test if no logfile was provided by the config. This behavior can impact the performances. With this commit, the screencast does not start at all if not needed.
In some situations, Chrome remote debugging is sending an empty list of opened tabs. In that case, an orphan Chrome process stays alive. With this commit, Chrome is stopped properly in those situations.
When Odoo receive a SIGXCPU (CPU time limit reached), it shuts down immediately. If a headless Chrome is running, it stays alive after the Odoo shutdown. With this commit, the signal is intercepeted and the Chrome browser is properly closed before shutting down the Odoo server.
When computing coverage, the tests are slowed down and the timeout is often exceeded. With this commit, HttpCase headless Chrome tests timeout is increased if coverage is detected.
When installing chromium using apt e.g apt install chromium-browser the executable is `chromium-browser`, not just `chromium`
On Ubuntu, the chromium executable is `chromium-browser`, On other distributions, such as debian, it's `chromium`. We therefore add another fallback
Typically if you use an onchange method to retrieve values on the server and convert them to write it will also try to write empty values like [(6, 0, [])] and this will crash as it has also the length of 3 but no dictionary but a list closes odoo#27937
Seems like something similar to odoo#17111 can happen on Python 2. The same change as odoo#17111 is a bit involved for -stable, but this looks pretty harmless. Probably fixes odoo#23781.
For unknown [1] reason, phantomjs starts to segfault when running qunit tests. Be radical with simply not using phantomjs anymore. [1] Any guidance on tracking the root cause may help...
When sending notifications by batch one notification email can be send up to 50 people. For one mail_mail entry to handle 50 emails can be sent as those are sent independently for each recipient. In some cases a bounce may occur while the whole batch of recipients is not completely mailed. In that case the mailgateway will update the notification status to bounced. When the cron finishes to send the whole batch of emails it tries to update the notifications of all recipients. However as a notification has already been updated due to the bounce we face a concurrent update, meaning the transaction is rollbacked. Emails have been sent but notifications are not considered as sent as they have not been updated accordingly. Next time the cron runs it will send the same batch again, with probably the same bounce and rollback. We could therefore face an email loop. This commit add test for this use case. This commit is linked to task ID 1893054.
The format function was missing for the percentage widget type, so `field_utils.parse[this.formatType]` (see [1]) resolved as `undefined` which is not a function and so raised an error when the user was trying to update the field. This PR add that parsing function. Both `xx%` and `0.xx` are understood by the parser and resolve to the correct float value. opw-1895979 [1] https://github.com/odoo/odoo/blob/e220721a8ee80c02fe5aba5ed8c9f3f4ae54ea97/addons/web/static/src/js/fields/abstract_field.js#L399 closes odoo#28431
Steps to reproduce the bug: - Let's consider three products P1(in Unit), P2(in kg), P3(in Unit) - Create a BOM kit for P1 whit 1kg of P2 and 1 Unit of P3 as components - Create a SO with P1 and validate it - Go to the shipment and validate Bug: An error was raised saying: The unit of measure kg defined on the order line doesn't belong to the same category than the unit of measure Unit defined on the product. Please correct the unit of measure defined on the order line or on the product, they should belong to the same category. PS: The quantity delivered on a SO line must only be computed for the product defined on the SO line. Otherwise with a BOM kit, the sum of all its components was done instead. opw:1905223 closes odoo#28460
- When creating an eCommerce cart using the Public User, the code tries to access all the sale orders linked to it. Depending on the count of sale orders linked to the partner, the loading can take a lot of time. To avoid this, we only search for the sale orders of connected users and we only retrieve the last one.
web_editor dirty elements are saved by calling the ir.ui.view `save()` method. As this method is called through call_kw _rpc on the ir.ui.view model, self is binded to the view which has the `id` sent in the request. In some cases, when editing a field for example, the id sent is the id of the field's record (eg: product.template for price field). In that case, the view binded on self will be the view with the id of the field's record being edited. If there is no ir.ui.view with the same ID as the field's record, self won't exists. This misbehavior resulted in no error luckily since we only use self to call ir.ui.view methods without ever using self properties. Since multi-website 47b00c5 overrided the `save()` method and used self.key it was crashing when the self record did not exists. This commit will fix that by doing the multi-website check only when it is a view and not a field that is being edited. (We know that if xpath is set) opw-1904637 Step to reproduce: - Go to a product on ecommerce, eg product.template 13013 - Edit the product price field, the oe-id attribut is 13013 - Delete the ir.ui.view that has the same ID than the product (13013) - Save -> It will crash since self is binded to "ir.ui.view(13013,)" but it does not exists and we try to access key closes odoo#28469
…tocomplete server fails Add a check to see if we're in test mode that returns an InsufficientCreditError to avoid failing other tests if partner_autocomplete server fails closes odoo#28324
Sometimes, a sale.order in the SALE state doesn't have a confirmed date, which can cause a traceback. To avoid this, when confirmation_date is null, use the write_date, which is never NULL when sale.order is in sale state. In migration, we will try to populate the confirmation date with the mail.message subtype. As ultimate fallback, we will take the write_date. closes odoo#28296
Before that, with "post at bank reconciliation option" activated on bank journal, the following scenarii did not work as expected: 1. When creating an invoice, making two payments for it, and then matching only one of them with a bank statement => the invoice was marked as 'paid' while it should have staid 'in payment' until the second payment gets a bank statement. 2. When directly reconciling a bank statement with an invoice for its full amount => the invoice staid in "in payment" state, while it should have been "paid" [IMP] account: add tests for the aforementioned cases closes odoo#28428
c5dc0b2 disabled send button on composer sent. But this is only needed for chatter composer, other composers directly send the message and are not refreshed asynchronously. So for other composer, the send button worked one time but then was disabled and the only way to sent was ENTER (on basic composer) or CTRL+ENTER (on extended composer). With this fix, disabling the button is done only for chatter composer. Also the behavior of not clearing the message if there was an error is introduced back. Without change in code, added test fails with: "Should keep unsent message in the composer on failure" (result: "") "Send button should be re-enabled on message post failure" (result: true) issue found when checking opw-1904029 closes odoo#28475
…tions at record update Create an automated action to create a new activity on update of a record (e.g. a CRM lead). At update, many fields recompute may be triggered, triggering as many write. Thus it would generate many activities. We simply do nothing if we are in a recompute. Coauthored by rco opw 1904156 closes odoo#28498
…l group is active Stock moves show a detailed operations icon if the tracking, locations, or consignment allow to be configured. However it did so on a per move basis, only displaying it if the considered move has some of these features. This fix makes it that the "detailed operations" icon is always displayed if at least one group of group_tracking_lot, group_stock_multi_locations, or group_tracking_owner is active, or the move is tracked, unless the move picking type already does show detailed operations. opw 1893106 closes odoo#28072
Odoo 12.0 does *not* officially support any python version below 3.5, but no effort had been made to gracefully announce this to the end user if they were to run Odoo in an unsupported python version. This is done because Odoo 12.0 uses py3-only constructs which can and will raise different errors if ran in python 2. With this patch, Odoo will display an appropriate error message and won't launch at all unless it is being run with python 3.5 or greater. closes odoo#28502
When the eCommerce /shop page was configured to use collapsible product categories, performing a search on a product whose eCommerce category was a child of another one produced an error. This was due to a typo made with odoo@8889d00 Closes odoo#28435 closes odoo#28532
Make the CoA template instantiates accounts and other records in batch. closes odoo#28480
also reference_type is removed from the model b5bb5bd closes odoo#28536
…aluate extra fields Suppose you are editing a SO to add a new line. Depending on the configuration, a sale order line wizard may open (e.g. if packages are activated). This wizard is a form view, opened from the tree view of the sale order lines. We have commit 8e51569 that adds extra fields from the originating view. (However it doesn't work if the other view is inlined, so we modify this part to add the extra field even in this case.) Then we need the field info from the origin view in the target view; we do so by extending the former with the content of the latter. opw 1904337 closes odoo#28441
The root user is now the sudoable superuser. The demo data should be over admin user and not root user. opw-1907486 closes odoo#28534
Before this commit, RTL on frontend was only enabled for connected user. To have RTL, we add the direction on the element, and the RTL version of the stylesheet for the applicable languages are generated thanks to rtlcss. opw-1892757 closes odoo#28434
From 12.0 tips product from pos moduleis not available in PoS by default closes odoo#28569
When opening the customize menu as soon as the page became visible, an RPC crashed and the toggable options did not appear anymore. This happened: 1) DOM is ready. 2) The user click on the menu. 3) At the same time, the customize menu is initialized (`attachTo`), its event handlers are bound and the async `willStart` method is called. 4) The event handler for the user click is called... and crashes as requires a variable which would have been set in the `start` method. The bug did not appear in previous versions as the handler was not using the standard system and bound the event handler "by hand" in the `start` method. Maybe `attachTo` should not bind event handlers before the `willStart` method is completed; this would be a subject for the master branch. This commit solves the problem by setting the required variable in the `willStart` method instead of the `start` method. closes odoo#28578
Steps to reproduce the bug: -Activate the option "Prices computed from formulas (discounts, margins, roundings)" on the pricelist. -On the pricelist, click on Edit and select a product item. -Select "Formula" as Compute price Bug: The fields price_surcharge and price_max_margin were not fully displayed. Introduced by: odoo@9de1bc0#diff-e0b4a29125b1abccb0318498970342fcL61 opw:1907217 closes odoo#28514
Compatibility: rebuilding a correct modal from user database content. Since the first version, the modal is saved in databases directly but has never used a correct structure. While it was working with BS3, it is not with BS4. This was breaking the design and prevented the modal to be able to close. task-1889341 closes odoo#28589
For the special case of is_blacklisted, and due to the size of the tablers to handle, it's faster to filter some records rather than searching the whole res.partner table closes odoo#28028
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.