Pardon the DocBkXML markup below, but I tried to document the current
discussion about what reviewing should look like. Lemme know where I
got it wrong.
<para><emphasis>Reviewing</emphasis>. By default, when a
member authors a piece of content, the content isn't part of
the "public site". When a member requests that a piece of
content get reviewed and the content is approved, it
becomes part of the "public site".</para>
<para>The PTK includes extra roles to help this model.
First, Managers can turn Members into Contributors, meaning
their content doesn't require review. Next, Reviewers
receive email notifications and can approve content that
needs reviewing.</para>
<para>The goals of reviewing are straightforward. First,
Members with insufficient privileges should have their new
content reviewed before it is <em>visible</em>. In this
case, visible means the URL to the content should not reveal
the content, the content should not show up in searches or
topics, and the content should not be syndicated.</para>
<para>However, there is more to the policy than this.
First, different Members might have different authority.
For instance, by default the content managed by Contributors
needs no review. Next, the decision about whether an object
is visible is different for each role. That is, a Manager
should be able to view or search for anything. Most sites
will also want to make reviewing extend to edits and even
deletes as well as additions of content.</para>
<para>Additionally, content can move between a reviewed
state and an unreviewed state. In many cases one Reviewer
might decide to override another's decision. When many
Reviewers are involved, they need to efficiently get a list
of the things in the queue. As Reviewers perform actions on
content, these reviewing actions need to be recorded,
perhaps including comments about the action.</para>
<para>The PTK architecture accomplishes this set of goals
with a combination of reviewing metadata, connections to the
standard Zope permissions machinery, and metadata in the
SiteIndex, which is the default ZCatalog for the
portal.</para>
Note to Mike: Jim says that keyword index will be needed in the catalog
to have a list of values for permitted roles, rather than a field index
which can only have one value.
--Paul
discussion about what reviewing should look like. Lemme know where I
got it wrong.
<para><emphasis>Reviewing</emphasis>. By default, when a
member authors a piece of content, the content isn't part of
the "public site". When a member requests that a piece of
content get reviewed and the content is approved, it
becomes part of the "public site".</para>
<para>The PTK includes extra roles to help this model.
First, Managers can turn Members into Contributors, meaning
their content doesn't require review. Next, Reviewers
receive email notifications and can approve content that
needs reviewing.</para>
<para>The goals of reviewing are straightforward. First,
Members with insufficient privileges should have their new
content reviewed before it is <em>visible</em>. In this
case, visible means the URL to the content should not reveal
the content, the content should not show up in searches or
topics, and the content should not be syndicated.</para>
<para>However, there is more to the policy than this.
First, different Members might have different authority.
For instance, by default the content managed by Contributors
needs no review. Next, the decision about whether an object
is visible is different for each role. That is, a Manager
should be able to view or search for anything. Most sites
will also want to make reviewing extend to edits and even
deletes as well as additions of content.</para>
<para>Additionally, content can move between a reviewed
state and an unreviewed state. In many cases one Reviewer
might decide to override another's decision. When many
Reviewers are involved, they need to efficiently get a list
of the things in the queue. As Reviewers perform actions on
content, these reviewing actions need to be recorded,
perhaps including comments about the action.</para>
<para>The PTK architecture accomplishes this set of goals
with a combination of reviewing metadata, connections to the
standard Zope permissions machinery, and metadata in the
SiteIndex, which is the default ZCatalog for the
portal.</para>
Note to Mike: Jim says that keyword index will be needed in the catalog
to have a list of values for permitted roles, rather than a field index
which can only have one value.
--Paul