[trunk-website-al] ir_rule#_compute_domain caching destroys anonymous browsing for ecommerce

Bug #1265917 reported by Raphaël Valyi - http://www.akretion.com
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Odoo Server (MOVED TO GITHUB)
In Progress
High
OpenERP's Framework R&D

Bug Description

Hello,

How to reproduce:
on a fresh installation with demo data of server, addons and web trunk-website-al branches or on runbot here:
http://trunk-website-al-27183.runbot.openerp.com/shop

go in the /shop web module. Eventually log as public/public if you pass through the web interface.

try to add some e-commerce product to the shopping cart:
you may get a 403 error.

In fact, the very first browser session that try to connect to the shopping cart, will be able use the shopping cart.
BUT any subsequent session (it's likely your aren't the first on the runbot) will get the bug.
if you don't know how to create a new session, use your browser in anynomous mode and browse again for instance.

Why?

It because in the sale.order read, there is a domain like:
['(("sale_order"."company_id" IS NULL OR ("sale_order"."company_id" in (%s,%s,%s))) AND ((("sale_order"."state" = %s) AND "sale_order"."website_session_id" IS NOT NULL) AND ("sale_order"."website_session_id" = %s)))']

but in the evaluation, website_session_id will be always evaled to the website_session_id of the first website user that browsed the page as public/public.

This is because in openerp/addons/base/ir/ir_rule.py

it will enter around line 106 in:
    @tools.ormcache()
    def _compute_domain(self, cr, uid, model_name, mode="read"):
        if mode not in self._MODES:
            raise ValueError('Invalid mode: %r' % (mode,))

But the issue is the tools.ormcache decorator will cache the domain result param according to the explicit entry params of the _compute_domain method but without any consideration for the werkzeug session params such as website_session_id. Hence all different users get the same domain despite they use the same session so they'will miss there sale.order because they will look for it with a website_session_id that isn't theirs...

A simple way to ensure the bug is as I described is to simply remove @tools.ormcache(). Now users can see their cart information normally.

I imagine you should craft some tools.ormcache decorator that will take the session_id into account, but I'm not sure how bad will be the performance impact of that. Obviously it will badly hit the ability to mutualize the cache accross the portal users...
Still it seems somewhat required.
That leads to my considerations that the caching should move to the frontend web framework wherever possible and that may be trying to reinvent the wheel in the CMS part wasn't that great as you'll need to reinvent all that without a big skilled developer base to test and make it.

In any case I prefer your approach of a single portal user with that dynamic domain matching according to the session so please don't abandon to get a flood of ERP users for all portal users or something crazy like that.

Hope this helps and kudos for the shopping cart job and framework improvement around this and best wishes of success for 2014.

Revision history for this message
Nicolas JEUDY (njeudy) wrote :

I raphael, I just test it and reproduce it.
Hope this will change soon :)

Revision history for this message
Twinkle Christian(OpenERP) (tch-openerp) wrote :

Hello,

This trunk-website-al project task is in under development. Still it is not released in latest trunk. We will consider this issue and our expert will work on it, thanks for reporting this issue it will improve more .

But for now, We can not consider it as bug. So, Currently I am closing this issue.

Hope you understand.. !!

Thank you.

Changed in openobject-server:
status: New → Invalid
Revision history for this message
Nhomar - Vauxoo (nhomar) wrote : Re: [Bug 1265917] Re: [trunk-website-al] ir_rule#_compute_domain caching destroys anonymous browsing for ecommerce

2014/1/6 Twinkle Christian(OpenERP) <email address hidden>

> But for now, We can not consider it as bug. So, Currently I am closing
> this issue.
>
> Hope you understand.. !!
>

Hello.

Can you extend your answer and enlight us where is the correct place to
give early feedback please.

I understand you are closing this bug to avoid cross control of your
automation of bugs, but it is important to use you give us the right path.

THanks in advance.

Regards.

--
--------------------
Saludos Cordiales

Nhomar G. Hernandez M.
+58-414-4110269
Skype: nhomar00
Web-Blog: http://geronimo.com.ve
Servicios IT: http://vauxoo.com
Linux-Counter: 467724
Correos:
<email address hidden>
<email address hidden>
twitter @nhomar

Revision history for this message
Thibault Delavallée (OpenERP) (tde-openerp) wrote :

Well, for "basic" bug I agree with Twinkle Christian; but as we are working on the website and especially on caching issues, let's consider this bug as valid :) .

Changed in openobject-server:
status: Invalid → In Progress
importance: Undecided → High
Revision history for this message
Raphaël Valyi - http://www.akretion.com (rvalyi) wrote :

Ahhhhh :-)

I was also kind of finding strange you would sell the ecommerce https://www.openerp.com/oe_pricing with such a basic blocker bug...

Thanks for looking at that then.

Changed in openobject-server:
assignee: nobody → OpenERP's Framework R&D (openerp-dev-framework)
Revision history for this message
Raphaël Valyi - http://www.akretion.com (rvalyi) wrote :

Hello,

I just tested that bug on https://shop.openerp.com/shop/mycart/ and it seems fixed now.
Can we set it to fixed?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.