Skip to content
Snippets Groups Projects
  1. May 10, 2021
  2. 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
  3. May 09, 2021
  4. May 07, 2021
  5. 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
  6. Apr 01, 2021
  7. 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
  8. May 07, 2021
  9. May 06, 2021
  10. May 05, 2021
  11. May 06, 2021
  12. Oct 07, 2020
  13. May 06, 2021
    • abd-msyukyu-odoo's avatar
      [FIX] web: fix kanban view progressbars related to records in another group (groupby:week) · 665e9538
      abd-msyukyu-odoo authored
      * IMPACTED VERSIONS
      
        12.0+
      
      * HOW TO REPRODUCE
      
      locale :  Locale is en_US (or other SUNDAY based)
      view:     CRM - My Pipeline - Kanban view
      groupBy:  date_deadline:week (Expected closing)
      records:  one record with a planned activity, on date_deadline = 2021-05-02 (SUNDAY)
                one record with no planned activity, on date_deadline = 2021-05-09 (SUNDAY)
      remark:   don't keep any other record in MAY for better visibility
      
      * PROBLEM
      
      The progressbar of the week containing 2021-05-09 displays information about the record
      from the week containing 2021-05-02
      
      * CAUSE
      
      1. PostgreSQL `date_trunc` function follows ISO8601 which essentially means that
        the start of a WEEK is always MONDAY. There is no argument to change this.
      
      2. _read_group_format_result
        https://github.com/odoo/odoo/blob/27da86a138089c1838e4b94f8a6976995b9c1fff/odoo/models.py#L2210-L2219
      
        - Computes a label for a group of records.
        - Follows the locale for the label of the week, based on a date which is
          always a MONDAY because of `date_trunc`.
      
      3. read_progress_bar
        https://github.com/odoo/odoo/blob/88957afca09662af7eaa19df1e40b3699e45e79e/addons/web/models/models.py#L167-L175
      
      
      
        - Associates a group label to a record.
        - Follows the locale for the label of the week, based on the date of a record
          which can be any day of the week. If the record is related to a SUNDAY and
          SUNDAY is the first day of the week, it would have been in a group with a
          different label in (2.) than in (3.) prior to this change.
      
      * FIX
      
      In 3., before associating a label to a record, we truncate the date to the
      ISO start of the period, so that the label is determined for a record in the
      same conditions than in 2. The locale is still used to get language-dependent
      outputs with babel, but the grouping will always follows ISO8601 (date_trunc).
      
      * TEST
      
      Added a test for this problem case
      
      TASK-ID : 2517848
      
      closes odoo/odoo#70453
      
      X-original-commit: c08f6e3e
      Signed-off-by: default avatarRaphael Collet (rco) <rco@openerp.com>
      Signed-off-by: default avatarThibault Delavallee (tde) <tde@openerp.com>
      665e9538
  14. May 05, 2021
    • Rémy Voet (ryv)'s avatar
      [FIX] stock: fix broken forecasted report template · e0bafb07
      Rémy Voet (ryv) authored
      
      Remove the optimization of the `product_tmpl_id` related fields which
      needs a upgrade to work without any issues.
      
      This reverts partially the commit
      4c627651.
      
      Find a other for the stable to optimise the forecasted report of product
      template:
      When the `product_tmpl_id` is in the domain of a read_group, it will
      be replace by a equivalent clause with `product_id` instead to avoid
      any sub-query which didn't help the postgreSQL planner.
      The performance decrease but it still acceptable compared that before
      the revert fix (test with one template with 256 variants in
      a DB with 40K products and 100K moves, 1K locations, etc)
      - Revert fix (which need a upgrade): 75 ms
      - new fix (no need a upgrade): 130 ms
      - without any fixes (before the revert fix): 500 ms (also have a bigger
      scale penalty)
      
      closes odoo/odoo#70381
      
      Signed-off-by: default avatarArnold Moyaux <amoyaux@users.noreply.github.com>
      e0bafb07
  15. May 06, 2021
  16. May 05, 2021
  17. May 04, 2021
  18. May 03, 2021
    • oco-odoo's avatar
      [FIX] account: reconciliation models: fix priorities when matching amls from payments · b5800c9d
      oco-odoo authored
      
      Since the payment refactoring, the structured reference of a payment is stored in its ref field, not payment_reference like for invoices. This caused payments never to be matched with highest priorities, as payment_reference_flag was always false, and only communication_flag could match.
      
      To reproduce:
      
      - Have a reconcile model with match_total_amount=False.
      - Create a statement line with communication a1b2c3 for 1000
      - Create 3 payments:
      > 500, with memo a1b2c3
      > 500, with memo a1b2c3 (so, the same one)
      > 500, with memo d1e2f3
      - Open the reconciliation widget for your statement line
      
      ===> The 3 payments are matched, while only the two first ones should have been, as they were exact matches for the communication, and should hence have received higher priority.
      
      closes odoo/odoo#70277
      
      Signed-off-by: default avatarLaurent Smet <smetl@users.noreply.github.com>
      b5800c9d
  19. Apr 29, 2021
    • Laurent Stukkens (LTU)'s avatar
      [FIX] sale_timesheet: prevent multicompany issue on SOL · 2480e959
      Laurent Stukkens (LTU) authored
      
      Steps to reproduce:
      
              - Create an SO for a prepaid service in company A and confirm it
              - Create a project and a task in company B and select the customer linked to the SO you previously created
              - Unselect company A from the multi-company widget; only display the records from company B
              - Timesheet on the task you previously created
      
      Observed behavior:
      
              - The SOL set by default belongs to company A, thus generating an access right error when trying to timesheet on the task
      
      Expected behavior:
      
              - The SOL set by default should belong to the same company as the task
      
      task-2515259
      
      closes odoo/odoo#69783
      
      Related: odoo/enterprise#17921
      Signed-off-by: default avatarYannick Tivisse (yti) <yti@odoo.com>
      2480e959
  20. May 04, 2021
  21. Apr 28, 2021
  22. May 04, 2021
Loading