bug with share_create object

[Aline (OpenERP)]

in trunk (tested on chrome and web client)

create a db. In configuration wizard, install extra tools and then, web share.
I got a bug :

In server side :
----------------------------

[2011-06-14 10:52:24,172][?] ERROR:web-services:Uncaught exception
Traceback (most recent call last):
  File "/home/aline/openerp/server/trunk/openerp/osv/osv.py", line 122, in wrapper
    return f(self, dbname, *args, **kwargs)
  File "/home/aline/openerp/server/trunk/openerp/osv/osv.py", line 176, in execute
    res = self.execute_cr(cr, uid, obj, method, *args, **kw)
  File "/home/aline/openerp/server/trunk/openerp/osv/osv.py", line 167, in execute_cr
    return getattr(object, method)(cr, uid, *args, **kw)
AttributeError: 'share_create' object has no attribute 'has_share'

<type 'exceptions.AttributeError'>
Python 2.6.5: /usr/bin/python
Tue Jun 14 10:52:54 2011

A problem occurred in a Python script. Here is the sequence of
function calls leading up to the error, in the order they occurred.

 /home/aline/openerp/server/trunk/openerp/netsvc.py in dispatch(self=<TinySocketClientThread(netrpc-client-127.0.0.1:47265, started 140017077249792)>, service_name='object', method='execute', params=('testbug_14juin', 1, u'a', 'share.wizard', 'has_share'))
  426 self.log('service', tuple(replace_request_password(params)), depth=(None if logger.isEnabledFor(logging.DEBUG_RPC_ANSWER) else 1), fn='%s.%s'%(service_name,method))
  427 auth = getattr(self, 'auth_provider', None)
  428 result = ExportService.getService(service_name).dispatch(method, auth, params)
  429 self.log('result', result, channel=logging.DEBUG_RPC_ANSWER)
  430 return result
result undefined
global ExportService = <class 'openerp.netsvc.ExportService'>
ExportService.getService = <bound method type.getService of <class 'openerp.netsvc.ExportService'>>
service_name = 'object'
).dispatch undefined
method = 'execute'
auth = None
params = ('testbug_14juin', 1, u'a', 'share.wizard', 'has_share')

 /home/aline/openerp/server/trunk/openerp/service/web_services.py in dispatch(self=<openerp.service.web_services.objects_proxy object>, method='execute', auth=None, params=('share.wizard', 'has_share'))
  577 ls = netsvc.LocalService('object_proxy')
  578 fn = getattr(ls, method)
  579 res = fn(db, uid, *params)
  580 return res
  581
res undefined
fn = <bound method object_proxy.execute of <openerp.osv.osv.object_proxy object>>
db = 'testbug_14juin'
uid = 1
params = ('share.wizard', 'has_share')

 /home/aline/openerp/server/trunk/openerp/osv/osv.py in wrapper(self=<openerp.osv.osv.object_proxy object>, dbname='testbug_14juin', *args=(1, 'share.wizard', 'has_share'), **kwargs={})
  120 if pooler.get_pool(dbname)._init:
  121 raise except_osv('Database not ready', 'Currently, this database is not fully loaded and can not be used.')
  122 return f(self, dbname, *args, **kwargs)
  123 except orm.except_orm, inst:
  124 if inst.name == 'AccessError':
f = <function execute>
self = <openerp.osv.osv.object_proxy object>
dbname = 'testbug_14juin'
args = (1, 'share.wizard', 'has_share')
kwargs = {}

 /home/aline/openerp/server/trunk/openerp/osv/osv.py in execute(self=<openerp.osv.osv.object_proxy object>, db='testbug_14juin', uid=1, obj='share.wizard', method='has_share', *args=(), **kw={})
  174 if method.startswith('_'):
  175 raise except_osv('Access Denied', 'Private methods (such as %s) cannot be called remotely.' % (method,))
  176 res = self.execute_cr(cr, uid, obj, method, *args, **kw)
  177 if res is None:
  178 self.logger.warning('The method %s of the object %s can not return `None` !', method, obj)
