How great is it to get Odoo (almost) 9.0 (almost) translated?
Clean .tx/config file
Regenerate .pot files
Fetch current translations from Transifex (10% completion)
Now that most refactoring has been merged
It is better to have red a great work of another culture in translation than never to have read it at all.
― Henry Gratton Doyle
When a bank statement acquisition method (file import, plaid, manual encoding)
is used on a journal, it should only be set as the journal's
bank_statements_source after successful completion.
- use a wizard to ask about creating a new bank account + journal
- fix 'Import Statement' action from the dashboard
- make l10n_be_coda new-api-compliant
- bank statement import: misplaced parenthesis
- payment: show the 'Post' button no matter the payment method
- payment: fixed some attrs in payment form view
In previous versions the system would simply refuse to import
a bank statement if the corresponding journal/account did
not exist.
As of 9.0 the system can create them automatically, but
should not do that without asking for confirmation first,
to avoid user mistakes with dangerous consequences.
Closes#6023
If the method `import_file` is called with the new API, the context is a
frozendict and the update will raise `NotImplementedError: 'update' not
supported on frozendict`
closes#5798
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.
Odoo Translation Bot