← Back to team overview

openerp-india team mailing list archive

[Bug 932586] Re: [trunk][sale] error in how _get_uom_id and product_id_change interact

 

** Changed in: openobject-addons
   Importance: Undecided => Low

** Changed in: openobject-addons
       Status: New => Confirmed

** Changed in: openobject-addons
     Assignee: (unassigned) => OpenERP R&D Addons Team 3 (openerp-dev-addons3)

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Addons.
https://bugs.launchpad.net/bugs/932586

Title:
  [trunk][sale] error in how _get_uom_id and product_id_change interact

Status in OpenERP Addons (modules):
  Confirmed

Bug description:
  Tested with new database, demo data, just stock and sale installed.

  A sale order line sets the default uom to PCE as per _get_uom_id.  Now
  when the product id is changed if its default UOM is in the same
  category (unit) the uom is not changed as the uom from _get_uom_id is
  passed.

  To test is easy, create a new UOM called Piece in the Unit category
  and change ARM100 to use Piece.

  Then enter a salesorder and enter the line ARM100 and you see PCE
  instead of Piece.

  To prove it is get_uom_id is obvious but if you must just change its
  return to False and restart and retest and you now see correct uom.
  Now the problem is caused by the following couple of bits of code in
  product_id_change but they actually do something useful.

          if uom:
              uom2 = product_uom_obj.browse(cr, uid, uom)
              if product_obj.uom_id.category_id.id != uom2.category_id.id:
                  uom = False

  in that if you change a product it doesn't change the uom already set
  unless it is in a different category which would be really annoying if
  it did.  I can see no way to detect this case based on the current
  parameters passed to onchange whether it is just the default entry or
  not.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-addons/+bug/932586/+subscriptions


References