[Zope-CMF] Refining the disposition of published-documentrevisions

[seb bacon]

* Chris McDonough <chrism@digicool.com> [010530 10:27]:
> seb bacon wrote:
> > If I understand you correctly, I believe this is what Shane was
> > proposing.  The important point here is that a document 'knows' what
> > its default version is.  Should this follow a simple policy (e.g. The
> > most recent version accessible to the user) or should it be
> > web-configurable (e.g. the most recent version accessible unless
> > you're a Manager, in which case you see the most recent non-public
> > version)?
> 
> Actually, as far as I was thinking of it, I don't think there needs to
> be more than two revisions:  a public revision, and a current revision. 
> When the current revision is public, these are the same.  When the
> current revision has been modified, they are different.  The document
> knows that it should always show the public version unless its being
> edited.

I understand now.  
Certainly that solves the workflow problem as stated by Ken; in fact,
I was going to do a quick hack which does just that in my next
project.  It will just create a copy with a known id
(e.g. originalname_v) and folder views will be hacked to return that
to an authenticated user.  However, if you're going to implement a
less hacky revision system, you might as well cater for the concept of
revisions on a more generic level, since there's obviously a need for
them.  Then the solution to the problem Ken outlines is just a q. of 
workflow implementation.  Furthermore, I think the only tricky bit of
this is the requirements - the implementation Shane suggested wouldn't
be hard to carry out, I think.  Hope.  :)

cheers,

seb