Etria Lists

Michael Reitsma wrote:
> Hi,
> 
> Would it be possible to use the method described below to allow users to
> publish an WeblogEntry?

Short answer: no.

> Info (for those not already familiar with my setup :-) ):
> In my setup the users can create weblogentrys but not publish them.
> Since i do not want them to be able to delete the weblog i removed the
> delete rights for them on this (folderish) object.

Sorry if I'm being a bit slow here.  Can you just clarify things a bit?

Firstly, is it true to say that having the delete permission on a 
non-folderish object only allows you to delete that object if you also 
have that permission on the containing folderish object?

Secondly, is it true to say that having the delete permission on a 
folderish object is enough to delete that object itself, without having 
the permission on the containing folderish object?

> This also means they can not delete weblog entrys unfortunately.
> This is not preferred but i can live with it, (i don't have a lot of posts)
> However they can also not publish them because that involves calling a
> script after the workflow runs that creates  (a) folder(s) and then moves
> the entry.
> 
> Dan told me the following:
> If the script is in a product on the file system then you need
> a .metadata  file for the script, i.e.
> 
> myscript.py
> myscript.py.metadata
> 
> in the metadata file add a line like
> 
> proxy=Manager
> 
> Dan
> 
> I did some looking and found two files that are used (i think) by the
> workflowscriptcall:
> Workflow_scripts.py and weblogarchive.py
> Would it be sufficient to use the method described above or does this cause
> havoc somewhere else ?

That method won't work for you because it is only hooked up for 
filesystem-based (skin) python scripts.  The workflow scripts get added 
as "External method"s, and consequently are already unencumbered by 
security.  Your problems almost certainly stem from the wf scripts 
calling a method that has some built-in security checks - perhaps 
portal_types.constructContent(...).

With a bit of work, you could fake a temporary login as a Manager-like 
user (in code) around the call to constructContent (or whatever method 
is causing the problem).

There are two reasons why I wouldn't do that.  Firstly, it seems hacky 
and wrong.  Secondly, if you're gonna spend time coding, it'd be far 
more productive for the Quills project if you spent it on hooking of the 
  fake traversal machinery that will do away with the need to move 
weblogentries during "publish" - which should solve your problem as well.


Tim