res undefined
self = <openerp.osv.osv.object_proxy object>
self.execute_cr = <bound method object_proxy.execute_cr of <openerp.osv.osv.object_proxy object>>
cr = <openerp.sql_db.Cursor object>
uid = 1
obj = 'share.wizard'
method = 'has_share'
args = ()
kw = {}

 /home/aline/openerp/server/trunk/openerp/osv/osv.py in execute_cr(self=<openerp.osv.osv.object_proxy object>, cr=<openerp.sql_db.Cursor object>, uid=1, obj='share.wizard', method='has_share', *args=(), **kw={})
  165 if not object:
  166 raise except_osv('Object Error', 'Object %s doesn\'t exist' % str(obj))
  167 return getattr(object, method)(cr, uid, *args, **kw)
  168
  169 @check
builtingetattr = <built-in function getattr>
object = <share.wizard.share_wizard.share_create object>
method = 'has_share'
cr = <openerp.sql_db.Cursor object>
uid = 1
args = ()
kw = {}
<type 'exceptions.AttributeError'>: 'share_create' object has no attribute 'has_share'
    __class__ = <type 'exceptions.AttributeError'>
    __delattr__ = <method-wrapper '__delattr__' of exceptions.AttributeError object>
    __dict__ = {}
    __doc__ = 'Attribute not found.'
    __format__ = <built-in method __format__ of exceptions.AttributeError object>
    __getattribute__ = <method-wrapper '__getattribute__' of exceptions.AttributeError object>
    __getitem__ = <method-wrapper '__getitem__' of exceptions.AttributeError object>
    __getslice__ = <method-wrapper '__getslice__' of exceptions.AttributeError object>
    __hash__ = <method-wrapper '__hash__' of exceptions.AttributeError object>
    __init__ = <method-wrapper '__init__' of exceptions.AttributeError object>
    __new__ = <built-in method __new__ of type object>
    __reduce__ = <built-in method __reduce__ of exceptions.AttributeError object>
    __reduce_ex__ = <built-in method __reduce_ex__ of exceptions.AttributeError object>
    __repr__ = <method-wrapper '__repr__' of exceptions.AttributeError object>
    __setattr__ = <method-wrapper '__setattr__' of exceptions.AttributeError object>
    __setstate__ = <built-in method __setstate__ of exceptions.AttributeError object>
    __sizeof__ = <built-in method __sizeof__ of exceptions.AttributeError object>
    __str__ = <method-wrapper '__str__' of exceptions.AttributeError object>
    __subclasshook__ = <built-in method __subclasshook__ of type object>
    __unicode__ = <built-in method __unicode__ of exceptions.AttributeError object>
    args = ("'share_create' object has no attribute 'has_share'",)
    message = "'share_create' object has no attribute 'has_share'"

The above is a description of an error in a Python program. Here is
the original traceback:

Traceback (most recent call last):
  File "/home/aline/openerp/server/trunk/openerp/netsvc.py", line 428, in dispatch
    result = ExportService.getService(service_name).dispatch(method, auth, params)
  File "/home/aline/openerp/server/trunk/openerp/service/web_services.py", line 579, in dispatch
    res = fn(db, uid, *params)
  File "/home/aline/openerp/server/trunk/openerp/osv/osv.py", line 122, in wrapper
    return f(self, dbname, *args, **kwargs)
  File "/home/aline/openerp/server/trunk/openerp/osv/osv.py", line 176, in execute
    res = self.execute_cr(cr, uid, obj, method, *args, **kw)
  File "/home/aline/openerp/server/trunk/openerp/osv/osv.py", line 167, in execute_cr
    return getattr(object, method)(cr, uid, *args, **kw)
AttributeError: 'share_create' object has no attribute 'has_share'

[Olivier Dony (Odoo) (odo-openerp)]

Aline,

I'm closing this bug as Invalid, the issue is caused by testing the new "share" wizard from the current feature branch, and then going back to normal trunk. The feature branch installs a newer "web addon" that will stay in the web client, and will not be backwards compatible with the old module in trunk.
So this is specific to your computer that was used for testing new features.

You can fix it by deleting the "addons/share" directory in your web client directory and then restarting the web client :-)

The issue will also fix itself as soon as we merge the feature branch, which should be this week.

[Dominique Chabord (dominique-chabord)]

Olivier
thank you for this answer. Can you just be more precise on the following questions:

Some are signaling this failure on 6.0.2, and these people don't have access to web client directory.
Is it the same answer to them ?

