[wasud]

uom/19.0.1.0/post-migration.py sets relative_factor = factor for "bigger" units without an xmlid, and 1 / factor for the others. Up to 18.0, though, factor has the same meaning for every uom_type: one reference unit equals factor of the unit. A bigger unit created in the UI (field "Bigger Ratio" = factor_inv) is stored with factor = 1 / ratio, e.g. a dozen has factor = 1/12. So the migrated ratio of every user-created bigger unit is inverted: a "Box of 24" becomes 1/24 of a Unit.

This PR:

• uses relative_factor = 1 / factor for every type;
• creates the test's bigger units with factor_inv, as the 18.0 UI does. The current test data writes factor: 1000000 on a bigger unit, which the UI never produces, and is why the bug passed the test. The expected conversions are unchanged.

How tested:

• 18.0 DB with only uom, data_uom_migration.py loaded: Mm and MA stored with factor = 1e-06, as from the UI.
• Upgraded with this branch. The conversions match the test exactly: dm→Mm 1e-07, Mm→dm 1e+07, mA→MA 1e-09, MA→mA 1e+09.
• Same check on a real-world DB with a user-created bigger unit (1 unit = 10 kg/m³): without the fix it converts to 0.1, with it to 10. Core units (dozen = 12) are unaffected, since units with an xmlid are skipped here.

[hbrunn]

thanks, but please remove uom_type from the select statement and the loop too then

[pedrobaeza]

Please squash the commits together.