Jim Baack wrote:
> ----- "Rob Miller" <robm@...> wrote:
> 
>> Rob Miller wrote:
>>> Jim Baack wrote:
>>>> Thanks, Rob.
>>>>
>>>> I simplified the test case a little and used the remember type 
>>>> directly. Same problem.
>>>>
>>>> The debug shows that the the new membrane_tool catalog contains
>> both 
>>>> the original and new members. Perhaps the catalog needs to be
>> cleared 
>>>> as it's cloned.
>>>>
>>>> Clearly, we can tell which of the two objects is the correct one by
>>>> comparing to the tool itself (last line). Probably not the ideal
>> fix.
>>>> Any thoughts? Thanks.
>>> not yet... i'll try to reproduce myself, see if i can't figure
>> something 
>>> out.  hopefully i'll be able to get to this later today.
>> okay, i've made some progress here.  first, i changed membrane so that
>> it 
>> won't barf on the pathological catalog state that importing or pasting
>> a Plone 
>> site produces.  you can see what i did in r67772 in the collective...
>> i was 
>> going to link to the changeset on dev.plone.org, but it's not
>> responding ATM.
>>
>> there was still a problem w/ copy/paste, however.  the member objects
>> were 
>> trying to perform schema validation before the newly pasted site had 
>> completely wired up the portal_skins acquisition.  this was failing,
>> b/c AT's 
>> validate_vocabulary method needs access to the 'unicodeEncode' skin
>> script.  i 
>> added a unicodeEncode method to remember's member implementation that
>> works 
>> around this issue.  you can see this in r67773 in the collective.
>>
>> now i can both copy/paste and export/import a remember-based Plone
>> site w/ a 
>> single member, whereas before i couldn't.  things still seem a bit
>> whack, 
>> though..  in a pasted site, the front-page comes up as 'private' for
>> me, when 
>> it's not private on the source site.  i'm guessing that content is
>> being set 
>> back to the default workflow state instead of that information being
>> carried 
>> across like it's supposed to.  if this is the case, then it's likely
>> to impact 
>> the member objects as well.
>>
>> this doesn't seem like a membrane or remember issue, though, so for
>> now i'm 
>> gonna consider this resolved.  hope it works out for you!
>>
>> -r
> 
> Thanks, Rob. I'll pull it down and check it out. I had noticed that when removing the assert for a temporary workaround, the resulting copied site would have both old and new entries for each member in membrane_tool - the uncatalog fix you put it in should take care of that too.

yes, although it's still a bit wonky.  when you do a copy/paste, the assertion 
gets hit during the paste, so all of the duplicates in the catalog will be 
purged.  this will make the paste take longer, however.

when you do an export/import, the assertion doesn't seem to get hit at import 
time, and you WILL end up w/ duplicates all over the catalog.  but when you 
log in as a user for the first time, it will discover the problematic entry 
and will delete it.  having duplicate entries is a pathological state, 
however; i'd strongly recommend doing a full membrane_tool reindex after the 
import to clear things up completely.

and while you're at it, you probably want to do the same for the 
portal_catalog... it looks like there are duplicates for each item in there, 
as well.  i haven't checked the reference_catalog or uid_catalog, but i'd 
guess they suffer from the same problem.

> I saw the unicodeEncode error (and several others not related to membrane/remember) on copy/paste so have moved to export/import instead which seems to have none of these issues and works fine for me now.

yup, that matches what i've seen.

-r