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.
Only admin was able to create product.putaway records. Gives all access
to warehouse manager.
If a putaway strategy was present on a location, a warehouse user was not able
to transfer goods as he had no access to the rule lines (no read to
stock.fixed.putaway.strat). Give read access. opw 619774
When invoicing from dropshipping picking, choose the correct partner.
Also, change the partner on the picking to be the partner of the purchase.
Change the picking report to include the destination partner or the warehouse address on the right.
[IMP] Only put partner_id on move from purchase when really necessary
[FIX] Default value of partner on stock move should be False
If a stock picking type was disabled, but had pickings in assigned or partially available state, the barcode interface main menu crashed
Because the stock picking type was not available in pickings_by_type array
If a wizard is launched from an embedded view list, only the record of the line from which the wizard was launched is reloaded after closing the wizard.
In this specific case, as new lines are added to the picking, we need to fully reload the stock picking
Fixes comparison with min_quantity orderpoint in scheduler - basic floating
point math issue in procurement scheduler when comparing current quantity
with orderpoint minimum quantity. In certain cases floating point comparison
could result in e.g 400.0 < 400.0 == True due to typical floating point
comparison issues, as Odoo doesn't use Decimal types where the issue
doesn't exist.
Fixes early exiting out of the loop cycle, in case qty is already near zero.
Fixes the new procurement creation check, to not do that if it's close
enough to zero already, to be considered a floating point math error, not
really non-zero.
These combined (or at least the last one) avoid each supply_method == buy
pending in draft PO's getting a zero quantity extra procurement order each
time the scheduler runs. Otherwise there could be hundreds of zero quantity
procurement orders pending, which makes the confirming of the PO take hours,
due to creating hundreds of stock moves for each order line.
Use float_compare helper to solve all these with floating point type for now,
instead of the more evasion possibility of converting to Decimal module.
Two potential bad comparisons remain, add FIXME notes for now until further
analysis.
Also: Float rounding on reste when comparing and on the procurement qty
Christophe Simonis