okay, we've got this problem fixed up, all tests are passing in both membrane 
and remember again...

Andrew Burkhalter wrote:
> I sent the following information to Rob yesterday.  Should have sent it 
> to the list, but it was relevant to a conversation we had during the sprint.
> 
>     Here's what I'm doing ...
> 
>     When I add a set_trace() to the end of the addMember() method within
>     the base layers setup, I get the following proof of password on the
>     member "portal_member":
> 
>      > /usr/local/zope/sprint/remember
>     -instance/Products/remember/tests/base.py(87)addMember()
>     -> return mem
>     (Pdb) mem.getEmail()
>     'noreply@... <mailto:noreply@...>'
>     (Pdb) mem.getPassword ()
>     'hmac_sha:0ebb57dd8fc590bbcf976b028e873fe804b9df60'
> 
> 
>     Later on in the process, when I add a set_trace() into the
>     test_deleteMembers() method of TestMembershipTool():
> 
>     (Pdb) guy = self.mtool.getMemberById('portal_member')
>     (Pdb) guy.getPassword()
>     'hmac_sha:0ebb57dd8fc590bbcf976b028e873fe804b9df60'
> 
> 
>     Okay, still a password.  When you dig into the innards of PAS, you
>     get to the following:
> 
>      >
>     /usr/local/zope/sprint/remember-instance/Products/PluggableAuthService/plugins/ZODBUserManager.py(303)removeUser()
>     -> def removeUser( self, user_id ):
>     (Pdb) s
>      >
>     /usr/local/zope/sprint/remember-instance/Products/PluggableAuthService/plugins/ZODBUserManager.py(305)removeUser()
> 
>     -> if self._user_passwords.get( user_id ) is None:
>     (Pdb) print user_id
>     portal_member
>     (Pdb) self._user_passwords.get( user_id )
> 
> 
>     None!  WTF!?!  Maybe I'm reading too much into the _user_passwords
>     attribute.  self._user_passwords is some BTree object, which I don't
>     really have too much experience interacting with unfortunately, but
>     "new_member" returns a non-None value avoiding the raised KeyError. 
>     "portal_member" returns None and halts there. 

the ZODBUserManager is a user manager that stores the user info directly 
within itself.  the _user_passwords attribute is a BTree with the keys as the 
user ids, the values as the user passwords.  the thing to note is that ONLY 
users that are stored in the ZODBUserManager plug-in should be in the 
_user_passwords BTree; all membrane-based users (including all remember users) 
should NOT be stored in there at all.

turns out there were 2 separate bugs.  one was in membrane's IUserAdder 
implementation; it didn't return True, which tells PAS that the user was 
created and not to continue.  this is why new_member was returning a non-None 
value, because new_member had been created in BOTH plug-ins... which is bad.

the other bug is that PlonePAS's monkey patch of PAS's _doDelUser method 
should have been using a try: except: to not barf on any of the 
_SWALLOWABLE_PLUGIN_EXCEPTIONS that PAS defines.  this has been added, so now 
BOTH new_member AND portal_member are raising the KeyError, but the _doDelUser 
method is catching this exception and thus doesn't raise any errors.

>     To the best of my understanding, the member created within
>     test_deleteMembers of the TestMembershipTool class with the
>     following syntax:
> 
>             self.mtool = self.portal.portal_membership
>             self.mtool.addMember ('new_member', 'secret', ('Member',),
>     tuple)
> 
>     is perhaps wrapped around the user object and thus is similar enough
>     to what the ZODBUserManager expects to interact with, but ultimately
>     defers deletion to membrane's implementation of IUserManagement. 
> 
>     By contrast, "portal_member", which is created in base.py is some
>     more limited object for some reason or another.  I don't have the
>     experience or context to understand this at this point, but a simple
>     __dict__ on each of these member objects turns up quite a few
>     differences.
> 
>     The obvious solution is just to move membrane_users above
>     source_users within the IUserManagement plugin via a setuphandler. 
>     But that feels kind of like cheating

even with membrane_users above source_users, we were having a problem, b/c 
adding a user was causing the user to be added in two locations, due to us not 
returning a True value.  this is fixed now in SVN, you'll need to update 
membrane, remember, and PlonePAS to get all of the pertinent fixes.

now we can move on to getting the searching dialed in.... death to 
portal_membership!

-r