[6.02] error opening crm categories

Hello Dr. Ferdinand,

I have checked your issue with latest updated code but did not face this traceback.
Would you please provide me reproducible steps.

Thanks.

adding debug output to name_get of crm_case_section()
/6.0/crm/crm.py

        reads = self.read(cr, uid, ids, ['name', 'parent_id'], context)
        import sys
        print >> sys.stderr, 'crm reads', reads
        for record in reads:
            print >> sys.stderr, 'crm record', record
            name = record['name']
            print >> sys.stderr, 'crm name', name
            if record['parent_id']:

crm reads {'parent_id': False, 'name': u'Sales Department', 'id': 1}
crm record parent_id
[2011-04-07 09:19:35,300][test602] ERROR:web-services:Uncaught exception
Traceback (most recent call last):
  File "/home/terp/OpenERP/trunk/openobject-server/6.0/bin/osv/osv.py", line 122, in wrapper
    return f(self, dbname, *args, **kwargs)
  File "/home/terp/OpenERP/trunk/openobject-server/6.0/bin/osv/osv.py", line 176, in execute
    res = self.execute_cr(cr, uid, obj, method, *args, **kw)
  File "/home/terp/OpenERP/trunk/openobject-server/6.0/bin/osv/osv.py", line 167, in execute_cr
    return getattr(object, method)(cr, uid, *args, **kw)
  File "/home/terp/OpenERP/trunk/openobject-addons/6.0/crm/crm.py", line 671, in name_get
    name = record['name']
TypeError: string indices must be integers, not str

addons 6.0 rev 4408

Hello Dr. Ferdinand,

You did check this with very old revision of 6.0 stable addons.
I have checked this with following revision of server and addons:

server: 3395 launchpad_translations_on_behalf_of_openerp-20110407055442-dotyi6bfnw93g9da
Addons: 4513 <email address hidden>
GTK:1831 <email address hidden>
Web:4569 launchpad_translations_on_behalf_of_openerp-20110407055431-2h708bsgu2pz556p

So Would you please check this again with latest updated code.

Thanks.

sorry the rev was wrong
I am on
server 3388
addons 4513 (http://bazaar.launchpad.net/~openerp/openobject-addons/6.0/)
web 4568

Hello DR Ferdinand,

I have checked your issue in stable 6.0.2 with GTK and web-client both.
But I am not faced any type of the traceback and all are working as expected.

So would you please provide your copy of dump database then we will
check what is the problem you have faced.

Thanks in advance.

basic demo database
it happens in all my database

Hello DR Ferdinand,

Thanks for your reply!

I have restore your database at my end and I am checked your issue in your own database but I am still not get any traceback or error.

I have attached a video for your reference So would you please check it and notify us where you faced the problem.

Thanks again.

I followed the example and I still get the error
please could you chek if the crm.py are the same.

parent branch: http://bazaar.launchpad.net/~openerp/openobject-addons/6.0/
revision-id: launchpad_translations_on_behalf_of_openerp-20110408061309-vdc4fos4jns3upnx
date: 2011-04-08 06:13:09 +0000
build-date: 2011-04-08 12:17:58 +0200
revno: 4514
branch-nick: 6.0

Hello Dr Ferdinand,

I have checked the both crm.py are same.
And I have checked the whole name_get method which is run perfectly I think it may be your end side problem.

For now I am closing this issue If you still faced the same problem then you can reopen this.

Thanks for understanding!

Sorry to bother you with this again

v6 and Python 2.6.5 (r265:79063, Oct 28 2010, 20:56:23)
[GCC 4.5.0 20100604 [gcc-4_5-branch revision 160292]]
returns a dict
crm reads {'parent_id': False, 'name': u'Sales Department', 'id': 1}

v5 and Python 2.5.2 (r252:60911, Dec 1 2008, 18:10:01)
[GCC 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036]]
returns a list with the dict
crm reads [{'parent_id': False, 'name': u'Helpdesk and Support', 'id': 1}]

the attached patch solves the problem
revisions 6.0 series
server 3397
addons 4514

may be a strange behaviour of read method ?

Hello DR Ferdinand,

The patch seems good but I am not able to produce the trace-back at my end because for every time there is passed a list in read method so no need to check this kind.

In reads passed list of dict like [{'parent_id': False, 'name': u'Sales Department', 'id': 1}]
So the record is dictionary like {'parent_id': False, 'name': u'Sales Department', 'id': 1} and in line number 677 of crm.py if there a parent in record then it will go a head.

That's why there is no need to check
 if isinstance(reads, dict): this type which you have suggested in patch.

And again said this is not a bug If you still faced it then would you please attached a video with whole steps and traceback.

Thanks in advance.

Hmm,
It's not worth to make a video showing me clicking on Sales/config/helpdesk/categories ...
aynd there is no more server output than in the bug message.

the question is, why does
        reads = self.read(cr, uid, ids, ['name', 'parent_id'], context)
returns
{'parent_id': False, 'name': u'Sales Department', 'id': 1}
instead of
[{'parent_id': False, 'name': u'Sales Department', 'id': 1}]

and why only in my installation ?

could there be another read method ..
is there a possibility to find out which read form which module is used ?

Hello DR Ferdinand,

The traceback is not generated directly if we used a python script for executing a name_get method then we will faced the problem.

And your patch works fine.

Thanks for the support!

On Monday 11 April 2011, you wrote:
> Hmm,
> It's not worth to make a video showing me clicking on
> Sales/config/helpdesk/categories ... aynd there is no more server output
> than in the bug message.
>
> the question is, why does
> reads = self.read(cr, uid, ids, ['name', 'parent_id'], context)
> returns
> {'parent_id': False, 'name': u'Sales Department', 'id': 1}
> instead of
> [{'parent_id': False, 'name': u'Sales Department', 'id': 1}]
>
> and why only in my installation ?

Well, this is a "dark corner" of the framework:
In the addons code, we meet both cases of
   res1 = obj.read(cr, uid, ids=4, ...)
and
   res2 = obj.read(cr, uid, ids=[1,2,3], ...)
(same with the browse(.., ids=?) one)

The de-facto definition of this function is that if you supply an int/long id,
it returns a single dict result. If you supply anything else[1] (we expect
list/tuple), it returns a list of dicts.
So, res1 = {'id': 4, 'foo': ...}
and res2 = [{'id': 1, 'foo': ...}, ... ]

I know the framework is not very consistent this way. You'd expect the
function to return the same type of results. But the problem is that it's used
so much (and is such a basic fn) that we cannot just change it. It would break
the API in a way that all rest of the code needs to be adapted.

[1] in a twisted way, something that evaluates to an int may result in a list
return. Most probably, however, it will bork because we'd iterate on it.

great to have at least an explanation

but something must have changed between v5 and v6, as the same dataset in v5 works and not in v6.

IMHO we will have a good chance to encounter more problems like this one - especially grave as we could proove that the same database supplied as attachment runs on one installation and not on the other.

Hello Dr,

        We have fix ed the issue and committed to the lp:~openerp-dev/openobject-addons/trunk-bug-747776-jam and proposed for Merging in lp:openobject-addons.
      Thank you for Kind support and pointing the crucial point.