On the wizard 'Gengo: Manual Request of Translation' display a warning
if the credentials are missing or unauthorized by gengo via the method
gengo_authentication, with a link to the company form view for the user
to be able to configure it.
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
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.
removed js that let user to uncheck radiobutton and from addons removed radiobuttons used for not required field except sync_typ.
changed this field as required because of functional requirement
Basically the admin group can read the gengo key. When adding website_gengo that adds the
website groups, the groups allowed to access the key are updated.
This is done because in base_gengo the website groups are not necesssarily defined. Website
is not a dependency of base_gengo.
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
- if any changes like acception of job,approval of job, comment by translator etc gengo will post that job to given callback url
- On otherside added a controller for '/website/gengo_callback' for handling callback.
so any chages on job will instantly reflected to openerp
bzr revid: pga@tinyerp.com-20140331121932-3u2usycyftdrqcrw
* database scheme simplification
* merge of boolean on ir.translation and selection fields on res.company to select the tier (level service of gengo), which is now located on ir.translation
* move of all the new features in a new wizard
* removal of wizard to display the results
bzr revid: qdp-launchpad@openerp.com-20120830161429-h7rti6hbnrk8mozg
Swapnesh Shah