openerp-india team mailing list archive

[Graeme Gellatly <932586@xxxxxxxxxxxxxxxxxx>]

OK there is a workaround, which may actually be the solution.  Or the
reverse of it.

By making PCE inactive it no longer shows in search lists, but will
still default for orders without a product_id.

Then create another UOM category called Unit_2 (or whatever), and create
a new active PCE as well as any other units that belong in that
category.  Tested and it works.

I think if you wanted to resolve though you would do the opposite.
Change the xml data so 2 PCE entries were created, one inactive, one
not.  The inactive one in some other category, but with the xml_id of
'product_uom_unit'.

-- 
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