Do you mean these people uploaded something in the code of the web-client on the server ? Or the server admin only can do it ?
Thank you for answering these basic questions, but I wasn't aware of this possibility up to now on V6.0.2
regards

[Dominique Chabord (dominique-chabord)]

This bug affects 6.0.2, which seems in contradiction with you explaination. I never tested new features on this server.

Traceback (most recent call last):
  File "/home/sisalpuser/openerp/server/bin/netsvc.py", line 489, in dispatch
    result = ExportService.getService(service_name).dispatch(method, auth, params)
  File "/home/sisalpuser/openerp/server/bin/service/web_services.py", line 599, in dispatch
    res = fn(db, uid, *params)
  File "/home/sisalpuser/openerp/server/bin/osv/osv.py", line 122, in wrapper
    return f(self, dbname, *args, **kwargs)
  File "/home/sisalpuser/openerp/server/bin/osv/osv.py", line 176, in execute
    res = self.execute_cr(cr, uid, obj, method, *args, **kw)
  File "/home/sisalpuser/openerp/server/bin/osv/osv.py", line 167, in execute_cr
    return getattr(object, method)(cr, uid, *args, **kw)
AttributeError: 'share_create' object has no attribute 'has_share'

[Dominique Chabord (dominique-chabord)]

I followed this hint
You can fix it by deleting the "addons/share" directory in your web client directory and then restarting the web client

and restarted all web-clients which shared this code. I'll ask users if this fixes the problem.

If I understand correctly what Odony says, the code of client-web is updated when a user connects to an openerp-server, depending in the version of the module in this openerp-server.
This implies a web-client code cannot be used several times for several web-client processes.
If right, then this is a regression of client-web, but I'm not sure because I cannot locate any piece of documentation so far.
regards

[Olivier Dony (Odoo) (odo-openerp)]

On 06/22/2011 05:37 PM, Dominique Chabord wrote:
> Some are signaling this failure on 6.0.2, and these people don't have
> access to web client directory. Is it the same answer to them ?

What error do you mean, the exact same one about "share_create" object
having no "has_share" attribute?
This was not very likely until last friday, because this attribute only
existed in a separate development branch. Now this new version of the
"share" module has been merged in trunk, so it could in theory happen if
you connect your web client to a trunk server, and then go back to a 6.0
server.

> Do you mean these people uploaded something in the code of the
> web-client on the server ? Or the server admin only can do it ? Thank
> you for answering these basic questions, but I wasn't aware of this
> possibility up to now on V6.0.2 regards

The users don't upload anything themselves, but as soon as you login
using the 6.0 web client (or later) onto an OpenERP server, it queries
the server to know about any installed modules that contain "web
addons", in order to install them automatically.
The installation is done (in 6.0) by retrieving the zipped version of
the web component from the server (there's a special method for that on
the ir.module object), and deploying it locally in the web client.
This mechanism has a built-in update detection so that it will upgrade
the web components if the server-side has a newer version of the module.
All of the above is restricted to admins by default, as only
administrators may install modules on a server. The difference is that
modules can now be split into 2 parts: one part stays server-side, and
another part goes in the web client side (and may also contain python
code, static resources, etc.)

One limitation is that there is no auto-downgrade mechanism, so
connecting a web client to an older version of the OpenERP server/addons
might cause issues under some circumstances (as in the current bug,
where the newer version of the web component is not backwards-compatible).
There's a simple way for system admins to solve the issue: after
changing the config of the web client to go to a different (older)
server, they can just delete all non-core web addons from the "addons"
subdirectory (1 subdir = 1 web addon).
The core web addons that should not be deleted are those that are part
of the standard install:
 - openerp
 - view_calendar
 - view_diagram
 - view_graph
 - widget_ckeditor

Hope this makes matters more clear...

[Dominique Chabord (dominique-chabord)]

Thank you very much Odony,
your explaination is excellent.
This is bad news, but better understand what is happening.
In my case, client web cannot have been connected to trunk for practical reasons so the only remaining question is why this happened on 6.0.2 .I checked and nobody uploaded a .zip version of web_addon on the servers.

