Re: silva-2.2: comments

On 24. Sep 2009, at 04:52 Uhr, Andy Altepeter wrote:

> 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?

what about the properties tab? i think this should be locked as well,  
e.g. because of the title (and short title) can be edited there as well.

> Does anyone have experience with other cms's that have broader
> object locking support, and how did it work?

i have no such experience.

>>
>> 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)

nice. we use the AccessListing script from here http://www.mat.ethz.ch/silva_cms/scripts 
  for this task.

> 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!

i will do this.

regards,
marc