I have just tried the workaround suggested by Rob and it throws the
same errors.

On 12/4/06, Mick Drevyanko <mick@...> wrote:
>
> 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.
>
> --
> To unsubscribe send an email with subject unsubscribe to remember@....
> Please contact robm@... for questions.
>