This design means you dropped the capability for a code directory to be used several times for several process. (This so far useless duplication would cost ~15 GB of SSD disk if I cannot avoid it :-( )
Correct design would be to add a path to addon directory in the config file, so each process can update separatly if they connect to different openerp servers. I'm still puzzled by this way to update a web client on the fly.

thank you again for your detailled answer.
regards

[Olivier Dony (Odoo) (odo-openerp)]

On 06/27/2011 03:55 PM, Dominique Chabord wrote:
> Thank you very much Odony, your explaination is excellent. This is
> bad news, but better understand what is happening. In my case, client
> web cannot have been connected to trunk for practical reasons so the
> only remaining question is why this happened on 6.0.2 .I checked and
> nobody uploaded a .zip version of web_addon on the servers.

In fact I just checked, and this same 'has_share' attribute has been
added recently in 6.0 addons branch at revision 4637.
This was not in 6.0.2, but will be part of 6.0.3. I suppose somehow your
web client has been connecting to a server that has the (future) 6.0.3
version of the 'share' module, and later to another one that does not
have it?

> This design means you dropped the capability for a code directory to
> be used several times for several process. (This so far useless
> duplication would cost ~15 GB of SSD disk if I cannot avoid it :-( )

Unfortunately, being able to execute several web client instance within
the same directory has never been a documented feature as far as I know.
We don't execute multiple web client instances from the same directory,
not even in our SaaS server.
So it's just that in 6.0 we introduced web addons, and decided to store
them in the same location as the core addons that are builtin in the web
client.

> Correct design would be to add a path to addon directory in the
> config file, so each process can update separatly if they connect to
> different openerp servers. I'm still puzzled by this way to update a
> web client on the fly.

Sorry if this design conflicts with the way you were using the 5.0 web.
Every day we have to take design decisions, and for sure some of them
conflict with the way someone else was using OpenERP. We always try to
be backwards compatible with documented API and features, but we can't
always preserve compatibility with undocumented features, or side
effects of the previous design.

I suppose you may need to extend/modify the web client for your own
hosting needs, if you want to avoid this.

BTW, the web client does manage web addons on a per-database basis, so
each session will only use the relevant web addons. Therefore if your
multiple clients all connect to the same server, with the same addons
versions, users should not see anything - that's perhaps an order of
magnitude less instances needed. The current design is meant to allow
running hundreds of databases in a single server process and a single
web client process - you can isolate databases from each other, so
privacy is preserved.

Be careful that the web client also automatically reloads as soon as its
files change, so sharing the same directory may have other side-effects
and cause spurious restarts.

[Dominique Chabord (dominique-chabord)]

Thank you again for your time, I think you are writing a widely awaited documentation in this thread.
Le 27/06/2011 18:10, Olivier Dony (OpenERP) a écrit :
> On 06/27/2011 03:55 PM, Dominique Chabord wrote:
>
> In fact I just checked, and this same 'has_share' attribute has been
> added recently in 6.0 addons branch at revision 4637.
> This was not in 6.0.2, but will be part of 6.0.3. I suppose somehow your
> web client has been connecting to a server that has the (future) 6.0.3
> version of the 'share' module, and later to another one that does not
> have it?

correct. my users can order a 6.0.2 version or a 6.0.2-launchpad version which is impacted by this change.
This explains the problem.
>
>
>> This design means you dropped the capability for a code directory to
>> be used several times for several process. (This so far useless
>> duplication would cost ~15 GB of SSD disk if I cannot avoid it :-( )
>
> Unfortunately, being able to execute several web client instance within
> the same directory has never been a documented feature as far as I know.

Where are client web features documented since 1.0 ? ;-)
It was for me a state-of-the-art rule, but seems it's not.
It was discussed and considered by Amit for the 1.0.

> We don't execute multiple web client instances from the same directory,
> not even in our SaaS server.

It worked perfectly till now and eases updates

> So it's just that in 6.0 we introduced web addons, and decided to store
> them in the same location as the core addons that are builtin in the web
> client.

nobody is perfect ;-)
>
>
>> Correct design would be to add a path to addon directory in the
>> config file, so each process can update separatly if they connect to
>> different openerp servers. I'm still puzzled by this way to update a
>> web client on the fly.
>
> Sorry if this design conflicts with the way you were using the 5.0 web.

V5 customers are not impacted at all. This design impacts the "not-so-stable" 6.0. I should not have to reconsider administration rules on a stable version.

> Every day we have to take design decisions, and for sure some of them
> conflict with the way someone else was using OpenERP. We always try to
> be backwards compatible with documented API and features, but we can't
> always preserve compatibility with undocumented features, or side
> effects of the previous design.

I understand the engineer didn't understand what a "stable" version should be, A path in the configuration with a default value as you wish it to be, as far as I know, is the standard design for backward compatibility and avoid to destabilize production servers.
>
> I suppose you may need to extend/modify the web client for your own
> hosting needs, if you want to avoid this.

yes, another one.

>
> BTW, the web client does manage web addons on a per-database basis, so
> each session will only use the relevant web addons. Therefore if your
> multiple clients all connect to the same server, with the same addons
> versions, users should not see anything - that's perhaps an order of
> magnitude less instances needed. The current design is meant to allow
> running hundreds of databases in a single server proce...

[Olivier Dony (Odoo) (odo-openerp)]

On 06/28/2011 12:07 PM, Dominique Chabord wrote:
> I understand the engineer didn't understand what a "stable"
> version should be

This changed as of 6.0 release. 5.0 series and 6.0 series are different
stable series. There may be any number of changes between 2 series, the
policy for stable series only holds within *the same* stable series,
obviously.

[Dominique Chabord (dominique-chabord)]

I confirm that we understand the same and we agree : it should have been better to think a bit before changing software features between 6.0.2 and 6.0.3, exactly for the basic rules you remind. ;-)
regards

