summaryrefslogtreecommitdiff
path: root/addons/base_import_module/models/ir_module.py
AgeCommit message (Collapse)Author
2019-03-06[IMP] base_module_import: ignore garbage directoriesxmo-odoo
If the zipfile contains some garbage directories (e.g. leftover empty directories from git, `__MACOSX` metadata folder, …) it seems unnecessary to log an error, just skip the directory and don't mark it as a proper / successful module. closes odoo/odoo#31639 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
2017-06-07[MERGE] Forward-port saas-11 up to fff4af36abb28a26977928455fe20fbcd135399eOlivier Dony
2017-06-07[MERGE] Forward-port saas-6 up to b604f3b3daf063a621bb118befb5a0fd792f0af0Olivier Dony
2017-06-07[MERGE] Forward-port 8.0 up to c6b9b69f6a483e7ccebf0b823240b71a8f426fd3Olivier Dony
2017-06-07[FIX] base_import_module: allow selective access to module filesOlivier Dony
As a consequence of rev. 76cd8d2558d2a1fc11681dbc4a134ba06fb698c0, imported modules were unable to access their resource files during import. Rather than further modifying the file_open API to whitelist paths (the whole thing needs a redesign in master), we temporarily whitelist the temporary directory by including it in the global addons_paths, making sure to undo it afterwards. This gives all lower level function access the resource files via file_open, without having to pass around whitelisted paths through many different calls.
2016-10-10[MERGE] forward port branch saas-12 up to 43cb4acChristophe Simonis
2016-10-03[MERGE] Forward-port 8.0 up to 3d55aff1c83d3157228852d1fe28efe82d7cc329Olivier Dony
2016-10-03[FIX] base_import_module, tools: raise a clear error for unsupported file typesOlivier Dony
Also restrict XML data attribute evaluation context even for real module data files. This will prevent accidentally depending on context parameters that would not be available inside base_import_module.
2016-10-03[FIX] base_import_module, tools: raise a clear error for unsupported file typesOlivier Dony
Also restrict XML data attribute evaluation context even for real module data files. This will prevent accidentally depending on context parameters that would not be available inside base_import_module.
2016-07-13[MIG] base_import_module: Migrated to new APIMohammed Shekha
2015-11-25[MERGE] forward port of branch saas-6 up to dade7e3Christophe Simonis
2015-11-17[MERGE] forward port of branch 8.0 up to c9fce1aDenis Ledoux
2015-11-06[FIX] base_import_module: exception logger for module importsDenis Ledoux
When importing a module, if an error was raised during the import, the traceback wasn't displayed anywhere, making harder the debugging. While it make sense to not display the entire traceback to the user, in the web client, this is useful to diplay the traceback in the logs, for debugging purposes. opw-653882
2015-10-01[MERGE] forward port of branch saas-6 up to e9f1ee4Christophe Simonis
2015-09-30[MERGE] Forward-port 8.0 up to rev. 26d0fe6d9f645ec128182bb2f4f8b9808ad05004Olivier Dony
2015-09-28[FIX] base_import_module: special chars in error messagesArnaud Pineux
use ustr() instead of str() to avoid traceback with translations Closes #4272
2015-08-31[ADD] base_import_module: add boolean field `imported` on `ir.module.module`Thomas Groutars
2015-01-16[IMP] Cleanup and refactoring of exception handlingGoffin Simon
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.
2014-09-05[FIX] Some fixes for base_import_moduleFabien Meghazi
- Properly check unmet dependencies - Set imported module's state to 'installed' - Fix bad translation usage
2014-06-11Added --force to odoo deployFabien Meghazi
Will force --init mode even if module is already installed
2014-05-22[IMP] improved code to show import result in wizard and improved typotpa-odoo
2014-05-22[ADD] add wizard to import zipped moduletpa-odoo
2014-03-24[IMP] Properly import filesFabien Meghazi
bzr revid: fme@openerp.com-20140324151711-89mfg14573dpnh0p
2014-03-20[IMP] static file injected in ir.attachmentFabien Meghazi
bzr revid: fme@openerp.com-20140320143346-nimxg7c61lm1253x
2014-03-19[WIP] base_import_moduleFabien Meghazi
bzr revid: fme@openerp.com-20140319085343-zkee3rmqc9dzpa7h