Skip to content
Snippets Groups Projects
  1. Jan 27, 2019
  2. Jan 25, 2019
    • Denis Ledoux's avatar
      [IMP] api: improve storing performance of the api cache · 8fb76c42
      Denis Ledoux authored
      This revision moves the `cache_key` to the first level
      dict of the cache, instead of the last one.
      
      Doing so, we reduce the number of times the reference
      to the cache key is stored in the dict.
      
      For instance,
      for 100.000 records, 20 fields and 2 env (e.g. with and without sudo)
      formerly, there were 100.000 * 20 * 2 occurences of cache key references
      now, there is only 2 references.
      
      Storing references to an object consumes memory.
      Therefore, by reducing the number of object references
      in the cache, we reduce the memory consumed by the cache.
      Also, we reduce the time to access a value in the cache
      as the cache size is smaller.
      
      The time and memory consumption are therefore improved,
      while keeping the advantages of revision
      d7190a3f
      which was about sharing the cache of fields
      which do not depends on the context, but
      only on the cursor and user id.
      
      This revision relies on the fact there are less different references
      to the cache key then references to fields/records.
      Indeed, this is more likely to have 100.000 different records stored
      in the cache rather than 100.000 different environments.
      
      Here is the Python proof of concept that was used
      to make the conclusion that setting the cache_key
      in the first level dict of the cache is more efficient.
      ```Python
      import os
      import psutil
      import time
      
      from collections import defaultdict
      
      cr = object()
      uid = 1
      fields = [object() for i in range(20)]
      number_items = 500000
      
      p = psutil.Process(os.getpid())
      m = p.memory_info().rss
      s = time.time()
      
      cache_key = (cr, uid)
      cache = defaultdict(lambda: defaultdict(dict))
      for field in fields:
          for i in range(number_items):
              cache[field][i][cache_key] = 5.0
              # cache[cache_key][field][i] = 5.0
      
      print('Memory: %s' % (p.memory_info().rss - m,))
      print('Time: %s' % (time.time() - s,))
      
      ```
      - Using `cache[field][i][cache_key]`:
         - Time: 3.17s
         - Memory: 3138MB
      - Using `cache[cache_key][field][i]`:
         - Time: 1.43s
         - Memory: 756MB
      
      Even worse, when the cache key tuple is instantiated inside the loop,
      for the former cache structure (e.g. `cache[field][i][(cr, uid)]`),
      the time goes from 3.17s to 25.63s and the memory from 3138MB to 3773MB
      
      Here is the same proof of concept, but using the Odoo API and Cache:
      ```Python
      import os
      import psutil
      import time
      
      from odoo.api import Cache
      
      model = env['res.users']
      records = [model.new() for i in range(100000)]
      
      p = psutil.Process(os.getpid())
      m = p.memory_info().rss
      s = time.time()
      
      cache = Cache()
      char_fields = [field for field in model._fields.values() if field.type == 'char']
      for field in char_fields:
          for record in records:
              cache.set(record, field, 'test')
      
      print('Memory: %s' % (p.memory_info().rss - m,))
      print('Time: %s' % (time.time() - s,))
      ```
      - Before (`cache[field][record_id][cache_key]` and cache_key tuple instantiated in the loop):
         - Time: 4.12s
         - Memory: 810MB
      - After (`cache[cache_key][field][record_id]` and cache_key tuple stored in the env and re-used):
         - Time: 1.63s
         - Memory: 125MB
      
      This can be played in an Odoo shell, for instance
      by storing it in `/tmp/test.py`, and then
      piping it to the Odoo shell:
      `cat /tmp/test.py | ./odoo-bin shell -d 12.0`
      
      closes odoo/odoo#29676
      
      closes odoo/odoo#30554
      8fb76c42
    • Denis Ledoux's avatar
    • Raphael Collet's avatar
      f9582bf1
    • Hetal Dhanak's avatar
      [FIX] web: date filter operators less than greater than · 1dbef66b
      Hetal Dhanak authored
      Before this commit, in the filter, when using a custom filter with a
      date field, the operators "is after" and "is before" were set to execute
      "is after or equal" and "if before or equal" respectively. That means it
      includes in the results, records with the same date as the filter.
      
      Now, the operators 'is after' and 'is before' won't include the records
      with the same date as the filter. And the operators 'is after or equal'
      and 'is before or equal' will include the records with the same date as
      the filter.
      
      Fixes #29868
      OPW-1921756
      
      closes odoo/odoo#30560
      1dbef66b
    • jev's avatar
      [FIX] mail: activity, crash when activity type is null · a4a3bfd3
      jev authored
      When activity_type_id is null on an activity
      marking it as 'done and schedule schedule next' crashed
      
      OPW-1928989
      
      closes odoo/odoo#30522
      a4a3bfd3
  3. Jan 17, 2019
  4. Jan 24, 2019
  5. Jan 23, 2019
  6. Jan 22, 2019
    • Nicolas Martinelli's avatar
      [FIX] sale: taxes and untaxed amount · b95affa3
      Nicolas Martinelli authored
      - Create a SO, do not set a partner
      - Add a product with a tax
      
      The untaxes amount as well as the taxes remain 0.0.
      
      This is because there is no pricelist, therefore no currency.
      
      There is actually no need of rounding explicitly since these are
      monetary fields which will be rounded automatically.
      
      opw-1931796
      
      closes odoo/odoo#30450
      b95affa3
  7. Jan 17, 2019
    • Christophe Simonis's avatar
    • Christophe Simonis's avatar
      17adccd9
    • wan's avatar
      [FIX] account: journal dashboard graph wrong value · 50bae1c0
      wan authored
      OPW 1918926
      
      Current behavior:
        The sql query groups by date,id in a intermediary table instead of the result. This allows to get data in the wrong order if the statements were not produced sequentially. The fill values are computed in the wrong order and may override correct values.
      
      Desired behavior:
        There is no override of the values correctly computed.
      
      closes odoo/odoo#29936
      50bae1c0
    • Lucas Perais (lpe)'s avatar
      [FIX] base: merge contacts linked to by an o2m field with caps · ba39efdf
      Lucas Perais (lpe) authored
      Define a field on a model as:
      - o2m to res.partner
      - the field's column, hence its name, has capital letters in it
      (studio does that)
      
      create two objects of that class, each one linked to a different partner with the new o2m
      
      merge the partners
      
      Before this commit, the object linked to the second partner, was deleted
      This was because merge partner sql requests did not quote the column name
      
      After this commit, the second object still exists
      
      This commit is tested in v12.0 with PR #30300 only. In v10.0 it is not testable as
      the model concerned is in CRM, and that no new fields in business modules can be added in stable
      
      OPW 1925060
      
      closes odoo/odoo#30301
      ba39efdf
  8. Jan 15, 2019
    • Denis Ledoux's avatar
      [FIX] ir_ui_view: do not change view mode when just changing the inherit · a4096276
      Denis Ledoux authored
      Some views have the primary mode while having an inherit_id view
      In such views, if the user wants to change the inherit_id,
      the mode must remain primary.
      
      The use case behind this is a user who want to change
      the inherit_id view of the view
      product.product.form (product.product_normal_form_view)
      to another view.
      This view is in primary mode while having an inherit_id
      (product.product_template_form_view).
      In such a case, the primary mode must remain,
      otherwise the view will no longer be opened by default
      when opening a product.
      Indeed, when searching the default form view of a model,
      it only searches for primary mode views for this model.
      
      The `all` is there because this is an `api.multi` method.
      We could consider adding a `self.ensure_one`,
      but it breaks the API if someones calls this method with multiple records.
      This is likely to happen, as this method is used
      in `write` which is likely to be called with multiple records.
      
      In my opinion, in master, this should be replaced by an
      onchange so the user can see the change of mode
      when he adds or remove an inherit_id for a view.
      
      opw-1916324
      
      closes odoo/odoo#30241
      a4096276
  9. Jan 22, 2019
  10. Jan 18, 2019
  11. Jan 15, 2019
  12. Jan 16, 2019
    • Nicolas Martinelli's avatar
      [FIX] product: unwanted attribute values in name · 180ace7b
      Nicolas Martinelli authored
      - Create the following attributes with values:
        Size: S, M, L, XL
        Color: Black, White
      - Create a product template with the following attribute values:
        Size: S, M, L, XL
        Color: Black
      
      The `name_get` of `product.product` returns `Name (SIZE, Black)` while
      it should only return `Name (SIZE)`.
      
      When using `attribute_id.value_ids`, the list of values contains all
      possible values of the attribute, not only the values which apply to the
      given product. In this case, it contains 'Black' and 'White', therefore
      the condition `> 1` is verified and the attribute is kept for display.
      
      We go back to the original filtering, and add `attribute_line_ids` in
      the list fields read in order to avoid prefetching.
      
      opw-1922140
      opw-1922447
      
      closes odoo/odoo#30273
      180ace7b
    • Joren Van Onder's avatar
      [FIX] point_of_sale: allow refunds on non-cash journals · 302d8a52
      Joren Van Onder authored
      Cherry pick of 5b769650 in version 11.0
      
      A customer can pay an order with a non-cash journal (e.g. a credit
      card through a stand-alone terminal).
      
      When this order has to be refunded later it should be possible to do
      so on that same journal.
      
      Some code prevented this from happening, notably a check in
      order_is_valid which explicitly prevented this for an unknown
      reason. There is no explanation in the
      commit (4647f896) introducing that.
      
      This commit allows the following:
      
      1. input what you want to refund with a negative qty
      2. click 'Payment'
      3. click the Credit Card (type Bank) journal
      4. (amount is auto-populated)
      5. click 'Validate'
      
      opw-805302
      opw-1913731
      
      closes odoo/odoo#30218
      302d8a52
    • Nicolas Martinelli's avatar
      [FIX] account: bank statement with many AML · 614babd1
      Nicolas Martinelli authored
      - Create a bank statement with more than 80 lines (therefore more than
        80 AML)
      - Reconcile the lines
      - Go back to the bank statement, and try to add a new line
      
      An error arise:
      "You cannot do this modification on a posted journal entry, you can just
      change some non legal fields"
      
      The error arise on the `move_line_ids` field on which the web client
      tries to write.
      
      Actually, this field is hidden since it is only used in the domain of a
      stat button. We can make it read-only.
      
      opw-1921138
      
      closes odoo/odoo#30266
      614babd1
    • Iryna Vyshnevska's avatar
      [CLA] signature for ivyshnevska · 92e4c4c3
      Iryna Vyshnevska authored
      Backport to 10.0 of 3b14a7da
      
      closes odoo/odoo#30090
      92e4c4c3
    • Manuel Vázquez Acosta's avatar
      [FIX] survey: don't disclose the survey via print · 6ac32c65
      Manuel Vázquez Acosta authored
      To avoid bigger changes, only verify if the login is required.
      A proper refactoring has been implemented in master at 9771fdfe
      
      Closes odoo/odoo#30166
      6ac32c65
  13. Jan 14, 2019
Loading