Etria Lists

Hi,

>Sorry if I'm being a bit slow here.  Can you just clarify things a bit?
Jup,
I have setup a weblog as the siteOwner. My users have the weblogauthorrole.
The idea is that they should be able to publish entrys in this weblog.
There is only one weblog on the site and i want them to be able to publish
in this one, instead of having muliple weblogs and aggregrating content on
the main weblog page. This will add confusion i think.

I went into the ZMI and removed the delete objects rights from the weblog.
This way they cannot delete the weblog itself.
They have rights to create weblogentry's and archives (ZMI permissions on
weblog object).
Creating goes ok , deleting i don't mind doing myself (this is a low-volume
site..), but publishing doesn't work.

Btw this is excerpt from the log:

Traceback (innermost last):
  Module ZPublisher.Publish, line 114, in publish
  Module ZPublisher.mapply, line 88, in mapply
  Module ZPublisher.Publish, line 40, in call_object
  Module Products.CMFFormController.FSControllerPythonScript, line
109, in __call__
  Module Products.CMFFormController.Script, line 141, in __call__
  Module Products.CMFCore.FSPythonScript, line 108, in __call__
  Module Shared.DC.Scripts.Bindings, line 311, in __call__
  Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
  Module Products.CMFCore.FSPythonScript, line 164, in _exec
  Module None, line 41, in content_status_modify
   - <FSControllerPythonScript at /Lepelaar/content_status_modify used
for /Lepelaar/weblog/test>
   - Line 41
  Module Products.CMFCore.WorkflowTool, line 301, in doActionFor
  Module Products.CMFCore.WorkflowTool, line 616, in _invokeWithNotification
  Module Products.DCWorkflow.DCWorkflow, line 287, in doActionFor
  Module Products.DCWorkflow.DCWorkflow, line 472, in _changeStateOf
  Module Products.DCWorkflow.DCWorkflow, line 575, in _executeTransition
  Module Products.ExternalMethod.ExternalMethod, line 232, in __call__
   - __traceback_info__:
((<Products.DCWorkflow.Expression.StateChangeInfo instance at
0x07D1E800>,), {}, None)
  Module C:\Program
Files\Plone21\Data\Products\Quills\Extensions\workflow_scripts.py,
line 38, in moveToArchive
  Module OFS.CopySupport, line 175, in manage_pasteObjects
  Module Products.CMFCore.PortalFolder, line 497, in _verifyObjectPaste
Unauthorized: <AccessControl.unauthorized.Unauthorized instance at 0x07D05CB0>

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

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?
Yes.
I tested this on a folder in a clean Plone instrance with two users setup.


Secondly, if you're gonna spend time coding,....
Well i can tweak a template here and there and do a fair bit of css hacking
but i am no Plone coder yet. I think i would do more harm than good i am
afraid...

rgrds Mike

On 11/1/06, Tim Hicks <tim at sitefusion.co.uk> wrote:
>
> 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
>



-- 
met vriendelijke groeten / with kind regards

Michael Reitsma
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.etria.com/pipermail/quills-dev/attachments/20061101/0c4ab687/attachment.htm