Darcy Clark wrote:
> Plone 2.1.4 migrating to Plone 2.5.4
> Zope 2.9.8
> Python 2.4.4
> 
> remember 1.0b1
> membrane 1.0
> contentmigration 1.5a1 svn/unreleased
> 
> I've been trying to migrate a Plone 2.1.4 with a custom CMFMember Member 
> type to Plone 2.5.4. I basically followed the instructions outlined in 
> remember/cmfmember/README.txt. The typical error that I'm getting is 
> triggered by line 75 below in contentmigration/common.py:
> 
> 66    # we have to do it all manually :(
> 67    p = container.manage_addProduct[fti.product]
> 68    m = getattr(p, fti.factory, None)
> 69    if m is None:
> 70        raise ValueError, ('Product factory for %s was invalid' %
> 71                           fti.getId())
> 72
> 73    # construct the object
> 74    m(id, *args, **kw)
> 75    ob = container._getOb( id )
> 
> Basically the new Member is created by line 74; line 75 tries to get the 
> new object, which is where it fails with:
> 
> ".....\Products\contentmigration\common.py", line 75, in 
> _createObjectByType ob = container._getOb( id ) AttributeError: _getOb
> 
> Getting in and debugging I've determined that the new Member instance 
> isn't created in the container (portal.portal_memberdata) but rather in 
> the portal root. Hence container._getOb( id ) fails.

this is quite strange, though... the error you're getting is an 
AttributeError, which implies that 'container' doesn't have the _getOb method. 
  since _getOb is present on pretty much every Zope folderish type, it's an 
indication that container is very much not what we're expecting it to be.

> I sense that something isn't right with the "container" object but 
> typing the following at the PDB prompt returns what appears to be the 
> correct object:
> 
> -> ob = container._getOb( id )
> (Pdb) container
> <MemberDataTool at /vhosts/permaforest/portal_memberdata>

wait a minute.  you've got a MemberDataTool.  with both CMFMember and 
remember, this should be a MemberDataContainer.  the CMFMember -> remember 
migration will only work on a site that has CMFMember installed.  are you sure 
CMFMember is installed in the site that you're migrating?

anyway, this explains why your members are ending up at the portal root... 
portal_memberdata isn't a container at all, so acquisition is kicking in and 
methods are being run on the parent container, i.e. the portal root object.

not sure what's going on, but hopefully this will provide you with some clues.

-r