Re: silva-2.2: comments

Hi Marc,

> > I don't believe kupu, or any other type of content object for that
> > matter, was
> > ever designed to lock the object being edited.  This seems like a
> > glaring
> > omission -- an oversight that should be fixed.  I'm left wondering
> > how this
> > should be fixed.  There are a few options:
> >
> > 1) expand the locking mechanism on documents only, such that when
> > kupu is
> > loaded the document is also locked.  Ensure the lock is removed
> > whenever the
> > document is published.
> > 2) expand the locking mechanism to all versioned content object's
> > edit tab
> > 3) expand the locking mechanism to all object's edit tab
> > And, in addition to the edit tab decision above:
> > A) expand locking mechanism for any tab which allow changing of
> > content.  This
> > would include (only?) the properties tab.
> >
> > Thoughts?
>
> of course i would like to have a locking mechanism for every versioned
> content;-) what about the publish tab? shouldn't it be locked as well
> when somebody is editing a document? locking becomes more important in
> larger sites and when multiple people have editing rights to the same
> documents.

I'd like to hear some more discussion on this issue of locking.  Where in 
Silva would it be appropriate?  
Should the edit tab of all content and versionedcontent objects be locked upon 
visiting?  Does anyone have experience with other cms's that have broader 
object locking support, and how did it work?
>
> Sylvain talked about zc.relationship. could this product be used to
> not only store the id and path of an object but also the status/
> revision of a document and if it's locked by whom? this would also
> allow to add some nice features to the smi. e.g.: imagine logging into
> silva and you see a list of objects that are currently in revision
> "draft" and where you are the last author. this list would be like
> bookmarks and would allow you to jump to your work without the need to
> navigate through the smi (which, in my opinion, is still not optimal).
> this could be implemented like an rss feed where the user can
> configure the filter. please, can i have a "silva code source" which
> would allow me to expand the smi itself?

Heh, this is not a bad idea.  I think a "dashboard" view of Silva is in order.  
It seems to be the way most web applications are moving nowdays.  Using the 
catalog (not zc.relationship) Bethel has added an indexes for the last 
author's userid and also the locally defined users (users with roles 
associated locally on that object).  So, given the catalog is kept up to 
date, it is now possible to pull information like:
1) where a person is assigned permissions (useful for access auditing / 
permission removal)
2) a "show me where I have access" "dashboard"

These use the information Silva currently maintains, which in terms of 
authorship is only the last author.  I'll put this one on my list of 
blueprints to add to launchpad.  

> regards,
> marc
>
> p.s.: infrae should open up a forum (using SilvaForum with openid, of
> course) for discussing future enhancements of silva. i have still an
> idea or two;-)

In the absence of a forum for silva enhancements, please send them here!

regards,
Andy