diff options
| author | Xavier Morel <xmo@odoo.com> | 2015-10-01 17:32:26 +0200 |
|---|---|---|
| committer | Xavier Morel <xmo@odoo.com> | 2015-10-02 11:25:42 +0200 |
| commit | 20bab327d478cfe8c7cdf95f74d4e1598b21e7b7 (patch) | |
| tree | bb125eedf3df551cd25f5c2e6fc8f86941eb722f /addons/mass_mailing/static/src/js | |
| parent | 3a26046b88b7605f1903d34bedf051af1b074c42 (diff) | |
[FIX] possible incorrect request.env
On a new database, logged as administrator, installing
``website_slides`` commonly (but not systematically) leads to a 403
error when the module install redirects to the slides
index (``/slides``).
The issue here is the installation of the slides module deletes the
existing routing map, which needs to be regenerated. The regeneration is
performed at the start of URL dispatching *before authentication* but
accesses ``request.env` in order to look up the list of installed
modules, which generates and caches (due to env being a lazy_property)
an ``Environment(cr, None, context)``.
Once regeneration and auth are done the controller is executed with
``request.env`` still being set to ``Environment(cr, None, context)``
and thus the first tentative access (search) to an object blowing up
with an AccessError. The next request or an initial request not
accessing ``request.env`` will work fine as they'll reuse the routing
map generated by the initial request.
Fixed by just getting the set of installed modules from the registry.
Diffstat (limited to 'addons/mass_mailing/static/src/js')
0 files changed, 0 insertions, 0 deletions
