When checking `Attach Google documents to any record`
in the general settings, if you are not redirected
to a module, but, instead, the current page is refreshed
(the wizard is reloaded instead of creating a new
configuration wizard),
the default value for `google_drive_uri` was not correctly
loaded, the `client_id` in the URL
remained `False` because the wizard was not being
re-created, but reloaded,
and therefore `default_get` hasn't been re-called,
and the `client_id` changed
(it was added to the system parameters after
the installation of the module)
Therefore, the link did not include the correct
`client_id`, and it leaded to the inabibility
to use the URL:
401. That’s an error.
The OAuth client was not found.
Replacing the simple char fields by a function
field, with the correct store trigger,
force the URL value to be reloaded
when the system parameter is inserted.
opw-673274
This commit removes the request of having gzip or deflate data for two
requests to google drive API.
Previously the code worked since google api would send ungzipped data
(maybe base on urllib2 user agent or other input parameters) but after
a recent change on google part, it is not anymore the case.
closes#8243
opw-648007
note: if we did not do this, we would either need to use requests or add
custom uncompressing code for urllib2 response content.
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.
Rebranding has been done in:
- data/demo files
- html templates
- help notices
- comments
- logger messages
- and other various messages
(Commit taken from odoo-dev:8.0-improve-openerp-odoo-rlu at rev 7deaa08)
Closes#1260
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
We used to give write access to the email address of the current user, but if the email is not a google account, there is no way for the current user to write on the data (except if the current email address is also the email which has done the oauth activation in the settings).
bzr revid: dle@openerp.com-20140115093528-ir39ppqrinjqyeta
Persist the auth code in the settings to show
that it has already been set, even if it is not
technically used by the system.
Also fixed a variable referenced before assignment.
bzr revid: odo@openerp.com-20131016163908-9d05x85me3n30ala
Christophe Simonis