Skip to content
Snippets Groups Projects
  1. Jan 19, 2015
  2. Dec 15, 2014
  3. Dec 10, 2014
    • Martin Trigaux's avatar
      [FIX] account: avoid losing product on invoice · 36958865
      Martin Trigaux authored
      Add restriction on product_id field to prevent the suppression of the product
      if already present in an invoice.
      This is to avoid the suppression of a used product variant when modifying
      the list of attributes.#
      Due to the constrain, the variant will be disabled instead of deleted.
      Fixes #4129
      
      Add warning message on the product form to warn users about the potential impact
      of modifying variants.
      36958865
  4. Dec 02, 2014
  5. Nov 24, 2014
    • Martin Trigaux's avatar
      [FIX] product: creation of reference uom · 4ce7af35
      Martin Trigaux authored
      Set a default value for factor when creating a new uom.
      Could not create a new UoM with type reference (if creates a reference uom, no need to pass a factor).
      
      Change the readonly filter to (type = bigger) to make the field writable for reference uom.
      This is needed to force the reset of the factor when switching of type (onchange_type).
      As the field was readonly, kept the old value for factor.
      4ce7af35
  6. Nov 07, 2014
  7. Oct 22, 2014
    • Martin Trigaux's avatar
      [FIX] product.uom: safer handling of factor/factor_inv in UI · 3a0af6af
      Martin Trigaux authored
      Add readonly attribute to avoid sending both factor and factor_inv value to the backend when saving.
      This was possible if the user switched between uom_type to fill the two fields.
      3a0af6af
    • Cédric Snauwaert's avatar
      [FIX] product: remove digits_precision from uom factor fields · fa2f7b86
      Cédric Snauwaert authored
      Remove the hardcoded precision of 12 on factor and factor_inv,
      to use the complete natural precision of NUMERIC types,
      preserving all significant digits.
      
      e.g. a UoM with a factor_inv of 6.0 used to be computed as:
      factor_inv: 6.0 -> factor: 0.166666666667 (1.0/6.0, rounded to 12 digits) -> factor_inv: 5.999999999988 (1.0/factor)
      which could lead to errors such 12*0.166666666667 = 2.000000000004 instead of 2.0
      
      Slightly changed the way the ORM handles float fields to allow setting `digits=0`
      as a way to explicitly require a NUMERIC value but without enforcing/rounding
      the values at the ORM level, i.e. a truly full-precision field.
      
      NUMERIC type has unlimited precision but is less efficient so should not be
      used as the default behaviour, which is why we keep float8 as an alternative.
      
      Modified the view to display the product UOM factor with a 5 digits value by default.
      This value is for usability purpose only, the field still accepts bigger precision, by
      setting the `digits` option on the field in the form view.
      
      This change is safe in a stable series, the `digits=0` alternative is
      treated the same as the default `digits=None` everywhere in the framework,
      except when creating the database field.
      fa2f7b86
  8. Oct 06, 2014
  9. Sep 22, 2014
  10. Sep 19, 2014
  11. Sep 11, 2014
  12. Sep 10, 2014
  13. Aug 22, 2014
  14. Aug 21, 2014
  15. Aug 20, 2014
  16. Aug 19, 2014
  17. Jul 28, 2014
  18. Jul 16, 2014
  19. Jul 11, 2014
    • Martin Trigaux's avatar
      [FIX] product: unfuck templates and products in views · 0a6d63b8
      Martin Trigaux authored
      product.product reuses most of the product.template views however some parts need to be excluded or replaced.
      Instead of adding template only parts in base view and removing it for product, split the views in 'common' (product_template_form_view), 'template only' (product_template_only_form_view) and 'product only' (product_normal_form_view) where the first is inherited by the other two. The attribute mode='primary' on both second views allows to make sure that future inheritance of product_template_form_view and product_template_only_form_view will work with the full rendered product_template_form_view view.
      This allows us to have valid buttons in crm for bill of material (filters based on active_id).
      Also cleaning the mess with circular dependencies.
      0a6d63b8
  20. Jul 09, 2014
    • Martin Trigaux's avatar
      [FIX] product: allow user to set price at template creation · bd163d7b
      Martin Trigaux authored
      The lst_price field on product.template is a related to list_price. As we do not allow to set a value for related fields at creation (see orm.py , L4180), we display the list_price instead (float field).
      On the product.product form, we display the lst_price (function field, readonly) as we don't want to allow changing the template price from the product. opw 609497
      bd163d7b
  21. Jul 08, 2014
  22. Jul 07, 2014
  23. Jun 17, 2014
  24. Jun 13, 2014
  25. Jun 12, 2014
  26. Jun 03, 2014
  27. May 28, 2014
  28. May 27, 2014
  29. Apr 22, 2014
  30. Apr 11, 2014
  31. Apr 08, 2014
    • Denis Ledoux's avatar
      [FIX] product, stock: set active field in default product view, instead of... · 41d172ea
      Denis Ledoux authored
      [FIX] product, stock: set active field in default product view, instead of inherited view of stock module
      
      The active field was placed in the Delays section, which does not make sense
      Besides, we should be able to disable products by default, not when stock is installed.
      
      bzr revid: dle@openerp.com-20140408180920-jpl50ups6ro1z4qp
      41d172ea
  32. Mar 20, 2014
  33. Mar 04, 2014
Loading