If you test this addon after installing `partner_event`, you get this error in all tests:
ERROR: test_validate_pass_reset_error (odoo.addons.password_security.tests.test_res_users.TestResUsers)
` It should throw PassError on reset inside min threshold
Traceback (most recent call last):
` File "/opt/odoo/auto/addons/password_security/tests/test_res_users.py", line 143, in test_validate_pass_reset_error
` rec_id = self._new_record()
` File "/opt/odoo/auto/addons/password_security/tests/test_res_users.py", line 46, in _new_record
` partner_id = self.env['res.partner'].create(self.partner_vals)
` File "/opt/odoo/auto/addons/mail_tracking_mailgun/models/res_partner.py", line 154, in create
` return super(ResPartner, self).create(vals)
` File "/opt/odoo/auto/addons/partner_firstname/models/res_partner.py", line 54, in create
` return super(ResPartner, self.with_context(context)).create(vals)
` File "/opt/odoo/custom/src/odoo/odoo/addons/base/res/res_partner.py", line 532, in create
` partner = super(Partner, self).create(vals)
` File "/opt/odoo/auto/addons/mail/models/mail_thread.py", line 228, in create
` thread = super(MailThread, self).create(values)
` File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3847, in create
` record = self.browse(self._create(old_vals))
` File "/opt/odoo/custom/src/odoo/odoo/models.py", line 4006, in _create
` self.recompute()
` File "/opt/odoo/custom/src/odoo/odoo/models.py", line 5336, in recompute
` vals = rec._convert_to_write({n: rec[n] for n in ns})
` File "/opt/odoo/custom/src/odoo/odoo/models.py", line 5336, in <dictcomp>
` vals = rec._convert_to_write({n: rec[n] for n in ns})
` File "/opt/odoo/custom/src/odoo/odoo/models.py", line 5232, in __getitem__
` return self._fields[key].__get__(self, type(self))
` File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 918, in __get__
` value = record._cache[self]
` File "/opt/odoo/custom/src/odoo/odoo/models.py", line 5584, in __getitem__
` return value.get() if isinstance(value, SpecialValue) else value
` File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 48, in get
` raise self.exception
` AccessError: (u'Sorry, you are not allowed to access this document. Only users with the following access level are currently allowed to do that:\n- Events/User\n\n(Document model: event.registration)', None)
Since creating users or partners in tests has a very high probability to collide with other addons, this test is being moved to post mode.
Also, to avoid the above permissions issue, the partner is actually created through the admin user, which actually has permissions to read everything. Then, it is `.sudo()`ed later, to perform the module tests correctly. The tests do not get affected because what is being tested was not [intended to be] the partner creation itself, but the password policy enforcement.
Include HACK for https://github.com/odoo/odoo/pull/24833, which explains the false positive problem we were having here: an addon being importable doesn't mean it is installed.
The goal was to force developers to write validation logic.
Now it's becoming useless with keychain.backend
And it adds boilerplate code.
In this commit, we set a permissive default validation logic.
It will reduce code in consumers module and still allow fine grained validation.
* [FIX][mass_editing] v9 Fixing error when removing value for fields being translatable, as their translations were not removed.
* Fixing travis errors
* Adding contribution
Without this patch, when upgrading after you have stored the deprecated features parameter, the cursor became broken and no more migrations could happen. You got this error:
Traceback (most recent call last):
File "/usr/local/bin/odoo", line 6, in <module>
exec(compile(open(__file__).read(), __file__, 'exec'))
File "/opt/odoo/custom/src/odoo/odoo.py", line 160, in <module>
main()
File "/opt/odoo/custom/src/odoo/odoo.py", line 157, in main
openerp.cli.main()
File "/opt/odoo/custom/src/odoo/openerp/cli/command.py", line 64, in main
o.run(args)
File "/opt/odoo/custom/src/odoo/openerp/cli/shell.py", line 65, in run
self.shell(openerp.tools.config['db_name'])
File "/opt/odoo/custom/src/odoo/openerp/cli/shell.py", line 52, in shell
registry = openerp.modules.registry.RegistryManager.get(dbname)
File "/opt/odoo/custom/src/odoo/openerp/modules/registry.py", line 355, in get
update_module)
File "/opt/odoo/custom/src/odoo/openerp/modules/registry.py", line 386, in new
openerp.modules.load_modules(registry._db, force_demo, status, update_module)
File "/opt/odoo/custom/src/odoo/openerp/modules/loading.py", line 335, in load_modules
force, status, report, loaded_modules, update_module)
File "/opt/odoo/custom/src/odoo/openerp/modules/loading.py", line 239, in load_marked_modules
loaded, processed = load_module_graph(cr, graph, progressdict, report=report, skip_modules=loaded_modules, perform_checks=perform_checks)
File "/opt/odoo/custom/src/odoo/openerp/modules/loading.py", line 136, in load_module_graph
registry.setup_models(cr, partial=True)
File "/opt/odoo/custom/src/odoo/openerp/modules/registry.py", line 186, in setup_models
cr.execute('select model, transient from ir_model where state=%s', ('manual',))
File "/opt/odoo/custom/src/odoo/openerp/sql_db.py", line 154, in wrapper
return f(self, *args, **kwargs)
File "/opt/odoo/custom/src/odoo/openerp/sql_db.py", line 233, in execute
res = self._obj.execute(query, params)
psycopg2.InternalError: current transaction is aborted, commands ignored until end of transaction block
Now you can safely migrate, be that parameter pre-created or not.
Without this patch, if your tests are run under a `PYTHONOPTIMIZE=2` precompiled environment, they'd fail with this error because a new `.pyo` file would be created.:
FAIL: test_basic (openerp.addons.module_auto_update.tests.test_addon_hash.TestAddonHash)
Traceback (most recent call last):
` File "/opt/odoo/auto/addons/module_auto_update/tests/test_addon_hash.py", line 41, in test_basic
` 'static/src/some.js',
` AssertionError: Lists differ: ['README.rst', 'data/f1.xml', ... != ['README.rst', 'data/f1.xml', ...
`
` First differing element 13:
` models/stuff.pyo
` static/src/some.js
`
` First list contains 1 additional elements.
` First extra element 14:
` static/src/some.js
`
` ['README.rst',
` 'data/f1.xml',
` 'data/f2.xml',
` 'i18n/en.po',
` 'i18n/en_US.po',
` 'i18n/fr.po',
` 'i18n/fr_BE.po',
` 'i18n/test.pot',
` 'i18n_extra/en.po',
` 'i18n_extra/fr.po',
` 'i18n_extra/nl_NL.po',
` 'models/stuff.py',
` 'models/stuff.pyc',
` - 'models/stuff.pyo',
` 'static/src/some.js']
Ran 3 tests in 0.005s
FAILED
With this patch, the `.pyo` file is included, so tests will pass anywhere.
The previous implementation of this addon proved being extremely buggy:
- It supplied out of the box a enabled cron to update Odoo that didn't restart the server, which possibly meant that upgrades broke things.
- It overloaded standard Odoo upgrade methods that made i.e. installing an addon sometimes forced to upgrade all other addons in the database.
- The checksum system wasn't smart enough, and some files that didn't need a module upgrade triggered the upgrade.
- It was based on a dirhash library that was untested.
- Some updates were not detected properly.
- Storing a column into `ir.module.module` sometimes forbids uninstalling the addon.
Thanks to Stéphane Bidoul (ACSONE), now we have new methods to perform the same work in a safer and more stable way.
All I'm doing here is:
- Cron is disabled by default.
- Installed checksums are no longer saved at first install.
- Old installations should keep most functionality intact thanks to the migration script.
- Drop some duplicated tests.
- Allow module uninstallation by pre-removing the fields from ir.mode.model.
- When uninstalling the addon, the deprecated features will get removed for next installs always.
Besides that, fixes for the new implementation too:
- When uninstalling the addon, we remove the stored checksum data, so further installations work as if the addon was installed from scratch.
This code comes from the module_checksum_upgrade proposal
at https://github.com/OCA/server-tools/pull/1176.
* [ADD] module_checksum_upgrade
It provides the core mechanism of module_auto_update without
the cron nor any change to the standard upgrade mechanism.
Instead it provides an API on which module_auto_update can build,
as well as a method which can be called from a script to run
the upgrade of modules for which the checksum has changed.
* [IMP] refactor module_auto_update
Make it depend on module_checksum_upgrade which provides
the core mechanisms of managing the checksums. module_auto_update
makes it automatic.
* [IMP] module_checksum_upgrade: better exclusion mechanism
Ignore files based on exclude patterns.
Ignore uninstalled languages.
Better default for patterns to ignore (*.pyc,*.pyo,*.pot,static/*)
For better control on the hashing mechanism implement our own:
it's quite easy, and the checksumdir module used previously had
no test.
* [MIG] module_auto_update: adapt to new checksum mechanism
* [IMP] module_checksum_upgrade: raise in case of
incomplete upgrade
* [IMP] module_checksum_upgrade: improve default exclusion
pattern
* [IMP] module_checksum_upgrade: control translations
overwrite
* [IMP] module_checksum_upgrade: one more test
* [IMP] module_checksum_upgrade: credits [ci skip]
- Files are clearly suffixed with `_deprecated` so we know those features have no support nor migrations.
- Views are removed, since updating from UI was too buggy to support it anymore.