[Zope-CMF] List of subject/metadata sets?

[Meilicke, Scott]

That's how I was planning on doing it, but haven't gotten that far.  

What I didn't think of was the private/public thing.  What I want is for
everything to be public instantly for all members of the workgroup folder,
so in the interests of speed (I know very little python), instead of doing
it the 'right way', I was just going to give everyone 'reviewer' privs
within that workgroup folder - or something like that.  What I haven't tried
yet is to see if an object created in a workgroup folder that is still
private can be viewable by others that also have permissions in the
workgroup folder.  In effect, private but viewable by the group, but not
viewable by the rest of the company until published (this is an intranet
project).

-Scott

-----Original Message-----
From: Shane Hathaway [mailto:shane@digicool.com]
Sent: Thursday, June 14, 2001 10:36 AM
To: Meilicke, Scott
Cc: zope-cmf@zope.org
Subject: Re: [Zope-CMF] List of subject/metadata sets?


"Meilicke, Scott" wrote:
> The default CMF as I perceive it is geared around one person owning a
chuck
> of something, and not so much a team effort for that chunk.  For example,
if
> I publish a short manual on how to do something, no one else can later
> modify/update the manual except for me.

I think we're much closer to workgroup functionality than we used to be.

On the security tab of your portal root, create a new role.  Call it
"Workgroup Member".  Give the Workgroup Member role the "Add portal
content" and "Modify portal content" permission.

Now, don't give your users the "Workgroup Member" role globally.  That
would be pointless. :-)  Instead, in each of your workgroup folders
assign local roles to individual users.  You can find local roles
through a link on the security tab of all folders.

Now here's the cutting edge part: I think you'll need DCWorkflow (or
your own workflow) to make this work.  You'll need to be able to assign
the "Workgroup Member" role the "View" permission when objects are in
the "private" state, or you'll need to use the "visible" state instead
(which is probably better).

The thing I perceive to be missing is the fact that assigning local
roles is tedious for large numbers of users and we don't have a
mechanism yet for managing users through the portal UI.  But you can
work around this.

Shane