Skip to content
Snippets Groups Projects
  1. Oct 20, 2020
  2. Oct 19, 2020
  3. Oct 20, 2020
    • Olivier Laurent's avatar
      [FIX] pad: permission issue on securized etherpad servers · 88839809
      Olivier Laurent authored
      
      If you want to prevent pad creation without the API key, you configure
      the etherpad server with the 'editOnly' parameter set to 'true'.
      In this case (copy/pasting the settings.json):
      * users may edit pads but not create new ones
      * pad creation is only via the API
      
      But if you secure your etherpad server like this, you won't be able to
      create pads in odoo in certain circonstances.
      
      This use case does not work (using 'pad_project'):
      * secure your etherpad server ("editOnly": true)
      * open the Project app and choose a project
      * open an already existing task (or create one)
      * from this task, click on the "Create" button to create a new task
      * the 'description' field displays: "You do not have permission to access this pad"
      * if you save, you'll get a traceback: "ValueError: padID does not
        exist"
      
      The same issue arise if you create a task from the list (not kanban)
      view.
      If you create a task directly from the kanban view, there is no
      problem because there is an 'object_id' in the context dict.
      
      closes odoo/odoo#60333
      
      X-original-commit: 8ffc00fb
      Signed-off-by: default avatarMartin Trigaux (mat) <mat@odoo.com>
      88839809
    • Olivier Laurent's avatar
      [CLA] Logicasoft · 70ffd509
      Olivier Laurent authored
      X-original-commit: 69c551f6
      70ffd509
    • yhu-odoo's avatar
      [IMP] stock: allow multi_edit on replenish report · 24def7f1
      yhu-odoo authored
      
      Allow multi_edit on replenish report.
      
      Task 2363495
      
      closes odoo/odoo#60319
      
      Signed-off-by: default avatarArnold Moyaux <amoyaux@users.noreply.github.com>
      24def7f1
  4. Oct 19, 2020
  5. Oct 20, 2020
  6. Oct 19, 2020
    • Jeremy Kersten's avatar
      [FIX] web_editor: fix width of SVG images in media dialog · f0eda151
      Jeremy Kersten authored
      
      This solves an issue with svg images from Isometric for example. The
      media dialog assigns width to its displayed images thanks to the
      flex-basis and flex-grow properties of their container, based on the
      aspect ratio of each image. This was done correctly for SVG images too.
      However, after assigning a nice space for a specific SVG image, the
      image itself was not made to fill that assigned space... it only worked
      if the natural width of the image was higher than the assigned space.
      This was of course more obvious with SVG files with no intrinsic width
      as they would simply not appear.
      
      closes odoo/odoo#60305
      
      X-original-commit: 585aed8b
      Signed-off-by: default avatarQuentin Smetz (qsm) <qsm@odoo.com>
      Co-authored-by: default avatarqsm-odoo <qsm@odoo.com>
      f0eda151
  7. Oct 20, 2020
  8. Oct 19, 2020
  9. Oct 20, 2020
  10. Oct 16, 2020
  11. Oct 15, 2020
  12. Oct 19, 2020
    • Randall Castro's avatar
      [CLA] Add randall-vx as new contributor in vauxoo · 145e3ad0
      Randall Castro authored
      
      closes odoo/odoo#60284
      
      X-original-commit: 89daca4b
      Signed-off-by: default avatarMartin Trigaux (mat) <mat@odoo.com>
      145e3ad0
    • Balvant Ramani's avatar
      [CLA] signature for rb3606 · 74ae9028
      Balvant Ramani authored
      
      closes odoo/odoo#60283
      
      X-original-commit: 5df06d8e
      Signed-off-by: default avatarMartin Trigaux (mat) <mat@odoo.com>
      74ae9028
    • Nicolas Galler's avatar
      [FIX] account: use commercial partner id for auto computed lines · 6c74444c
      Nicolas Galler authored
      
      Behavior before the fix:
      
      - if you create a sales order for a customer invoice address (a child
      partner record), then create the invoice for that order, the partner_id
      is not consistent between the move_line (some get the child partner id,
      some get the commercial partner id = the parent partner id)
      - if you create the invoice directly from the accounting app for a
      child partner, the commercial partner id is used consistently for all
      move lines (the invoice itself keeps the child partner id)
      
      Behavior after the fix:
      
      - when an invoice is created from a sales order, the partner id is set
      using the commercial partner id, consistently for all lines (in this way
      the behavior is consistent with that of the accounting app)
      
      It is more appropriate to use the commercial_partner_id for this purpose
      as it is used pretty consistently in the account_move file
      
      opw-2347878
      
      closes odoo/odoo#60302
      
      X-original-commit: cd299518ae45f2732d47788869b013be16b814e8
      Signed-off-by: default avatarJorge Pinna Puissant (jpp) <jpp@odoo.com>
      Signed-off-by: default avatarNicolas Galler <nicocrm@users.noreply.github.com>
      6c74444c
    • Pierre Masereel's avatar
      [FIX] point_of_sale: fix price computation for tax included · 5df62398
      Pierre Masereel authored
      
      When you hava a fiscal position that that map one tax included into the
      price to another, the new amount is wrong.
      
      I we have a fiscal position that map a tax of 10% included to 20%
      included, and a product at 110$ having 10% included. When we map the tax
      from 10% to 20%, the new price is 100$ but should be 120$.
      
      This is because for now, the price is fixed to get the amount without
      tax, which perfectly works when destination tax is tax excluded. But
      when you call compute_all from a price with a tax included (20%) it keep
      the price and compute the tax amount out of this price.
      
      So to fix this issue, whent the origin tax and destination tax are
      included, we are computing the base amount (like before) and then we
      compute the new tax amount wihtout trying to find the tax amount out of
      the price.
      
      This will lead to have the same behavior between accounting and POS
      
      closes odoo/odoo#60312
      
      X-original-commit: f8737b46
      Signed-off-by: default avatarpimodoo <pimodoo@users.noreply.github.com>
      5df62398
    • Josse Colpaert's avatar
      [IMP] l10n_il: add tags and tax report · 33ed6cb1
      Josse Colpaert authored
      
      This way the PCN874 report is already there.
      Existing databases will need to relink the taxes
      with the report however.
      
      closes odoo/odoo#60295
      
      X-original-commit: 6963f58d1c23065eec440d5be23c93f73c24b3bd
      Signed-off-by: default avatarJosse Colpaert <jco@openerp.com>
      33ed6cb1
    • Priyanka Kakadiya's avatar
      [FIX] mass_mailing: do not add `opt_out` by default on mailing domains · 7f5ef74b
      Priyanka Kakadiya authored
      
      In mass mailing (_sms) when you set `Mailing Contact` as target model the
      `opt_out` field is added to the default domain. However as it is a computed
      field depending on a single mailing list given in context it should not be
      used that way. Moreover current implementation raises a warning as only some
      custom views can use this field accordingly.
      
      This commit removes `opt_out` field being set by default in mailing domain and
      also removes the UserError raised by the search function, thus avoiding
      unwanted warnings.
      
      Opt-out field is automatically taken into account when sending mass mailing on
      contacts (see ``_get_opt_out_list``) so removing it from domain is actually
      even better for coherency. Opt-out is not an option in sending process.
      
      Task Id-2300427
      PR #57310
      
      closes odoo/odoo#60262
      
      X-original-commit: 5ccf5b51
      Related: odoo/enterprise#14200
      Signed-off-by: default avatarThibault Delavallee (tde) <tde@openerp.com>
      7f5ef74b
    • Victor Feyens's avatar
      [FIX] sale_coupon: avoid duplicated checks/filters · f5dcbb29
      Victor Feyens authored
      
      Avoid filtering/checking the same condition multiple times on the same
      records...
      
      This allows to avoid n more fetch of all applicable coupon programs from
      the database (because _check_promo_code is called on each program in a loop).
      
      Also apply the date filter directly in SQL:
      * The computation of inherited fields (_inherits) by the orm is intrinsically slow.
      
      	The fields rule_date_from and rule_date_to checked in the _filter_on_validity_dates
      	python filter are inherited from sale.coupon.program.rule model.
      
      * Filtering recordsets in SQL is faster.
      
      closes odoo/odoo#60292
      
      X-original-commit: 679ebc33
      Signed-off-by: default avatarVictor Feyens (vfe) <vfe@odoo.com>
      f5dcbb29
    • Victor Feyens's avatar
      [IMP] sale_coupon: diverse perf improvements · 4e693726
      Victor Feyens authored
      
      * Use set instead of recordset to incrementally join records
      * avoid filtered and mapped calls when possible
      * use generators correctly
      sum([gen]) --> sum(gen)
      
      X-original-commit: d3daa379
      Co-authored-by: default avatarLoan Sens <lse@odoo.com>
      4e693726
    • Victor Feyens's avatar
      [FIX] sale_coupon: perf improvement · d7df652b
      Victor Feyens authored
      _get_applicable_no_code_promo_programs always returns a subset of
      _get_applicable_programs ...
      
      We can thus avoid summing the results from the two methods, which
      triggered unnecessary operations and resulted in a recordset with
      useless duplicates...
      
      Furthermore, as _get_applicable_programs returned recordset is only
      used to compare to other recordsets (substraction or comparison),
      it doesn't need to be sorted by the model order.  We can thus
      safely order the result by id instead, to reduce the query complexity.
      
      X-original-commit: 5d45322c
      d7df652b
    • Victor Feyens's avatar
      [FIX] sale_coupon: reorder costly method to avoid useless operations · 70295e5c
      Victor Feyens authored
      
      When coupon is installed, all cart (SO) updates on the e-commerce go through
      the _remove_invalid_lines method.  It has been proved to be a performance
      bottleneck on big instances with a lot of coupon programs.
      
      To reduce the performance impact of this method, this commit reorganize it
      to avoid unnecessary operations as much as possible.
      
      X-original-commit: 447057cf
      Co-authored-by: default avatarLoan Sens <lse@odoo.com>
      70295e5c
Loading