Skip to content
Snippets Groups Projects
  1. Feb 15, 2021
  2. Dec 31, 2020
    • Mohammed Shekha's avatar
      [FIX] web: fix horizontal scroll position not preserved · 8eba2150
      Mohammed Shekha authored
      before this commit: when there is a horizontal scroll in view say for example
      kanban view where there are too many columns and user scrolls horizontally and
      go to form view by clicking on any record and then come back to kanban view
      horizontal scroll is not preserved and user is moved to scroll position 0
      this is due to commit: https://github.com/odoo/odoo/commit/19eacf7d23c9413de4430a3422b5ed74b37ef242
      
      
      
      after this commit: scrolling horizontally and then go to form view and come
      back to previous view will preserve scroll position, we also consider case for
      kanban view where there are too many columns and user click on 'Add Column'
      user will be scrolled to new column element.
      
      task-2418275
      
      closes odoo/odoo#63933
      
      Related: odoo/enterprise#15511
      Signed-off-by: default avatarAaron Bohy (aab) <aab@odoo.com>
      8eba2150
  3. Feb 14, 2021
  4. Jan 12, 2021
  5. Feb 11, 2021
  6. Dec 08, 2020
  7. Feb 10, 2021
  8. Feb 09, 2021
    • Goffin Simon's avatar
      [FIX] mrp: Print BOM / BOM structure & cost · 80d4fb9f
      Goffin Simon authored
      
      Steps to reproduce the bug:
      
      - Install manufacturing app
      - Create a product A
      - Create a Bill of Materials for product A
      - Archive Product A (Only the final product not any of the components)
      - Print BOM or Print BOM Structure & Cost
      
      Bug:
      
      A traceback was raised
      
      opw:2447514
      
      closes odoo/odoo#65815
      
      Signed-off-by: default avatarSimon Goffin (sig) <sig@openerp.com>
      80d4fb9f
  9. Jan 04, 2021
    • Jorge Pinna Puissant's avatar
      [FIX] account: error in caba entry with stock valuation account · 555aa8fb
      Jorge Pinna Puissant authored
      
      - Install Accounting, Purchases and Inventory;
      - Configure cash basis accounting;
      - Configure purchases taxes as 'Based on Payment' with 16% of amount;
      - Create a new product and configure it as a Storable Product.
      - Configure the product category with costing method of the to FIFO and
          the Inventory Valuation to Automated;
      - Create a Purchase Order for a stock product with quantity 1,262.84 and
          price unit of 10.37;
      - Confirm the Purchase Order;
      - Receive product for 1,262.835 (0.005 less than ordered);
      - Create the vendor bill from the purchase order for the original
          quantity (1,262.84) and price unit of 10.37;
      - Validate the vendor bill and pay it.
      
      Before this commit, the cash basis journal entry was created with an
      incorrect amount of 0.05 of Base Tax Received Account.
      
      Now, the cash basis journal entry is created with the amount paid of
      13095.65 of Base Tax Received Account
      
      fine-tuning of e25f857e
      
      opw-2411516
      
      closes odoo/odoo#63738
      
      Signed-off-by: default avatarJorge Pinna Puissant (jpp) <jpp@odoo.com>
      Co-authored-by: default avatarAndrea Grazioso <agr@odoo.com>
      555aa8fb
  10. Jan 26, 2021
    • Romain Derie's avatar
      [FIX] base, website: replicate inherit_id update on cow view · bf537f1c
      Romain Derie authored
      Before this commit, only whitelisted fields would be updated on cow views
      during a module update.
      A field would be whitelisted if he had the same value than the original view,
      see it as a heuristic to not write on modified fields.
      
      But `inherit_id` is not that simple, even if the cow view has a different value
      than its original view, it doesn't mean it was modified by the user, it is just
      because of the cow mechanism that assigned a copied view as inherit_id, which
      is just a copy ofthe original one.
      
      We can thus consider `inherit_id` as unchanged and whitelist it if the `key` is
      the same.
      
      In practice, it means that cow'd views did not receive the `inherit_id` updates
      as in commit https://github.com/odoo/odoo/commit/c8577568a1e39f6692889b3e21652fa3b8df06b2#diff-823e5db841dca1798ff1300e243059a4e1c93343598d2be5a1d1dcd1d2d0c273R537
      where `portal.my_account_link` had its `inherit_id` changed from
      `portal.frontend_layout` to `portal.user_dropdow`, see https://github.com/odoo/upgrade/pull/2059
      
      :
      
      Considering a module update changing `inherit_id` of D from A to B, the
      following use cases are expected. Without this fix, D' never move:
      
      CASE 1
        A    A'   B                      A    A'   B
        |    |                 =>                 / \
        D    D'                                  D   D'
      
      CASE 2
        A    A'   B    B'               A    A'   B   B'
        |    |                 =>                 |   |
        D    D'                                   D   D'
      
      CASE 3
          A    B                        A    B
         / \                   =>           / \
        D   D'                             D   D'
      
      CASE 4
          A    B    B'                  A    B   B'
         / \                   =>            |   |
        D   D'                               D   D'
      
      closes odoo/odoo#64446
      
      Signed-off-by: default avatarChristophe Simonis <chs@odoo.com>
      bf537f1c
  11. Feb 09, 2021
  12. Feb 08, 2021
  13. Feb 05, 2021
    • Anh Thao Pham (pta)'s avatar
      [FIX] stock_account: fix valuation with negative value after an adjustment · 8877e7a3
      Anh Thao Pham (pta) authored
      
      - Install account_accountant, stock_account, purchase & sale_management
      - Create a Product (i.e. Product X)
      - Edit Product Category:
        * Costing Method: Average Cost (AVCO)
        * Inventory Valuation: Automated
      - Create a PO with Product X for 5 quantities at $5
      - Receive the Products
      - In Inventory > Report > Inventory Valuation, for Product X, we have (qty: 5, value: $25)
      - Create a SO with Product X for 10 quantities
      - Deliver Products
      - Valuation for Product X = (qty: -5, value: $-25) => Correct
      - In Inventory > Operations > Inventory Adjustments, create an adjustment for Product X to 0
      - In Product X form, update cost to 0 (You may need to remove Vendors from Purchase tab to be able to do it)
      - There is no more valuation for Product X => Correct
      - Edit Product Category by setting "Costing Method" to "First In First Out (FIFO)"
      - /!\ Do not recompute Inventory Valuation via Inventory > Report > Inventory Valuation
      - Create a PO with Product X for 10 quantities at $7
      - Valuation for Product X = (qty: 10, value: $70) => Correct
      - Create a SO with Product X for 7 quantities
      - Deliver Products
      At this point, Inventory Valuation for Product X is incorrect. The Quantity is 3, which is correct,
      but the value is $31, instead of $21 (3 * $7).
      
      With FIFO Costing Method, the valuation of the last SO should be (7 units at $7) = $49.
      But here, we have (5 units at $5 + 2 units at $7) = $39.
      When the Inventory Adjustment has been made to set Product X to 0, a move of (qty:5, value: $25)
      has been made to balance the previous Valuation of (qty: -5, value: $-25).
      Values from this move are used during the last SO, but it shouldn't.
      
      It happens because the "remaining_qty" field of the move created for the adjustment
      has a value of 5 (the original move qty), instead of 0 (the real remaining qty).
      Therefore the quantities from this move are used when running "_run_fifo" method,
      although they should have been used to cancel the negative "remaining_qty" (-5) from
      the move generated by the first SO.
      
      To prevent this, moves with negative "remaining_qty" should be fixed when an in move is validated.
      
      PS: The issue is also reproducible with FIFO Costing Method from the start,
      as long as no Inventory Valuation recomputation is performed once the
      inventory adjustment has been made.
      
      opw-2425909
      
      closes odoo/odoo#65250
      
      Signed-off-by: default avatarAnh Thao PHAM <kitan191@users.noreply.github.com>
      8877e7a3
  14. Jan 21, 2021
    • Tiffany Chang (tic)'s avatar
      [FIX] mrp: use bom quantity in bom report · 30c05ad9
      Tiffany Chang (tic) authored
      
      This commit makes it so when the bom structure report (Structure & Cost
      smartbutton) is opened the product quantity defaults to the BoM's
      `product_qty` amount rather than 1.
      
      Steps to reproduce:
      - Create/open a BoM
      - Set `product_qty` to any value greater than 1
      - Click on "Structure & Cost" button.
      
      Expected result: product quantities scaled to the `product_qty`
      Actual result: product quantities scaled to Quantity = 1
      
      closes odoo/odoo#64839
      
      Task: 2429885
      Signed-off-by: default avatarArnold Moyaux <amoyaux@users.noreply.github.com>
      30c05ad9
  15. Jan 29, 2021
  16. Feb 08, 2021
    • Adrien Horgnies's avatar
      [FIX] product: generate variant combinations faster · 2e5634fa
      Adrien Horgnies authored
      
      The function `_get_possible_combinations` generates possibles combinations
       for the product template attribute values (ptav) of each product template
       attribute line (ptal) of a given product template. It used to iterate over
       them using a cartesian product. A combination can be invalid if it
       contains two incompatibles ptav. The problem is that it used to filter out
       invalid combinations after generating them. It's a problem because there
       can be a lot of invalid combinations to filter out before finding a valid
       combination. Even before the first valid combination if the first ptav of
       the two first ptal are incompatible.
      
      The solution brought by this commit is to reject the invalid combinations
       while building them rather than after. It does so by using a cartesian
       product implementation with early rejection. The algorithm tests each
       ptav when incorporating it in a partial combination and if it's
       incompatible, it goes to the next partial combination and thus skips all
       combinations starting with the invalid partial combination.
      
      The client that reported the issue has a product template with about 25
       ptal with an average of 9 ptav. The ptav of the first ptal was
       incompatible with the first ptav of second ptal. It had to build and
       filter out 5.76*10^15 ptav before finding the first valid ptav. If we
       generate 10^6 ptav by second (it's much less) user would get first ptav
       after 182 years. Now it's instantaneous.
      
      opw-2335936
      
      closes odoo/odoo#65089
      
      Signed-off-by: default avatarSébastien Theys (seb) <seb@odoo.com>
      2e5634fa
    • Nicolas Lempereur's avatar
      [FIX] account: can refresh tax audit action · d685a475
      Nicolas Lempereur authored
      
      Because of context:
      
      {'search_default_account_id': [active_id]}
      
      refreshing on the tax audit action could cause an error because in normal
      use case we have active_id that is never an account.account id (but for
      example an account.tax.report.line).
      
      There doesn't seem to be any use case where that context is useful since
      it was introduced in 2017 (81089042), this action is always used with an
      overriden context. So this commit is removing it.
      
      opw-2388448
      
      closes odoo/odoo#65698
      
      Signed-off-by: default avatarNicolas Lempereur (nle) <nle@odoo.com>
      d685a475
  17. Feb 07, 2021
  18. Feb 04, 2021
  19. Feb 05, 2021
  20. Jan 26, 2021
    • Arnold Moyaux's avatar
      [FIX] stock: couldn't unreserve mixed tracking stock · 3bbefb10
      Arnold Moyaux authored
      
      - Install stock
      - Go to Inventory > Configuration > Settings and enable "Lots" and "Storage Locations"
      - Create a Product tracked By Lots (i.e. Product X)
      - Go to Inventory > Operations > Inventory Adjustments
      - Create an Inventory Adjustment for Product X:
      
           Product   |   Location   |   Lot/SN   |   Real Quantity
       -------------------------------------------------------------
          Product X  |   WH/Stock   |   LOT 01   |       20
          Product X  |   WH/Stock   |            |       10
      
      - Validate Inventory
      - Go to Inventory > Operations > Transfers and create one:
        * Source Location: WH/Stock
        * Destination Location: WH/Stock/Shelf1
        * Operation Type: Internal Transfers
        * Operations:
          [Product: Product X, Initial Demand: 25]
      - Save Transfer, Mark As Todo and Check availability
      - Click on list icon of Operation line for Product X to display Detailed Operations
      - 20 units of LOT 01 and 5 units without lot have been reserved
      - Set LOT 01 for the 5 reserved units without lot and confirm
      - Open Detailed Operations again
      - There are now 20 units of LOT 01 and 5 units of LOT 01
      - Remove the row with 5 units and confirm
      - Check availability and open Detailed Operation
      - There is now only a row with 25 reserved units of LOT 01
      - Unreserve
      The following errror is raised:
      "It is not possible to unreserve more products of P than you have in stock."
      
      It happens because the system is not able to manage quants with lots and
      wihtout lots at the same time. When modifying the move line to 25
      reserved units. It's composed of 20 quants with lot and 5 quants without
      lot. And when unreserving it will check if there is a quants with 25
      units with the lot and if it's not found 25 units without lot. But never
      25 units of quants with lots and without lots.
      
      opw-2419444
      
      Close #64497
      
      closes odoo/odoo#65057
      
      Signed-off-by: default avatarArnold Moyaux <amoyaux@users.noreply.github.com>
      3bbefb10
  21. Feb 03, 2021
  22. Feb 01, 2021
    • nie's avatar
      [FIX] l10n_ch: use commercial company name in invoice PDF · d9ea1d5f
      nie authored
      Steps:
      - Edit the current company (1):
        - Country: Switzerland
        - Currency: CHF
      - Install l10n_ch
      - Go to Invoicing > Configuration > Bank Accounts
      - Edit Bank:
        - Bank Account: create a new one:
          - Account Holder: (1)
      - Go to Configuration > Journal
      - Edit Customer Invoices:
        - Advanced Settings tab:
          - Communication Standards: Switzerland
      - Go to Customers > Customers
      - Create a new customer (2):
        - Fill in street, city, zip code and country
      - Edit (2):
        - Contacts & Addresses tab:
          - Add:
            - Select Invoice Address
            - Contact Name: Keep this field blank
      - Go to Customers > Invoices
      - Create a new one:
        - Customer: "(2), Invoice Address"
        - Add a product
      - Validate it
      - Click Print QR-Bill
      
      Bug:
      Traceback here:
      https://github.com/odoo/odoo/blob/b76e9ef658bde0178fa1660b6ad27b880e91632a/addons/l10n_ch/models/res_bank.py#L129
      
      
      TypeError: 'bool' object is not subscriptable
      
      Explanation:
      The contact name of an address is optional. When nothing is filled in
      that field, it returns `False`, hence the error.
      Using the commercial company name ensures a name is put in the invoice,
      even if the contact doesn't belong to a company.
      
      opw:2447158
      
      closes odoo/odoo#65357
      
      Signed-off-by: default avatarbackspac <backspac@users.noreply.github.com>
      d9ea1d5f
    • Ivan Yelizariev's avatar
      [FIX] core: initialize new stored related field via SQL · 02417290
      Ivan Yelizariev authored
      Filling the new column in SQL is dramatically faster than doing it via
      the ORM, which iterates over all the records in the table.
      
      The test case is creating a related field for 100+ records with distinct
      values.  Setting the field's value was taking more than 100 queries.  It
      now takes 3 queries.
      
      task-2449313
      opw-2380445
      opw-2389376
      https://github.com/odoo/enterprise/pull/15910
      
      
      
      closes odoo/odoo#65232
      
      Signed-off-by: default avatarRaphael Collet (rco) <rco@openerp.com>
      02417290
  23. Dec 11, 2020
    • david's avatar
      [FIX] hr_expense: wrong company account when creating from mail · dca2127f
      david authored
      
      In a multicompany environment, when a expense is created from the
      expense email alias, the expense account is computed with SUPERUSER
      context, so depending on the SUPERUSER set company, we could get
      a mismatch of expense and employee's company and the account one, wich
      causes a subsequent error when trying to post the expense.
      
      closes odoo/odoo#63188
      
      Signed-off-by: default avatarSimon Goffin (sig) <sig@openerp.com>
      dca2127f
  24. Feb 01, 2021
    • Christophe Monniez's avatar
      [FIX] packaging: add a bom to nsi script · 3d0871d1
      Christophe Monniez authored
      
      When using the windows installer in French language, the `Hôte` label
      used to configure postgresql server does not display correctly.
      
      The LangString documentation does not specify how to use the special
      characters but after some tests, specifying a BOM for the nsi file seems
      to be the way to go.
      
      closes odoo/odoo#65354
      
      Signed-off-by: default avatarChristophe Monniez (moc) <moc@odoo.com>
      3d0871d1
    • nie's avatar
      [FIX] account: clearer bank account holder validation message · b76e9ef6
      nie authored
      
      Steps:
      - Go to Accounting > Configuration > Accounting > Bank Accounts
      - Create a new Bank Account
        - "Bank Account" field: create and edit a new one
          - Account Holder: Anyone but your company
      - Save
      
      Bug:
      Validation Error: The holder of a journal's bank account must be the
      company (YourCompany).
      
      Explanation:
      The error is not clear enough. Users may be confused because this
      validation error appears upon saving a "Bank Account Journal"
      (`account.journal`) but is talking about "Partner Bank Account"
      (`res.partner.bank`) which is a field of the "Bank Account Journal".
      
      opw:2448183
      
      closes odoo/odoo#65281
      
      Signed-off-by: default avatarbackspac <backspac@users.noreply.github.com>
      b76e9ef6
  25. Jan 31, 2021
  26. Jan 29, 2021
  27. Dec 09, 2020
  28. Nov 17, 2020
  29. Jan 28, 2021
  30. Jan 19, 2021
  31. Jan 22, 2021
    • Priyanka kakadiya's avatar
      [FIX] project: propagate internal subtypes to tasks · 9c5a79ff
      Priyanka kakadiya authored
      
      Manual backport of commit done in 13.0 odoo/odoo@227c8fb53265de03b202133c4e8012b8bcce01b4
      
      before this commit:
      
      while changing subtypes of the project it was only
      propagating those subtypes to the task, whose parent_id is set.
      internal subtypes are not propagating in the task of a project.
      
      So, filter internal subtypes and concat them with the subtypes which
      have parent_id.
      
      after this commit:
      internal subtypes will also propagate to their tasks
      
      LINKS
      
      Task ID-2205643
      Task ID-2241688
      COM PR #56775
      
      Signed-off-by: default avatarThibault Delavallee (tde) <tde@openerp.com>
      9c5a79ff
Loading