Skip to content
Snippets Groups Projects
  1. May 12, 2021
  2. May 11, 2021
    • Florent de Labarre's avatar
      [FIX] mail: impossible to update email of partner on large database · 2c6e744b
      Florent de Labarre authored
      
      On large database with million of channel made by one partner.
      When you try to update the email of partner, it take lot of time (CPU time limit).
      
      closes odoo/odoo#70436
      
      Signed-off-by: default avatarRaphael Collet (rco) <rco@openerp.com>
      2c6e744b
    • Florent de Labarre's avatar
      [FIX] mail: impossible to update image of partner on large database · 9dcecc0e
      Florent de Labarre authored
      On large database with million of messages made by one partner.
      When you try to update the image of partner, it take lot of time (CPU time limit).
      9dcecc0e
    • Donatas's avatar
      [FIX] purchase_stock: PO line related stock moves getting stuck · c347f679
      Donatas authored
      
      When purchase order line is removed, related stock moves procure method stays as "Advanced" which doesn't allow reservation from stock
      
      closes odoo/odoo#70643
      
      X-original-commit: a474108d
      Signed-off-by: default avatarWilliam Henrotin <Whenrow@users.noreply.github.com>
      c347f679
    • Denis Ledoux's avatar
      [FIX] account: speeds up `account.payment` deletion · 29a9cf98
      Denis Ledoux authored
      
      The deletion of `account.payment` were slowed down
      because of the missing index
      
      ```
                                                                                        QUERY PLAN
      -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
       Delete on account_payment  (cost=20.37..44.45 rows=10 width=34) (actual time=0.449..0.450 rows=0 loops=1)
         ->  Nested Loop  (cost=20.37..44.45 rows=10 width=34) (actual time=0.383..0.404 rows=10 loops=1)
               ->  HashAggregate  (cost=19.95..20.05 rows=10 width=32) (actual time=0.378..0.380 rows=10 loops=1)
                     Group Key: "ANY_subquery".id
                     Batches: 1  Memory Usage: 24kB
                     ->  Subquery Scan on "ANY_subquery"  (cost=0.42..19.92 rows=10 width=32) (actual time=0.035..0.371 rows=10 loops=1)
                           ->  Limit  (cost=0.42..19.82 rows=10 width=4) (actual time=0.032..0.365 rows=10 loops=1)
                                 ->  Nested Loop  (cost=0.42..186848.76 rows=96312 width=4) (actual time=0.031..0.364 rows=10 loops=1)
                                       ->  Seq Scan on account_payment_pre_backup pay_backup  (cost=0.00..14763.48 rows=277317 width=4) (actual time=0.015..0.086 rows=53 loops=1)
                                             Filter: ((state)::text <> ALL ('{draft,cancelled}'::text[]))
                                             Rows Removed by Filter: 166
                                       ->  Index Scan using account_payment_pkey on account_payment pay  (cost=0.42..0.62 rows=1 width=4) (actual time=0.005..0.005 rows=0 loops=53)
                                             Index Cond: (id = pay_backup.id)
                                             Filter: (move_id IS NULL)
                                             Rows Removed by Filter: 1
               ->  Index Scan using account_payment_pkey on account_payment  (cost=0.42..2.44 rows=1 width=10) (actual time=0.002..0.002 rows=1 loops=10)
                     Index Cond: (id = "ANY_subquery".id)
       Planning Time: 0.294 ms
       Trigger for constraint account_move_line_payment_id_fkey: time=1.236 calls=10
       Trigger for constraint account_payment_sale_order_rel_account_payment_id_fkey: time=0.195 calls=10
       Trigger for constraint credit_token_payment_id_fkey: time=1.308 calls=10
       Trigger for constraint payment_transaction_payment_id_fkey: time=0.288 calls=10
       Trigger for constraint account_invoice_payment_rel_payment_id_fkey1: time=0.191 calls=10
       Trigger for constraint account_move_payment_id_fkey: time=6015.799 calls=10
       Trigger for constraint account_payment_account_bank_statement__account_payment_id_fkey: time=0.444 calls=10
       Execution Time: 6019.988 ms
      ```
      
      upg-12139
      
      closes odoo/odoo#70712
      
      Signed-off-by: default avatarDenis Ledoux (dle) <dle@odoo.com>
      29a9cf98
    • Nicolas Lempereur's avatar
      [FIX] sale: no show single novariant attribute in configurator · 23f95f05
      Nicolas Lempereur authored
      
      A product with single novariant attribute is normally not shown.
      
      But in the configurator modal it was shown and then added in the product
      description when doing exactly the same scenario (add the product) than
      without the configurator.
      
      With this changeset, we add is_single attribute and only add a no_create
      variant if it is not a single value or a custom value.
      
      opw-2494331
      
      closes odoo/odoo#70680
      
      X-original-commit: 9bd32f2a
      Signed-off-by: default avatarNicolas Lempereur (nle) <nle@odoo.com>
      23f95f05
    • Thibault Delavallée's avatar
      [FIX] phone_validation: add country trigger on sanitize phone computation · f593cdab
      Thibault Delavallée authored
      
      If country is updated on a record inheriting from mail.thread.phone
      its sanitized number should be computed again. Indeed without this
      trigger it is not computed and may lead to inconsistencies between
      phone numbers and sanitized number.
      
      Task ID-2528169
      
      closes odoo/odoo#70684
      
      Signed-off-by: default avatarThibault Delavallee (tde) <tde@openerp.com>
      f593cdab
    • Thibault Delavallée's avatar
      [FIX] crm: correctly compute phone_sanitized without having crm_sms installed · 4b0c5511
      Thibault Delavallée authored
      Currently phone_sanitized computation on lead model works only if crm_sms
      is installed. Indeed an override of ``_phone_get_number_fields`` is missing.
      However ``_sms_get_number_fields`` coming with ``crm_sms`` and its ``sms``
      dependency hides the issue as those modules are auto-install. However if
      ``crm_sms`` is uninstalled phone_sanitized is not correctly computed anymore.
      
      Task ID-2528169
      Oversight of odoo/odoo#45315
      4b0c5511
    • Florent de Labarre's avatar
      [FIX] website : prevent bad query · d0db9849
      Florent de Labarre authored
      
      In database with front end, there are lot of bad query like this:
      bad query: UPDATE "website_visitor" SET "timezone"='Europe/Paris',"write_uid"=116,"write_date"=(now() at time zone 'UTC') WHERE id IN (15414)
      
      closes odoo/odoo#70507
      
      Error: Could not serialize access due to concurrent update
      Signed-off-by: default avatarThibault Delavallee (tde) <tde@openerp.com>
      d0db9849
  3. May 10, 2021
    • William Henrotin's avatar
      [FIX] mrp: split call to write on stock move · d1e49723
      William Henrotin authored
      
      You can, in a production order, change the quantity done of a stock move
      raw and change its initial demand ('To Consume' field) in the same
      transaction. This can lead to some issue as changing the quantity done
      will update the stock move line and changing the initial demand will
      unreserve the stock move thus impacting the stock move lines too.
      
      This commit will split the values to update of a stock in move in case
      the two fields have to be updated. First the stock move lines, then the
      initial demand.
      
      This commit also remove the default_product_uom_qty in the move_raw_ids
      fields. This ensure the onchanges do not create/edit any stock move lines
      with some reserved quantity.
      
      opw : 2451298
      
      closes odoo/odoo#69377
      
      Signed-off-by: default avataragr-odoo <agr-odoo@users.noreply.github.com>
      d1e49723
  4. May 11, 2021
  5. May 10, 2021
    • Raf Geens's avatar
      [IMP] hw_drivers: Document pitfalls of update_iot_devices logic · 8c584aa8
      Raf Geens authored
      
      closes odoo/odoo#70079
      
      Related: odoo/enterprise#18034
      Signed-off-by: default avatarQuentin Lejeune (qle) <qle@odoo.com>
      8c584aa8
    • Raf Geens's avatar
      [FIX] hw_drivers: InterfaceMetaClass violates CPython constraints and breaks import · edffdd10
      Raf Geens authored
      Currently, none of the classes derived from Interface use `super`. If
      it's added, for example by adding this to `SocketInterface`:
      
      ```
      def __init__(self):
          super().__init__()
      ```
      
      , a deprecation warning will appear in Python 3.6 and 3.7:
      
      ```
      2021-04-30 13:14:25,000 24736 WARNING ? py.warnings: /home/pi/odoo/addons/hw_drivers/iot_handlers/interfaces/SocketInterface.py:11: DeprecationWarning: class not set defining 'SocketInterface' as <class 'SocketInterface.py.SocketInterface'>. Was classcell propagated to type.new?
        class SocketInterface(Interface):
      ```
      
      In Python 3.8 this is no longer a warning and becomes a `RuntimeError`.
      
      The reason this happens is that `InterfaceMetaClass` caches the results
      of the `__new__` calls it does in `interfaces`. CPython's data model
      specifies that when calling `__new__`, the cell for `__class__` needs to
      be passed along to the parent class: https://docs.python.org/3/reference/datamodel.html#creating-the-class-object .
      
      See https://docs.python.org/3/c-api/cell.html for a definition of what
      a cell is.
      
      Because of the caching, this doesn't happen when `__new__` is called
      multiple times for the same class. In the case of the `SocketInterface`
      example, `__new__` is called twice: first when it's imported directly by
      `load_iot_handlers` (https://github.com/odoo/odoo/blob/841c016913a87133bf7257c62ae5f6bf7d99e06d/addons/hw_drivers/main.py#L81)
      and second when `IngenicoDriver` imports it. The `__class__` cell is
      different each time in that case. With the caching present, this means
      the second cell isn't propagated correctly, resulting in the warning /
      error.
      
      After `load_iot_handlers` has finished, the `Manager`'s `run` method
      iterates over `interfaces`, instantiating and starting the loaded
      classes. Because of this, simply removing the caching appears to be
      sufficient to avoid the issue while keeping the end result the same.
      
      This issue was encountered while forward-porting a V13 PR, which adds a
      `super` use to `SocketInterface`. The issue didn't occur in V13, because
      the metaclass doesn't have a cache there.
      
      I found a second problem resulting from the caching. I had noticed that
      the `socket_devices` dict the `IngenicoDriver` had access to did not
      have the same contents as the one the `SocketInterface` was operating
      on. This means that whenever you called the `disconnect` function on the
      `IngenicoDriver`, which deletes its entry from `socket_devices`, it will
      always fail. The bluetooth driver seems to be impacted by the same.
      
      It turns out the reason for that is how downloaded modules get loaded in
      `load_iot_handlers`. That logic (using `exec_module`) doesn't actually
      import the module, it just executes the code (registering the interfaces
      and drivers as a side-effect). This means the module doesn't get cached
      in sys.modules. That means that when another module (`IngenicoDriver`)
      imports that same module (`SocketInterface`), Python will execute the
      entire contents again, in this case effectively replacing socket_devices
      with a new dict, which `IngenicoDriver` gets a reference to, while the
      `SocketInterface` thread that runs is still using the old reference to
      the original dict. Meaning the two are out of sync. See
      https://docs.python.org/3/reference/import.html#the-module-cache for
      details on how the import caching works.
      
      The reason the classes get out of sync is because the metaclass doesn't
      update interfaces when the second actual import happens, so the
      `SocketInterface` class that gets instantiated holds a reference to the
      old `socket_devices` dict. Removing the caching removes that problem as
      well. If there's no caching, both the `SocketInterface` class and
      `IngenicoDriver` will hold a reference to the same instance of
      `socket_devices`.
      edffdd10
    • Raf Geens's avatar
      [FIX] hw_drivers: Start iot_devices thread after registering it · 6c24d30c
      Raf Geens authored
      This commit was originally part of a larger commit related to an
      Ingenico double connection deadlock bugfix in V13, but in V14 most of
      the related code has moved to enterprise. When a driver thread is
      running, calling `disconnect` on it will delete it from iot_devices. If
      the driver thread gets added to iot_devices in the Interface thread
      after starting it, this means there is a tiny window of time where
      `disconnect` could be called and the thread wouldn't be in iot_devices
      yet, resulting in an exception. This change puts the driver thread in
      iot_devices before starting it, avoiding that scenario and the need to
      check in `disconnect` for that happening.
      6c24d30c
    • Thomas Beckers's avatar
      [FIX] account_edi_facturx: avoid crash when no edi attachment · e1659f8a
      Thomas Beckers authored
      
      When we get the values to embed to pdf, these values can be False if
      there is no edi attachment on the account_move so try to assign something
      to 'values' will fail.
      
      Now there is a check before assignment.
      
      opw-2526280
      
      closes odoo/odoo#70613
      
      Signed-off-by: default avatarJosse Colpaert <jco@openerp.com>
      e1659f8a
  6. May 07, 2021
  7. May 10, 2021
    • Joseph Caburnay's avatar
      [FIX] point_of_sale: group invoice receivable lines by partner · fa2fb9f7
      Joseph Caburnay authored
      
      Acronyms:
      
      SRL : receivable lines in the session's account move that balances
      the receivable lines in the session's invoices
      IRL : receivable lines of the invoices in the pos session
      
      When closing a pos session, a single account move is created to capture
      all the transactions, but, invoices are kept (each is an account move).
      During the construction of this single account move, SRLs are
      reconciled with IRLs.
      
      Prior to this commit, when closing a pos session, SRLs are grouped
      by `property_account_receivable_id` of the partners in the invoices.
      Because of this, SRLs are blind of the partners that they are linked
      to. This causes issues on tracking the 'due' in the partners that are
      invoiced using the pos application.
      
      To fix the issue, we now group the SRLs by partner before reconciling
      them the the IRLs.
      
      Same concept is employed for receivable lines generated from split
      cash payments, we also assigned partner to them if applicable.
      
      closes odoo/odoo#70580
      
      X-original-commit: ebb4f30a
      Signed-off-by: default avataragr-odoo <agr-odoo@users.noreply.github.com>
      fa2fb9f7
  8. May 03, 2021
    • std-odoo's avatar
      [FIX] website_event_track: fix new track notifications by email · 45ffab08
      std-odoo authored
      
      Bug
      ===
      1. Create an event which allows track proposal
      2. Follow it and subscribe to "New Track"
      3. Log in in incognito and submit a proposal
      
      The email is not sent, because it's sent as the public user, which has
      no email address set. And so it the 2 system parameters
      <mail.catchall.domain> and <mail.default.from> are not set, we can not
      know which email address used to send the email.
      
      Note that this bug also occurs if you create a track with a user without
      an email address set.
      
      Task 2510181
      
      closes odoo/odoo#69890
      
      Signed-off-by: default avatarThibault Delavallee (tde) <tde@openerp.com>
      45ffab08
  9. May 10, 2021
  10. May 07, 2021
    • guimarc-br's avatar
      Adding the CLA Signature · 811f4297
      guimarc-br authored
      
      closes odoo/odoo#70534
      
      X-original-commit: 44e05cd8
      Signed-off-by: default avatarWilliam Henrotin <Whenrow@users.noreply.github.com>
      811f4297
    • guimarc-br's avatar
      [FIX] stock: add location_out_id field domain into the Putaway Rules menu · 9f837a73
      guimarc-br authored
      [REF] models: use stock to implement location_out_id into the Putway Rules Menu
      
      Description of the issue/feature this PR addresses:
      
      On the Location/Location-ID/PutwayRule we have the fields:
      
      location_in_id = When Product Arrives
      
      locatio_out_id = Store To
      
      As the products arrives in the WH/STOCK location and due the putaway rules goes to other location then we have the fields populated like:
      
      location_in_id = WH/Stock
      
      location_out_id = location opened in the view.
      
      Due this domain setup the list is returning empty, and then the solution that I applied is to check if we have the location selected in the location_in_id or location_out_id and show the entries.
      
      Current behavior before PR:
      
      Only looking for the from into the location_in_id
      
      After PR merged :
      
      Looking for the values from the location_in_id or location_out_id.
      
      --
      
      TaskID: N/A
      Fixes : PR 67198
      Closes : PR 67198
      
      I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
      
      X-original-commit: cd7133f0
      9f837a73
  11. May 09, 2021
  12. May 07, 2021
  13. Apr 26, 2021
    • Thibault Francois's avatar
      [FIX] event_crm: fix False - False lead creation · 9a4e792c
      Thibault Francois authored
      
      Use Case
      --------
      Have two (or more) rules with mutually exclusive domain for that can be
      apply on the same event with lead_creation_basis = order
      
      Create a registration that match one of the rule
      
      Problem
      -------
      The lead for this rule is created properly but there is also
      another lead with the name False - False that is created for the second
      rule for which the registration does not match the filter
      
      Solution
      --------
      
      Create a lead only when there is a non empty record set in the
      registration group
      
      closes odoo/odoo#69853
      
      Signed-off-by: default avatarThibault Delavallee (tde) <tde@openerp.com>
      9a4e792c
  14. Apr 01, 2021
  15. May 06, 2021
    • William Henrotin's avatar
      [FIX] stock,mrp,purchase: bypass optionnal delay description · c7b32e07
      William Henrotin authored
      
      The _get_lead_days() method does two things:
      1. Compute the lead day depending on the product to replenish
      2. Build a string explaining what are the parts of this day number
      
      This second part is optional at the Replenishment report opening.
      As the string is translatable, this impact quite significantly the
      performance of this opening.
      
      closes odoo/odoo#70351
      
      Opw: 2519528
      Related: odoo/enterprise#18202
      Signed-off-by: default avatarArnold Moyaux <amoyaux@users.noreply.github.com>
      c7b32e07
    • Rémy Voet (ryv)'s avatar
      [FIX] product: `_prepare_seller` reuse the orm cache · f91ba797
      Rémy Voet (ryv) authored
      Make `seller_ids` `depends_context` of company to
      avoid shared cache with different company. The purpose
      is to avoid making a SQL search for each `_prepare_seller` and use
      the ORM cache (which depends of the company in env).
      Also change the `_order` of `product.supplierinfo` to be
      determinist and consistent with the `_prepare_seller`.
      
      task-2439019
      f91ba797
    • William Henrotin's avatar
      [FIX] stock: use product prefect · db062738
      William Henrotin authored
      The loop on `to_refill()` call `browse()` on the product one by one.
      This doesn't make use of the cache when accessing product attributes
      like route_ids or categ_id.
      
      opw: 2519528
      db062738
    • William Henrotin's avatar
      [FIX] stock, purchase_stock: read virtual_available in batch · 363c1916
      William Henrotin authored
      Performance improvement for missing products computation.
      - Call _prepare_sellers only once
      - _compute_quantities works in batch for product with the same
      context. Use this advantage to speedup the computation of virtual
      available for each warehouse and delivery date.
      363c1916
  16. May 07, 2021
  17. May 06, 2021
    • Thibault Delavallée's avatar
      [IMP] various: update query counters according to latest runbot run · 87964726
      Thibault Delavallée authored
      
      Base: seems related fields take only 1 extra query instead of 3
      
      Crm: assignment seems to have been slightly improved. Some randomness still
      happens.
      
      Hr Holidays: seems it was further improved beyond space frontier
      
      Test mail: those tests were a bit random, seems random is gone (hopefully)
      
      Test mail full: updated local counters
      
      Test mass mailing: seems we gained one query, updated local counters
      
      closes odoo/odoo#70486
      
      Related: odoo/enterprise#18180
      Signed-off-by: default avatarThibault Delavallee (tde) <tde@openerp.com>
      87964726
    • Pete Snyder's avatar
      [FIX] delivery: Backorder shipping cost with invoice policy in real · 6ee1484a
      Pete Snyder authored
      
      Steps to reproduce the bug:
      
      - Let's consider a delivery carrier DC with invoice policy = 'real'
      - Let's consider a consumable product P with a weight = 1kg and sales price = 10€
      - Create a sale order SO with 2 P and add DC as shipping cost
      - Process the shipment for 1 P and create a backorder
      - Process the second shipment with the last P
      
      Bug:
      
      Two lines L1, L2 with DC were created on SO but only L1 as a price unit and a description.
      L2 had a price unit = 0€ and no description.
      
      opw:2520135
      
      closes odoo/odoo#70454
      
      Signed-off-by: default avatarSimon Goffin (sig) <sig@openerp.com>
      Co-authored-by: default avatarsimongoffin <sig@odoo.com>
      6ee1484a
Loading