Mailing List Archive

At 17:59 Uhr -0800 22.02.2000, J C Lawrence wrote:
>Given a freshly installed demo portal, attempting to enter
>"Preferences" from the nav bar gets:
>
> Error Type: AttributeError
> Error Value: email
>
<snip Traceback>

This happens because the portal creation wizard does not ask you for
the eMail address of the first portal manager. You need to go to the
management interface and edit this user there.

I told this to Mike and the list among other "findings" but did not
recieve any form of proof up to now :)
Jochen

If you get a chance, please report these problems to the Tracker that's
been setup for keeping track of outstanding issues:

http://www.zope.org/Products/PTK/Tracker/

Thanks!

--Paul

J C Lawrence wrote:
>
> Given a freshly installed demo portal, attempting to enter
> "Preferences" from the nav bar gets:
>
> Error Type: AttributeError
> Error Value: email
>
> <!--
> Traceback (innermost last):
> File /usr/lib/zope/lib/python/ZPublisher/Publish.py, line 214, in publish_module
> File /usr/lib/zope/lib/python/ZPublisher/Publish.py, line 179, in publish
> File /usr/lib/zope/lib/python/Zope/__init__.py, line 202, in zpublisher_exception_hook
> (Object: DemoPortalBase)
> File /usr/lib/zope/lib/python/ZPublisher/Publish.py, line 165, in publish
> File /usr/lib/zope/lib/python/ZPublisher/mapply.py, line 160, in mapply
> (Object: personalize_form)
> File /usr/lib/zope/lib/python/ZPublisher/Publish.py, line 102, in call_object
> (Object: personalize_form)
> File /usr/lib/zope/lib/python/OFS/DTMLMethod.py, line 145, in __call__
> (Object: personalize_form)
> File /usr/lib/zope/lib/python/DocumentTemplate/DT_String.py, line 502, in __call__
> (Object: personalize_form)
> File /usr/lib/zope/lib/python/DocumentTemplate/DT_Var.py, line 278, in render
> (Object: AUTHENTICATED_USER.email)
> File /usr/lib/zope/lib/python/DocumentTemplate/DT_Util.py, line 335, in eval
> (Object: AUTHENTICATED_USER.email)
> (Info: AUTHENTICATED_USER)
> File <string>, line 0, in ?
> File /usr/lib/zope/lib/python/DocumentTemplate/DT_Util.py, line 127, in careful_getattr
> AttributeError: (see above)
>
> -->
>
> --
> J C Lawrence Home: claw@kanga.nu
> ----------(*) Other: coder@kanga.nu
> --=| A man is as sane as he is dangerous to his environment |=--
>
> _______________________________________________
> Zope-PTK maillist - Zope-PTK@zope.org
> http://lists.zope.org/mailman/listinfo/zope-ptk

On Wed, 23 Feb 2000, Jochen Haeberle wrote:

> At 17:59 Uhr -0800 22.02.2000, J C Lawrence wrote:
> >Given a freshly installed demo portal, attempting to enter
> >"Preferences" from the nav bar gets:
> >
> > Error Type: AttributeError
> > Error Value: email

> This happens because the portal creation wizard does not ask you for
> the eMail address of the first portal manager. You need to go to the
> management interface and edit this user there.

