[10.0] Update from upstream up to b144e09a10e7084cb96c2b420e6b7713834f7866 - #918
Conversation
…field Fixes #17312
Error thrown by google request is an urllib2.HTTPError that can be read and loaded in JSON. However in some cases the result of the read may be void or not JSON-ready. This was causing a crash in the error management and hid the actual issue. This commit tries to read and JSON-load the error but fall back on simply displaying the raw error in case of issue when handling it. Closes #17308 .
…ting event Google API: recurrence | Odoo field: recurrency Closes #17307 .
Portal users do not have access on invoices or invoice lines. However when viewing an online quotation in website_portal_sale some computation is performed based on invoices and invoice lines. We therefore iterate on invoice and invoice lines as superuser as we do not want to grant any additional access on those models for portal users.
The context is not in the kwargs when the integrity error is raised from a rpc request. So the user lang was lost and the sql error message was not translated. The part treating the callable message in sql error is depracated. opw:743259
In carousel snippet, the target element for background snippet option is being changed manually. So for the new target, we have to rebind the associated events that were bound in `start` function of the snippet option. For that, some code is extracted from the `start` function and is used to rebind necessary events for new targets. In particular, this was preventing the carousel slides' backgrounds to be automatically removed when a background-color was selected.
An archived forum could still be posted in, something better should be done in the next version (eg. website published present on a lot of record type) but as of 10.0 just this improvement is done. opw-745510 closes #17365
opw-745872
- Create a work center with a capacity of 1, an efficiency factor of 100% and a cost per hour of 40$ - Create a routing with two operations: one with a fixed duration of 30:00 minutes (OP1) and another with a duration computed on real time but with a default of 30:00 minutes (OP2) - Create a component with UOM "m" and a cost of 10$ - Create a finished product with an associated BoM - The BoM has a first line with 0.8m of component in the OP1 and a second line with 0.4m of component in the OP2 - Activate the Compute from BoM option on the finished product - The proposed cost is 32$ Expected cost: 52$ (30 minutes @40$/hour + 30 minutes @40$/hour + 1,2m @10$/m) We divide the WC cost by the number of operations, which does not make sense. opw-741032
Use the field `time_cycle` for cost computation, which takes into account the routing configuration (fixed time of computed based on previous operations).
When the user zooms with the browser, the bottom left pads are misaligned for some zoom levels. By slightly reducing the width of the action pad, this can be solved for all acceptable zoom levels. opw-745074
The attribute filters based on all products matching current domain was limited to the first page of result only. If all the products of the current page had no variant, no filter was displayed. Closes #17361
This try except block was added in another era, where the piece of code in the block was far less ambitious (and not for good reason since adding a try except block because of a malformed mail template seems overkill). Even worse, this block actually prevented errors from bubbling, which could have adverse effects. Example: a long transaction confirmation (several seconds since it implies S2S communication, invoice creating/validation, etc.) is rollbacked because a mail message is recorded on the quote during the processing time. The quote confirmation then crashes because of a concurrent update error in postgres. This try except block does not re-raise the error, which means that instead of retrying the operation like the ORM would normally do, we have an incomplete traceback in the system (since the error message crashes itself) and the transaction is not validated (as far fetched as it may seem, this is in fact how this bug was discovered). This try-except block offers no gain in error logging (on the contrary, since we have lost the initial error-causing statement) and prevent the orm from correctly managing errors. This commit removes it and let the orm handle the errors like a grown up man; either crash for real (because it should crash to know if there's a problem) or retry the transaction if it's a serialization issue. opw-744629
If you have two invoices with a same product, - one having 1 unit of a product, - the other -1 unit of a product, The sum of these quantities will be 0, and it will lead to a division by zero in the former sql request. The nullif should be applied on the sum, not on the line quantity. opw-745073
When disabling the customer portal in the general settings (or uninstalling the `portal_sale` module directly), the model `sale.order` no longer has a method `get_signup_url`, and it therefore leads to the fail of the email template rendering which is still referencing this method. Besides, the `access_url` is actually used only if `is_online` is True, (see the `% if is_online:` few lines later) and in this case `get_signup_url` was not used at all. Therefore, we can assume `None` is a good alternative, as the resul of `get_signup_url` was actually no longer used. opw-710481
- Create an excluded tax of 20 % - Create a customer invoice of 1000 - Create a payment of 900 - Make the matching between the invoice and the payment: Write-off of 83.33, with the 20 % tax Error: 'Cannot create unbalanced journal entry' After commit 89cbef8, the tax are by default not created automatically anymore. We should make sure to pass the context key `apply_taxes`. opw-744266
On a pricelist, if multiple rules were set with the same set of rules condition, the choice of which rule/item is used was random, according to the postgres database state. Adding the `id` in the order force to always use the same rule/item (the first that was created). opw-744865
In case of a MemoryError, there is no error message, the user gets a "Database restore error: " without any details. Instead fallback to the repr. This way, a wrong password is "Database restore error: Access denied" and a memoryerror "Database restore error: MemoryError()" Closes #17393
Closes #17846
If `product_category_all` is of type view, the installation of some modules, such as delivery, crashes. opw-749550
In an invoice, the modification of an invoice line triggers the complete recomputation of the tax lines. However, it also deletes any manual taxes that could have been set (e.g. on vendor bills). Courtesy of @jjscarafia Closes #17885 opw-749323
- Use the form builder to send an email - Customize the snippet to include the subject and the body - Send a mail => The subject is not included in the email This is because the subject is filtered out and considered as a blacklisted field. It happens because `mail.mail` inherits from `mail.message`. The field property `website_form_blacklisted` is set to: - `True` for `mail.mail` - `False` for `mail.message` Since we go through all inherited models, the property on `mail.mail` is overriden by the property on `mail.message`. It is actually not necessary to go through all inherited models, since in the case of `inherits`, we copy the fields of the inherited model to the target model. The check is simplified by only checking the fields of the current model. Based on work of @nla-odoo opw-748926
When a model contains a field translatable which has a unique constrain, it is impossible to copy a record. Indeed, the unicity constrain is always triggered, even if the model takes in charge the overriding of the copy method to avoid duplication. Introduced with commit ce7f31b, with the goal to target only XML/HTML translations. We apply this behavior in case of a callable translate property, to target only the desired problematic use case. opw-749481
Before 036ccbe when writing on qweb field with default language mi_SC: - writing in mi_SC: wrote on the current res.user language (wrong) - writing in en_US: wrote on en_US translation (right) - writing in de_DE: wrote on de_DE translation (right) but after 036ccbe: - writing in mi_SC: wrote on mi_SC (right) - writing in en_US: wrote on mi_SC (wrong) - writing in de_DE: wrote on mi_SC (wrong) With this commit, this drawback is also solved by keeping the lang in context if present. opw-746776 closes #17917
If the website default language is not en_US, qweb fields are not translatable in en_US (and thus can't be translated) because: - the code expected en_US to be the default language. - there was a error in website _dispatch opw-746776 closes #17939
This commit closes PR #17942
…pare Typo in previous condition. 'vat' in partner is always True.
The old code don't resize correctly if you use params in request. because if '200' > 500 => return True Now we force the casting to int to be sure to compare apple to apple. before: /web/image/<id>?height=100 => don't return an image with height=100px after: /web/image/<id>?height=100 => return now an image with height=100px
…h (#17969) When opening the reconciliation widget, there are two queries that are done, The first one is to find a move line that perfectly match the statement line and is done in SQL for performance issue. The second one is a search with a domain to find all the lines that could be used in that reconciliation. 1) There was a mismatch between the two. The domain fetches lines that have a payment_id while the SQL query does not. Which is inconsistent 2) In some case, we did not find a perfect match on the amount using the SQL query because of a rounding error. Example is for amount 3,3. In python: 3,3 is represented like this 3,3000000000003 and doing a float_round of that value still returns 3,3000000000003 Since we want to match on an exact amount, using float_repr is needed to fix that error
The route /shop and /shop/product did not used the same context. The partner is set in the shop but not in the product page which may lead to a different pricelist to be applied. opw-746729
b3098d7 to
9d8746e
Compare
|
Another try with 9d8746e3a7ff906703fcb0656aa8aab52a4cfcbe. |
|
Hi @pedrobaeza, Finally travis went green on this. |
|
Can you please specify the conflict resolution you have made? |
Conflicts:
odoo/tools/convert.py
Resolution:
index 368fcc3..82cc108 100644
--- a/odoo/tools/convert.py
+++ b/odoo/tools/convert.py
@@ -252,8 +252,6 @@ form: module.record_id""" % (xml_id,)
modcnt = self.env['ir.module.module'].search_count([('name', '=', module), ('state', '=', 'installed')])
assert modcnt == 1, """The ID "%s" refers to an uninstalled module""" % (xml_id,)
- if len(id) > 64:
- _logger.error('id: %s is to long (max: 64)', id)
openupgrade_log.log_xml_id(self.cr, self.module, xml_id)
|
The only conflict was $ git diff --cached -- odoo/tools/convert.py
diff --git a/odoo/tools/convert.py b/odoo/tools/convert.py
index 368fcc34f56..82cc1084445 100644
--- a/odoo/tools/convert.py
+++ b/odoo/tools/convert.py
@@ -252,8 +252,6 @@ form: module.record_id""" % (xml_id,)
modcnt = self.env['ir.module.module'].search_count([('name', '=', module), ('state', '=', 'installed')])
assert modcnt == 1, """The ID "%s" refers to an uninstalled module""" % (xml_id,)
- if len(id) > 64:
- _logger.error('id: %s is to long (max: 64)', id)
openupgrade_log.log_xml_id(self.cr, self.module, xml_id)
def _tag_delete(self, rec, data_node=None, mode=None):Should I |
9d8746e to
52a087b
Compare
|
Well, I made another push. Let's hope travis gets it. |
|
Green! I can't believe! 😄 |
|
OK, thank you very much for the effort! Merging. |
|
Shouldn't a new migration analysis be run to update the analysis files? 🤔 |
|
Not in theory, as the stability rule from Odoo forbids to change the DB layout once the version is published. The other time was different, as the analysis was done before the v10 release, and they said that the freeze was done, but it was not really frozen at all. Even that, on a critical bug, I remember a change in DB layout after the release, but on version 7 or 8, so it's very improbable that there are changes right now, but if you want to try and you have all prepared for the analysis, you can do it to be sure. |
In the same accord as PR #895 it can be beneficial to have a updated 10.0 branch.