In manufacturing bom lines, digits_compute is set
to the precision 'Product Unit of Measure'.
It should be the case as well in the produce wizard,
otherwise you won't be able to change the quantity
within this wizard to the according product quantity precision
opw-629657
Unify and refactor exception handling in framework and addons.
The generic `except_osv` is now deprecated, and replaced by more specialized exception subtypes:
- `UserError` (renamed from Warning, as it conflicts with the built-in `Warning`) raised when a non-technical error occurs during a business operation. It could be a missing information in the data provided by the user, or a misconfiguration.
- `AccessError`: raised when any operation is denied because the user conducting it does not have the required access rights.
- `AccessDenied`: raised when an operation that requires authenticated access is attempted via an unauthenticated request.
- `MissingError`: raised when an operation is attempted on a record that does not exist.
- `ValidationError`: raised when an operation violates a SQL or Python constraint.
- All other exceptions are internal errors due to a system problem or bug, and raised untouched to the client-side, which should display a traceback.
All exceptions take a single message argument.
The `test_exceptions` module has been updated to showcase both new and old (deprecated) exceptions.
A great many old `except_osv` had a useless title with "Error!" or "Warning", those have been removed, as this is handled by the client-side widget that displays the messages.
This commit introduces a more consistent policy for logging errors and warnings:
- All messages that do not require administrator attention should be logged at INFO level or lower. This includes all errors that are notified to the user in a friendly manner, even for access right problems or validation errors during business operations.
- All messages that indicate a likely misconfiguration or malicious use by the users should be logged at WARNING level, as they typically require administrator attention.
- All other unhandled internal errors cannot typically be handled by the user and should be logged at ERROR or higher level, as they require immediate administrator attention.
Module description of procurement was deprecated (talking about mrp, ...) and in product_extended
it described things not implemented in the module.
In _bom_find, we passed a UoM which was not used in Saas-4 and it would not be logical that you
need to select a BoM that matches the UoM, so I removed it.
In the demo data, there was still a push rule which triggered a move from output to pack. The copy=False
is correct for production_id when you would have these push rules.
For the properties: we want to allow to take a bom which has no properties, but only when there is no other
BoM matching the properties we pass.
Update module descriptions
[IMP] production_id copy + no round
[IMP] _bom_find without uom, property correction
Simplify the action_consume of the consumption lines after the corrections
by Kevin Wang. Also the UoMs are revised as the action_consume uses the default UoM
of the product.
We have to avoid circular boms where a child bom should not contain the product that
represents the parent bom, but it is possible for example to use another product of the parent bom in
the child bom.
As the consume line move has no procurement rule, its origin will have no description. So, when there is
none it will also check the description of the previous move (when passed to procurement for example) This way
the chained moves or purchase order for example will have the MO-number as origin and not nothing.
[IMP] Change assignation
[IMP] UoM changes continuation
[IMP] Make sure we can use 2 times the same product in a BoM
[IMP] Source document for consume lines to procurement
Christophe Simonis