I'm having trouble reproducing this. In fact, I'm not certain this is
the problem. I agree that the wizard should ask for the email address
(I've just made the change locally) but I have a feeling that what's
happened is you've tried to use the 'Preferences' option while logged in
as a user from the root acl_users user folder, such as the superuser.
This user obviously won't have the properties that Preferences
sets. You need to log in as a Portal member (such as the manager account
you created in the Portal wizard) for it to work. Can you verify for me
that this isn't (or is) what happened?

I could make the Preferences page check to make sure you're a PTK
member rather than just some Zope user, but there are lots of other places
much the same thing could still happen. Fixing Preferences specifically
would be something of a band-aid. I can't think of a way I could catch
all of them in one place. Suggestions?

Mike.

--
Mike Pelletier email: mike@digicool.com
Mild mannered software developer icq: 7127228
by day, super villain by night. phone: 519-884-2434

On Wed, 23 Feb 2000 09:52:17 -0500 (EST)
geek <geek@geekme.org> wrote:

> On Wed, 23 Feb 2000, Jochen Haeberle wrote:
>> At 17:59 Uhr -0800 22.02.2000, J C Lawrence wrote:

>>> Error Type: AttributeError
>>> Error Value: email

>> This happens because the portal creation wizard does not ask you
>> for the eMail address of the first portal manager. You need to go
>> to the management interface and edit this user there.

> I'm having trouble reproducing this. In fact, I'm not certain
> this is the problem. I agree that the wizard should ask for the
> email address (I've just made the change locally) but I have a
> feeling that what's happened is you've tried to use the
> 'Preferences' option while logged in as a user from the root
> acl_users user folder, such as the superuser.

Bingo! This was the problem. I'd previously set the email address
via the management interface and hadn't noticed that I wasn't logged
in as a local user.

> You need to log in as a Portal member (such as the manager account
> you created in the Portal wizard) for it to work. Can you verify
> for me that this isn't (or is) what happened?

That is what happened.

--
J C Lawrence Home: claw@kanga.nu
----------(*) Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--

geek@geekme.org wrote:
>
> On Wed, 23 Feb 2000, Jochen Haeberle wrote:
>
> > At 17:59 Uhr -0800 22.02.2000, J C Lawrence wrote:
> > >Given a freshly installed demo portal, attempting to enter
> > >"Preferences" from the nav bar gets:
> > >
> > > Error Type: AttributeError
> > > Error Value: email
>
> > This happens because the portal creation wizard does not ask you for
> > the eMail address of the first portal manager. You need to go to the
> > management interface and edit this user there.
>
> I'm having trouble reproducing this. In fact, I'm not certain this is
> the problem. I agree that the wizard should ask for the email address
> (I've just made the change locally) but I have a feeling that what's
> happened is you've tried to use the 'Preferences' option while logged in
> as a user from the root acl_users user folder, such as the superuser.
> This user obviously won't have the properties that Preferences
> sets. You need to log in as a Portal member (such as the manager account
> you created in the Portal wizard) for it to work. Can you verify for me
> that this isn't (or is) what happened?


Data point:
I've seen this under those exact circumstances.

--
In flying I have learned that carelessness and overconfidence are
usually far more dangerous than deliberately accepted risks.
-- Wilbur Wright in a letter to his father, September 1900

At 9:52 Uhr -0500 23.02.2000, geek@geekme.org wrote:
>On Wed, 23 Feb 2000, Jochen Haeberle wrote:
>
> > At 17:59 Uhr -0800 22.02.2000, J C Lawrence wrote:
> > >Given a freshly installed demo portal, attempting to enter
> > >"Preferences" from the nav bar gets:
> > >
> > > Error Type: AttributeError
> > > Error Value: email
>
> > This happens because the portal creation wizard does not ask you for
> > the eMail address of the first portal manager. You need to go to the
> > management interface and edit this user there.
>
> I'm having trouble reproducing this. In fact, I'm not certain this is
>the problem. I agree that the wizard should ask for the email address
>(I've just made the change locally) but I have a feeling that what's
>happened is you've tried to use the 'Preferences' option while logged in
>as a user from the root acl_users user folder, such as the superuser.
>This user obviously won't have the properties that Preferences
>sets. You need to log in as a Portal member (such as the manager account
>you created in the Portal wizard) for it to work. Can you verify for me
>that this isn't (or is) what happened?

You are right, that's the problem. Obviously, after creating a portal
you are logged in as a manager. If these are your first steps with
the portal, you defenitely start playing around. I think the best
would be that the http_authenticated user would have no effect to the
portal authorized users, but as this seems to be a problem, I would
suggest that the wizard-finish page looks different, not like a
functioning portal or at least has an text explaining this situation.

> I could make the Preferences page check to make sure you're a PTK
>member rather than just some Zope user, but there are lots of other places
>much the same thing could still happen. Fixing Preferences specifically
>would be something of a band-aid. I can't think of a way I could catch
>all of them in one place. Suggestions?

Is there no way to separate portal users from Zope users? I guess
this would greatly help to solve the problems and get a better
understanding of what happens for content-manager-type portal admins.

I find it very disturbing at the moment and have problems switching
back and forth portal and management interface the only solution was
to use virtual hosting so the http-authentication is different.

I think it is not very zopic at the moment. the portal should in some
way acquire the users from above, mostly the superuser

Jochen

On Thu, 24 Feb 2000, Jochen Haeberle wrote:

> I think the best would be that the http_authenticated user would have
> no effect to the portal authorized users...

I disagree, I think this would be a Bad Thing, potentially a VERY bad
thing. It would affect both the portal interface and the Zope management
interface. I do agree that the caveats need to be make more visible in
the Wizard's finish page.

> Is there no way to separate portal users from Zope users? I guess
> this would greatly help to solve the problems and get a better
> understanding of what happens for content-manager-type portal admins.

Can you elabotate in the idea of separation?

> I find it very disturbing at the moment and have problems switching
> back and forth portal and management interface the only solution was
> to use virtual hosting so the http-authentication is different.

Not at all-- The account you set up when you create the portal has
full management rights and can use the Zope management interface without
resorting to playing tricks with the hostname. It is more difficult if
you want to manage other portions of your site at the same time, depending
on your browser. IE5 seems to do a better job of not sharing
authentiction information between sessions if the sessions are launched
separately. (That is, don't clone the window with ^N.)

To be honest, I am reluctant to load the PTK up with authentication
hacks to solve a deficiency of some browsers.

> I think it is not very zopic at the moment. the portal should in some
> way acquire the users from above, mostly the superuser

The PTK _is_ acquiring users from above. That's essentially where
this problem comes from-- a non-PTK user is being accquired. I think
I'm not understanding you completely. Feel free to try again.

--
Mike Pelletier email: mike@digicool.com
Mild mannered software developer icq: 7127228
by day, super villain by night. phone: 519-884-2434

At 10:17 Uhr -0500 24.02.2000, Mike Pelletier wrote:
>On Thu, 24 Feb 2000, Jochen Haeberle wrote:
>
> > I think the best would be that the http_authenticated user would have
> > no effect to the portal authorized users...
>
> I disagree, I think this would be a Bad Thing, potentially a VERY bad
>thing. It would affect both the portal interface and the Zope management
>interface. I do agree that the caveats need to be make more visible in
>the Wizard's finish page.

I can't see why that should be a very bad thing. I do see however
that many people on this list have problem with the present situation
and get confused by the user diferences. I guess those problems will
grow very much when PTK is released and claims to be easy enough to
anyone to set up a portal...

I think there already is a big difference between portal users and
Zope users so seperating them totally would be as to go the full way.

> > Is there no way to separate portal users from Zope users? I guess
> > this would greatly help to solve the problems and get a better
> > understanding of what happens for content-manager-type portal admins.
>
> Can you elabotate in the idea of separation?

This would mean that when you enter the portal logged in as a Zope
user you will still be greated as a guest and have to log into the
portal.

> > I find it very disturbing at the moment and have problems switching
> > back and forth portal and management interface the only solution was
> > to use virtual hosting so the http-authentication is different.
>
> Not at all-- The account you set up when you create the portal has
>full management rights and can use the Zope management interface without
>resorting to playing tricks with the hostname. It is more difficult if

I think the portal should be managed only through Wizards, so there
should be no need for content managers to log into Zope aka the
Management Interface. The problem mostly concerns developers and I
guess they can deal with beeing logged in as separate portal and zope
users.

>you want to manage other portions of your site at the same time, depending
>on your browser. IE5 seems to do a better job of not sharing
>authentiction information between sessions if the sessions are launched
>separately. (That is, don't clone the window with ^N.)
>
> To be honest, I am reluctant to load the PTK up with authentication
>hacks to solve a deficiency of some browsers.

This is the way the browsers work today. The solution you suggest
only applies to the Win plattform - the Internet offers far more (and
better:) OSes.

But I can see your point to not overload the PTK!

>
> > I think it is not very zopic at the moment. the portal should in some
> > way acquire the users from above, mostly the superuser
>
> The PTK _is_ acquiring users from above. That's essentially where
>this problem comes from-- a non-PTK user is being accquired. I think
>I'm not understanding you completely. Feel free to try again.

Okay, that's what I meant... PTK acquires user from above which are
not suited for acquisition.

How about a wizard that builds a portal user with the missing
information? This way you could add that information missing from the
user in the portal where need arises. Even easier but perhaps not as
perfect as just adding the missing information would be to recreate
the user entirely.

The PTK could check if a user is a correct portal user or not and act
accordingly.

Jochen

Jochen Haeberle wrote:
>
> At 10:17 Uhr -0500 24.02.2000, Mike Pelletier wrote:
> >On Thu, 24 Feb 2000, Jochen Haeberle wrote:
> >
> > > I think the best would be that the http_authenticated user would have
> > > no effect to the portal authorized users...
> >
> > I disagree, I think this would be a Bad Thing, potentially a VERY bad
> >thing. It would affect both the portal interface and the Zope management
> >interface. I do agree that the caveats need to be make more visible in
> >the Wizard's finish page.
>
> I can't see why that should be a very bad thing. I do see however
> that many people on this list have problem with the present situation
> and get confused by the user diferences. I guess those problems will
> grow very much when PTK is released and claims to be easy enough to
> anyone to set up a portal...

Consider the site that doesn't want to use cookies. If you can't use
basic authorization, you're basically sunk (pun intended).


> I think there already is a big difference between portal users and
> Zope users so seperating them totally would be as to go the full way.

I disagree. I am actually putting a site together that uses both.

> > > Is there no way to separate portal users from Zope users? I guess
> > > this would greatly help to solve the problems and get a better
> > > understanding of what happens for content-manager-type portal admins.
> >
> > Can you elabotate in the idea of separation?
>
> This would mean that when you enter the portal logged in as a Zope
> user you will still be greated as a guest and have to log into the
> portal.

What about sites where the portal is only _part_ of the site, not _the_
site? In those cases, you're lost if you want members of the main site
to be able to be a prt of the sub-site without additional effort on
their part.

> > > I find it very disturbing at the moment and have problems switching
> > > back and forth portal and management interface the only solution was
> > > to use virtual hosting so the http-authentication is different.
> >
> > Not at all-- The account you set up when you create the portal has
> >full management rights and can use the Zope management interface without
> >resorting to playing tricks with the hostname. It is more difficult if
>
> I think the portal should be managed only through Wizards, so there
> should be no need for content managers to log into Zope aka the
> Management Interface. The problem mostly concerns developers and I
> guess they can deal with beeing logged in as separate portal and zope
> users.

Problem with this approach is that then _every_ product for Zope has to
then be converted to Portals and wizards. Something tells me this isn't
going to happen. Wizards are good for adding a specific thing, but bad
for overall layout and design.

> >you want to manage other portions of your site at the same time, depending
> >on your browser. IE5 seems to do a better job of not sharing
> >authentiction information between sessions if the sessions are launched
> >separately. (That is, don't clone the window with ^N.)
> >
> > To be honest, I am reluctant to load the PTK up with authentication
> >hacks to solve a deficiency of some browsers.
>
> This is the way the browsers work today. The solution you suggest
> only applies to the Win plattform - the Internet offers far more (and
> better:) OSes.

Actually, ths is an alternative to another solution (the one I use)
which works for non-windows platforms.


> But I can see your point to not overload the PTK!
>
> >
> > > I think it is not very zopic at the moment. the portal should in some
> > > way acquire the users from above, mostly the superuser
> >
> > The PTK _is_ acquiring users from above. That's essentially where
> >this problem comes from-- a non-PTK user is being accquired. I think
> >I'm not understanding you completely. Feel free to try again.
>
> Okay, that's what I meant... PTK acquires user from above which are
> not suited for acquisition.
>
> How about a wizard that builds a portal user with the missing
> information? This way you could add that information missing from the
> user in the portal where need arises. Even easier but perhaps not as
> perfect as just adding the missing information would be to recreate
> the user entirely.
>
> The PTK could check if a user is a correct portal user or not and act
> accordingly.

IMO, this can be accomplished with the use of roles.



--
In flying I have learned that carelessness and overconfidence are
usually far more dangerous than deliberately accepted risks.
-- Wilbur Wright in a letter to his father, September 1900