Mailing List Archive

[Zope-PTK] providing a read-only interface
Hi out there.

I want to give my users a read-only access to the complete content
of other users unless a variable "private" is set.
People should be able to see the stuph, but when they want to
change something they get a site that asks them to sign up.
In order to do that I added a print_static method to all my
ZClasses that are addable to the portal. Then I changed the
automatic on join created index_html method so that it prints
out the objects in read-only mode.

Now if people go to:

www.example.com/myportal/Members/XY
they should get the read only site

and when they are logged in they can access their portal
normally with /portal_contents

my question:

What permissions do I have to set/change that every unknown user
can access the portal contents in read-only mode?

TIA

philipp dunkel
** ** ** ** ** ** ** **
pgp public key available
gpg public key available
ICQ# 60149094
Re: [Zope-PTK] providing a read-only interface [ In reply to ]
Sorry for the delay, I had to check in an answer! ;-)

On Sun, 12 Mar 2000, Philipp Dunkel wrote:

> my question:
>
> What permissions do I have to set/change that every unknown user
> can access the portal contents in read-only mode?

It might take us a couple go-rounds before we're both talking about
the same thing. I say this because it sounds to me as though you simply
want unauthenticated users to be able to view portal content, which they
can do 'out of the box'. That is to say, that's how the PTK is configured
by default. The content merely has to be published first.

A Reviewer must first approve content for it to be publicly visible.
The owner of content may ask for a Reviewer to do this by using the
'Publish item' link. (This is the same interface that the Reviewer uses
to approve an item.) This request-approve cycle is called publishing.

Whether or not you are allowed to view an item is determined by,
naturally enough, the 'View' permission. If the Anonymous role has that
permission on the object, they can find it in the catalog and have at
least 'read-only' access. The reviewing machinery manipulates the
permissions on objects as its review_state dictates. If you want to
change who can view an object (who has 'read-only' access to it) for a
particular review_state, this can be done by overriding or extending the
portal's 'review_policy' method (just checked in). Actually, any part of
the object's state can be used to make this decision, but this hook is
only called when the review_state changes.

Hope there is some useful information in this shotgun-blast answer.
If not, I'll be happy 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