-
----- "Rob Miller" <robm@...> wrote: > Jim Baack wrote: > > When I attempt to copy/paste or import a Plone site where I've > created a single member of a remember-derived type I get the following > assertion error (relevant code also included below). When I change the > offending line > > assert len(members) == 1 > > to > > assert len(members) >= 1 > > reflecting the possibility of more than one result in the query, > everything works fine and the cloned member works fine, retains proper > ownership, etc. > > > > Clearly, this isn't a real fix. Any ideas on why this happens and a > proper way to deal with it. Thanks. > > i'm not exactly sure what's going on. the assertion seems valid; > there should > only ever be one user auth provider for a specific login id. this has > to be > the case, otherwise the system won't know which one to use when you > try to login. > > what i don't know is why you're getting more than one result back from > the > query. maybe there's something unusual about the state of the catalog > during > the paste that is causing the problem. > > i'll have to try to reproduce... if you want to dig deeper, i'd > recommend > putting a break point right where the failure is and examining the > query > results, so you can see exactly what the extra result might be. > > -r > 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. Jim ---------------------------------------------- (Pdb) print len(members) 2 (Pdb) print members[0].getObject().absolute_url() http://localhost:8380/test/copy_of_plone01/portal_memberdata/member1 (Pdb) print members[1].getObject().absolute_url() http://localhost:8380/test/plone01/portal_memberdata/member1 (Pdb) print self.absolute_url() http://localhost:8380/test/copy_of_plone01/membrane_tool (Pdb) > > > > > Jim Baack > > > > ------------------------------------------------------- > > > > > > Traceback (innermost last): > > > > * Module ZPublisher.Publish, line 119, in publish > > * Module ZPublisher.mapply, line 88, in mapply > > * Module ZPublisher.Publish, line 42, in call_object > > * Module OFS.ObjectManager, line 609, in manage_importObject > > * Module OFS.ObjectManager, line 631, in _importObjectFromFile > > * Module OFS.ObjectManager, line 347, in _setObject > > * Module zope.event, line 23, in notify > > * Module zope.component.event, line 26, in dispatch > > * Module zope.component._api, line 130, in subscribers > > * Module zope.component.registry, line 290, in subscribers > > * Module zope.interface.adapter, line 535, in subscribers > > * Module zope.component.event, line 33, in objectEventNotify > > * Module zope.component._api, line 130, in subscribers > > * Module zope.component.registry, line 290, in subscribers > > * Module zope.interface.adapter, line 535, in subscribers > > * Module OFS.subscribers, line 119, in dispatchObjectMovedEvent > > * Module zope.app.container.contained, line 182, in > dispatchToSublocations > > * Module zope.component._api, line 130, in subscribers > > * Module zope.component.registry, line 290, in subscribers > > * Module zope.interface.adapter, line 535, in subscribers > > * Module OFS.subscribers, line 119, in dispatchObjectMovedEvent > > * Module zope.app.container.contained, line 182, in > dispatchToSublocations > > * Module zope.component._api, line 130, in subscribers > > * Module zope.component.registry, line 290, in subscribers > > * Module zope.interface.adapter, line 535, in subscribers > > * Module OFS.subscribers, line 119, in dispatchObjectMovedEvent > > * Module zope.app.container.contained, line 182, in > dispatchToSublocations > > * Module zope.component._api, line 130, in subscribers > > * Module zope.component.registry, line 290, in subscribers > > * Module zope.interface.adapter, line 535, in subscribers > > * Module Products.remember.utils, line 103, in fixOwnership > > * Module Products.remember.content.member, line 115, in > fixOwnership > > * Module Products.remember.content.member, line 131, in getUser > > * Module Products.PluggableAuthService.PluggableAuthService, > line 223, in getUserById > > * Module Products.PluggableAuthService.PluggableAuthService, > line 730, in _findUser > > * Module Products.membrane.plugins.propertymanager, line 89, in > getPropertiesForUser > > * Module Products.membrane.tools.membrane, line 228, in > getUserAuthProvider > > > > AssertionError > > > > > > -------------------------------------------------------------- > > > > def getUserAuthProvider(self, login): > > """ > > Return the unique object that is the authentication > provider > > for the provided login. > > """ > > if not login: # could be either '' or None > > return None > > uSR = self.unrestrictedSearchResults > > idxname = 'getUserName' > > if self.case_sensitive_auth and \ > > ('exact_getUserName' in self._catalog.indexes): > > idxname = 'exact_getUserName' > > query = {idxname: login, > > 'object_implements': > IMembraneUserAuth.__identifier__} > > members = uSR(**query) > > > > if not members: > > return None > > > > --> assert len(members) == 1 > > member = members[0]._unrestrictedGetObject() > > return member > > > > > > > > -- > > Archive: > http://www.openplans.org/projects/remember/lists/remember/archive/2008/07/1215038176436 > > To unsubscribe send an email with subject "unsubscribe" to > remember@.... Please contact > remember-manager@... for questions. > > > > > > -- > Archive: > http://www.openplans.org/projects/remember/lists/remember/archive/2008/07/1215039422740 > To unsubscribe send an email with subject "unsubscribe" to > remember@.... Please contact > remember-manager@... for questions.
- Thread Outline:
-
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. -r > > Jim > > ---------------------------------------------- > > (Pdb) print len(members) > 2 > (Pdb) print members[0].getObject().absolute_url() > http://localhost:8380/test/copy_of_plone01/portal_memberdata/member1 > (Pdb) print members[1].getObject().absolute_url() > http://localhost:8380/test/plone01/portal_memberdata/member1 > > (Pdb) print self.absolute_url() > http://localhost:8380/test/copy_of_plone01/membrane_tool > (Pdb) > > > >>> Jim Baack >>> >>> ------------------------------------------------------- >>> >>> >>> Traceback (innermost last): >>> >>> * Module ZPublisher.Publish, line 119, in publish >>> * Module ZPublisher.mapply, line 88, in mapply >>> * Module ZPublisher.Publish, line 42, in call_object >>> * Module OFS.ObjectManager, line 609, in manage_importObject >>> * Module OFS.ObjectManager, line 631, in _importObjectFromFile >>> * Module OFS.ObjectManager, line 347, in _setObject >>> * Module zope.event, line 23, in notify >>> * Module zope.component.event, line 26, in dispatch >>> * Module zope.component._api, line 130, in subscribers >>> * Module zope.component.registry, line 290, in subscribers >>> * Module zope.interface.adapter, line 535, in subscribers >>> * Module zope.component.event, line 33, in objectEventNotify >>> * Module zope.component._api, line 130, in subscribers >>> * Module zope.component.registry, line 290, in subscribers >>> * Module zope.interface.adapter, line 535, in subscribers >>> * Module OFS.subscribers, line 119, in dispatchObjectMovedEvent >>> * Module zope.app.container.contained, line 182, in >> dispatchToSublocations >>> * Module zope.component._api, line 130, in subscribers >>> * Module zope.component.registry, line 290, in subscribers >>> * Module zope.interface.adapter, line 535, in subscribers >>> * Module OFS.subscribers, line 119, in dispatchObjectMovedEvent >>> * Module zope.app.container.contained, line 182, in >> dispatchToSublocations >>> * Module zope.component._api, line 130, in subscribers >>> * Module zope.component.registry, line 290, in subscribers >>> * Module zope.interface.adapter, line 535, in subscribers >>> * Module OFS.subscribers, line 119, in dispatchObjectMovedEvent >>> * Module zope.app.container.contained, line 182, in >> dispatchToSublocations >>> * Module zope.component._api, line 130, in subscribers >>> * Module zope.component.registry, line 290, in subscribers >>> * Module zope.interface.adapter, line 535, in subscribers >>> * Module Products.remember.utils, line 103, in fixOwnership >>> * Module Products.remember.content.member, line 115, in >> fixOwnership >>> * Module Products.remember.content.member, line 131, in getUser >>> * Module Products.PluggableAuthService.PluggableAuthService, >> line 223, in getUserById >>> * Module Products.PluggableAuthService.PluggableAuthService, >> line 730, in _findUser >>> * Module Products.membrane.plugins.propertymanager, line 89, in >> getPropertiesForUser >>> * Module Products.membrane.tools.membrane, line 228, in >> getUserAuthProvider >>> AssertionError >>> >>> >>> -------------------------------------------------------------- >>> >>> def getUserAuthProvider(self, login): >>> """ >>> Return the unique object that is the authentication >> provider >>> for the provided login. >>> """ >>> if not login: # could be either '' or None >>> return None >>> uSR = self.unrestrictedSearchResults >>> idxname = 'getUserName' >>> if self.case_sensitive_auth and \ >>> ('exact_getUserName' in self._catalog.indexes): >>> idxname = 'exact_getUserName' >>> query = {idxname: login, >>> 'object_implements': >> IMembraneUserAuth.__identifier__} >>> members = uSR(**query) >>> >>> if not members: >>> return None >>> >>> --> assert len(members) == 1 >>> member = members[0]._unrestrictedGetObject() >>> return member >>> >>> >>> >>> -- >>> Archive: >> http://www.openplans.org/projects/remember/lists/remember/archive/2008/07/1215038176436 >>> To unsubscribe send an email with subject "unsubscribe" to >> remember@.... Please contact >> remember-manager@... for questions. >> >> >> -- >> Archive: >> http://www.openplans.org/projects/remember/lists/remember/archive/2008/07/1215039422740 >> To unsubscribe send an email with subject "unsubscribe" to >> remember@.... Please contact >> remember-manager@... for questions.-
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
-