[Dominique Chabord (dominique-chabord)]

"> Unfortunately, being able to execute several web client instance within
> the same directory has never been a documented feature as far as I know. "

for the record, here is the time when this feature was supported by the author of eTiny aka openerp-web
http://www.openerp.com/forum/topic5216.html

[Olivier Dony (Odoo) (odo-openerp)]

On 07/01/2011 11:06 AM, Dominique Chabord wrote:
>> Unfortunately, being able to execute several web client instance
>> within the same directory has never been a documented feature as
>> far as I know. "
>
> for the record, here is the time when this feature was supported by
> the author of eTiny aka openerp-web
> http://www.openerp.com/forum/topic5216.html

Thanks for the reference. Doesn't change what I said, it was not a
"designed feature", it just happened to be possible, and Amit told you
so, to help you in the setup of your SaaS service.

Moreover, even it if was a fully documented technical spec, these can
change for each new major version. For example you can currently run
OpenERP with postgres 8.3 and python 2.5, and perhaps for 6.1 we'll drop
that capability and required postgres 8.4 or python 2.6.
No, that won't be a "regression", just a change, because there will be
nowhere in the documentation where we will say: You can run all OpenERP
versions with Python 2.5.

If there is a regression, it's in your own SaaS service, that failed to
properly adapt to 6.0, even if you only noticed it now, with the
(not-released-yet) 6.0.3. OpenERP is not released as a DIY SaaS package,
so if you want to run it as such, do your homework, please.
End of story.

PS: You could use hardlinks for the common part of the web client source
(e.g. "cp -al"), making them immutable by the users, and let them upload
new web addons normally. You could save almost 100% of the disk space.
DISCLAIMER: It's not a documented feature. This advice is distributed in
the hope that it will be useful, but WITHOUT ANY WARRANTY; without even
the implied warranty of FITNESS FOR A PARTICULAR PURPOSE.

[Dominique Chabord (dominique-chabord)]

Le 01/07/2011 14:01, Olivier Dony (OpenERP) a écrit :

> If there is a regression, it's in your own SaaS service, that failed to
> properly adapt to 6.0, even if you only noticed it now, with the
> (not-released-yet) 6.0.3.

Do you mean this behaviour could have been seen since 6.0, and by chance it only happens now ?
It would explain our death dialog since I thought it was a change between 6.0.2 and 6.0.3, and you mean it's not.

> PS: You could use hardlinks for the common part of the web client source

thank you for the advice. I won't ask for after-sale service ;-)
because I chose a different solution.

[Olivier Dony (Odoo) (odo-openerp)]

On 07/02/2011 01:22 AM, Dominique Chabord wrote:
> Do you mean this behaviour could have been seen since 6.0, and by
> chance it only happens now ?

Yes, "web addons" were one of the new features in v6.0, and were shown
at Community Days 2010 and other presentations/webinars.

There are only a few addons that include web addons so far, so that can
easily explain why you did not experience many errors due to version
mismatch (yet).