Name of unit of measurements should be unique per category

Bug #734686 reported by Marco Dieckhoff
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
In Progress
Low
OpenERP Publisher's Warranty Team

Bug Description

You can add two Unit of Measurements named "kg" (with the same, or even more severe: with different ratios), in the same category.

To avoid confusion and inconsistent data, the name of the unit should be unique (per category).

This is, among other usages, quite neccessary for external unit conversion e.g. programs contacting OpenERP via xmlrpc.

Related branches

Amit Parik (amit-parik)
Changed in openobject-addons:
assignee: nobody → OpenERP Publisher's Warranty Team (openerp-opw)
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
Amit Parik (amit-parik) wrote :

Hello,

This bug is generated only in stable 6.0 because in trunk version constraint putted in UOM.

Thanks.

Changed in openobject-addons:
status: Confirmed → In Progress
Revision history for this message
Amit Dodiya (OpenERP) (ado-openerp) wrote :

Hello Marco,

Its fixed in https://code.launchpad.net/~openerp-dev/openobject-addons/6.0-bug-734686-ado.

It will be merged soon with stable addons branch.

Thanks.

Changed in openobject-addons:
status: In Progress → Fix Committed
Revision history for this message
Olivier Dony (Odoo) (odo-openerp) wrote :

Marco,

Any particular reason you think UoM names should be unique only *per category*? Given that UoMs are like currencies, I would think as their names as being reference "keys", so they should be globally unique, not just within a category.
This would make it even better/easier for external unit conversion.

Or do you have an example where you think using the same UoM name in 2 categories is valid?

PS: I changed status to Confirmed because it does not look like the proposed patch/branch correctly addresses this issue.

Changed in openobject-addons:
status: Fix Committed → Confirmed
Revision history for this message
Olivier Dony (Odoo) (odo-openerp) wrote :

BTW, the related fix from trunk came from bug 731035, which I'm not sure was correctly addressed, we may need to reconsider it.

Revision history for this message
Marco Dieckhoff (dieck) wrote :

I'm trying hard to remember why I added that "per category".

Even trying to construct a hypothetical case, I can't find any reason.
The only thing that would matter would be equal named units with different meanings, like minutes are time and astronomical angle. But that's way of all use cases I could expect.

I think it was just a mere minimal requirement and can be superseeded by a stronger constraint like "for all".

Revision history for this message
Steffi Frank (Bremskerl, DE) (steffi-frank) wrote :

a reason to do it by category would be: stock unit = kg, purchase unit = pce. Therefor you would define 'pce' in category 'weight' as well....

Revision history for this message
Marco Dieckhoff (dieck) wrote :

That's a very (very) specialised case, where ALL products you have are of the same weight, to not mess it up.

Here, we had such a special case, something bought as m³ (cubic metres, had to be called on the purchase order like this) and sold as kg.

I think the common way would have been to do a "unit conversion" by manufacturing, but that was too much overhead.

So we added a unit for m³ to weight. But even here, we wanted to avoid any misunderstandings, esp. with future products that may be added, and called it "m³ (48kg)", thus identifying it uniquely.

Revision history for this message
Olivier Dony (Odoo) (odo-openerp) wrote : Re: [Bug 734686] Re: Name of unit of measurements should be unique per category

Steffi and Marco, thanks for the additional details. I guess this
confirms the general rule, so let's go for that.

Changed in openobject-addons:
status: Confirmed → In Progress
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.