FYI -

I've run into similar problems with the member_approval_workflow.  Any
workflow state for a member object that does not allow Anonymous users
view rights (at a minimum) causes problems similar to this during
registration.  I had it working at one point by calling an external
method workflow script that called a custom function to handle the
transition.  Of course I lost the code and it was several weeks ago so I
don't recall all of the details.  

If I remember correctly, the solution/hack I came up with involved using
the Zope Security Manager to gain temporary rights that were lacking by
the Anonymous user and then firing the transition.  It worked well and
the member object was created.  The only glitch I hadn't ironed out had
to do with the landing page that informs the user they had been
registered, etc.  It attempts to look at the member object for some
piece of data and of course redirected to a login page since the
Anonymous user didn't have View access to the new member object.

If I get time to re-visit this issue before anyone else, I'll post my
progress both here and to the tracker.

Mick


> -----Original Message-----
> From: Rob Miller [mailto:robm@...]
> Sent: Friday, December 01, 2006 5:46 PM
> To: remember@...
> Subject: Re: [Remember Mailing List] Problems with private profiles
> 
> Rob Miller wrote:
> > James Page wrote:
> >> Rob,
> >>
> >> Hi thanks for your response. I will create a new workflow for the
> >> project. Thank you for that tip.
> >>
> >> The state after filling in the registration form is that I get a
> >> "Please log in" screen. I can not see the new user in
> >> portal_memberdata. I can switch back the end state to 'Public'.
Then
> >> successfully create a new user using the same user name. So it does
> >> not look like the user is been created when the workflow is end
state
> >> is set to private.
> >>
> >> Creating a user from the open, and then setting his profile private
as
> >> admin works.
> >
> > okay, this is more helpful.  it definitely sounds like a bug, but
> > unfortunately i won't be able to look at it until monday at the
> > earliest.  it would help if you could enter it in the issue tracker:
> >
> > http://plone.org/products/remember/issues
> >
> > thanks!
> 
> it just occurred to me that you might try the following as a
workaround:
> 
> - in your custom workflow, create another state ('transitional',
maybe?)
> that
> is in an exact replica of 'public' as far as permissions go.  then you
can
> create a new transition ('autoprivate') that is an automatic
transition
> with
> no guards that has 'private' as destination state.  add this as the
only
> transition for your 'transitional' state, then make 'transitional' the
> destination state for 'auto_register'.
> 
> you shouldn't have to do this, but it's easy to try and might work for
> now.
> then again it might not.  in any event, it would still be very helpful
if
> you
> could open a ticket.
> 
> cheers,
> 
> -r
> 
> --
> To unsubscribe send an email with subject unsubscribe to
> remember@....
> Please contact robm@... for questions.