Re: [collective-cmfmember] member acquisition context inconsistencies

[Geoff D. <ge...@ge...>]

> is there a reason for the acquisition context to be set like that in 
> wrapUser?  it'd be easy enough to change wrapUser, but there must have 
> been some justification for doing this in the first place.  anyone have 
> any info here?

wrapUser was written the way it was in order to maintain compatibility
with the default CMF portal_memberdata's wrapUser method.  IIRC (and
it's been a very long time since I've looked at that code), wrapUser
produces a member object that has the user object as its aq_parent, then
the acl_users user folder as the aq_parent of that.  I believe the
reason it does so is to make methods on the user object and the user
folder available on the member object.  You're probably stuck with
having to do that.

I'm not sure how acquisition works if you have a different inner and
outer acquisition context.  You might experiment with re-wrapping the
output of wrapUser (e.g. wrapUser().__of__(memberdatafolder)) to see if
you can still acquire from the inner acquisition context.  If you can,
that may be the easiest way to address the issue.  I'm guessing you
probably don't, though.