[Zope-CMF] How to provide both public/private Member areas

Mark Langkau mark.langkau@pbmplus.com
Fri, 01 Jun 2001 11:16:49 -0500


Hi Norbert,

That makes sense. Here's some more detail:

Raw data is provided to us by clients/companies. (That's handled by a
process outside of Zope). We process that data and provide both detailed and
summarized reports back to the client/company. Employees of those companies
really won't be creating or posting content. (I'm leaving that open for
exceptions - always a possibility ;-) They will be viewing these
confidential reports that we create and post. So, we will be creating 99% of
the content and will be automating the posting of these reports to the site.

Most of what I've read about CMF is geared towards the community publishing
content for public viewing. This application is the opposite, where we will
create all content and push it out (so to speak) to individual Members. Sort
of like a My Netscape or My Yahoo where that Member's customized content
page is private to them and not publicly available to other site members.

The open/flexible nature of Zope/CMF/Python tells me that this is possible,
with some local development perhaps. I'm doing this now with perl. This will
be my "learn how to implement CMF" project.

>Maybe I'm simplifying too much, comments from the list?

Simple is always better. I think I'm too close to this project to see the
simple solutions that I'm sure exist. That's why I'm seeking the vast
knowledge of this list (compared to my half-vast knowledge...  um, wait a
minute ;-)

Cheers,
Mark

Norbert Marrale wrote:

> Hi Mark:
>
> Since you can create / assign multiple roles to each user, you might want
> to look into creating two different sets of permissions: based on
> companies/identity, and on the member's publishing authorization
> (member/author/reviewer/etc.)
>
> In each member folder, a private "incoming" folder should be created
> (with a method similar to the CMF Favorites folder), where other
> (properly authorized) members can post, but not view documents.
>
> You can then build a second CMF method which lets members create these
> private documents. Instead of being added to their own folder tree, these
> documents would instead be added to the recipient's folder. Zope stores
> the document's owner, so he/she will be able to view his own documents
> and make modifications if needed; and because of inheritance, documents
> in a particular folder can acquire a set of rights from the folder
> they're stored in (viewable/editable by the recipient).
>
> Maybe I'm simplifying too much, comments from the list?
>
> Norbert
>
> --
> On the Road of Life,
> there are Tourists and there are Travelers.
> I'd rather be Traveling!
>
> Norbert Marrale
> norbert@infocatch.com
>
> -----Original Message-----
> From: Mark Langkau <mlangkau@execpc.com>
> To: zope-cmf@zope.org
> Date: Fri, 01 Jun 2001 08:23:39 -0500
> Subject: [Zope-CMF] How to provide both public/private Member areas
>
> >[..]
> > Specifics: There will be several hundred clients, where a client is
> > actually a company/business. Members of this site will be employees of
> > these clients/businesses. When a Member logs in , they should see info
> > specific to their company (confidential), information specific to that
> > Member (confidential), and some general info of interest to the entire
> > site community (regulations, best practices, site announcements, etc.).
> > A major concern to us is that Members should not be able to
> > accidentally
> > publish or in any way post any of the confidential info to public areas
> > of the site. (I guess following the workflow model would prevent that.
> > Reviewers could reject requests to publish confidential info). Finally,
> > info that Members DO wish to publish should only be viewable by other
> > employees of that same client/business. Those postings should be owned
> > by the client, not the member. In other words, if the employee/Member
> > leaves his business (and maybe joins a competitor which also in on this
> > site), his postings remain with the client, not the Member (because
> > they
> > will be about the client and will contain confidential info).
> > [..]